It occurred to me that there's a bit of a knack to debugging into EMF code, so I just wrote an FAQ to describe how to do this. Comments are welcome on its clarity or accuracy.
Regards, Kelvin. On 11/12/2007, kelvin goodson <[EMAIL PROTECTED]> wrote: > > Amita, > > It feels like option 1 is the easy way to do things, and option 2 is the > right way given the introduction of instance properties on metadata provided > for this purpose (but doesn't currently work). > > Here's the results of my digging around. Let's start with what I found > last since it might prove to be the answer. It seems highly likely to be > so, but there is more thinking to be done. So after quite a bit of digging > to see how things are handled in EMF I saw the TODO in DataObjectUtil .... > > public static Object getMetaObjectInstanceProperty(EModelElement > metaObject, Property property) > { > String value = EcoreUtil.getAnnotation(metaObject, > property.getContainingType().getURI(), property.getName ()); > //TODO if (property.isMany()) ... // create list of values from from > string > return SDOUtil.createFromString(property.getType(), value); > } > > So there's a couple of things I haven't got my head round yet that perhaps > you could take a look at since I must divert my attention for a while. The > first is that the instance Property for the Type's enumeration is isMany = > false. So even if we handled the TODO we wouldn't get the desired result. > The second is that we must ensure a generic string tokenizer here, but I'm > not yet confident that the tokenizing that we want to satisfy the current > issue would be the same for all Properties. What I mean by this is that for > the example you give, it starts with the separator "space" indicating that > the first literal that should be returned from tokenizing is the empty > string. Would this be true for all Property values, or is it the case that > sometimes we would consider trimming leading white space? > > I had been going down a track of investigating storage and retrieval of > the enumeration facets inside EMF, which may yet prove to be the way to fix > this issue. The facets seem to be stored in two ways. Once as an > annotation on the metadata artifact directly, in concatenated string form, > and once as a vector on the extended metadata associated with the eDataType > (See setEnumerationFacet(EDataType,List) of BasicExtendedMetaData. The bulk > of code in setEnumerationFacet is devoted to concatenating the string > literals and hanging the annotation on the eDataType (Type), but the last > line then squirrels the original input vector of enumerations away on the > extended metadata. > > Now there is a basicGetEnumerationFacet method on the nested class > EDataTypeExtendedMetaDataImpl, which is contained in BasicExtendedMetaData > which has all the reverse logic for unpacking the vector of enumerations > from the concatenated string, but it never gets called in the scenario you > described. Given the piece of code I included above, that wouldn't work > anyway, given the EcoreUtil .getAnnotation returns a single String. > > I don't have a solution yet, but I'll think on it. Any suggestions you > may have are welcome. > > Regards, Kelvin. > > > > > > On 11/12/2007, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > Hi, > > I tried TUSCANY-1360 related to enumeration facet. Below is the summary > > of > > what was > > discussed so far and a few questions. > > ------------------------------------------------------------------------------------------------------------------------------------- > > > > 1) One way to do this is - > > public static List<String> getEnumerationFacet(Type type) { > > return ExtendedMetaData.INSTANCE.getEnumerationFacet > > ((EDataType)type); > > } > > > > which works very straight forward and gives a list of enums. > > > > ------------------------------------------------------------------------------------------------------------------------------------- > > 2) Another way is - > > Do type.getInstanceProperties() and find the Property called > > "enumeration". > > > > Where, getInstanceProperties() calls > > DataObjectUtil.getMetaObjectInstanceProperties(EModelElement metaObject) > > in which for the given metaObject its annotations and details of each > > annotations are traversed. Each > > Annotation Detail is mapped to EStringToStringMapEntryImpl entry like > > below > > - > > > > EStringToStringMapEntryImpl entry = > > (EStringToStringMapEntryImpl)iter.next(); //iter is Iterator over > > current > > Annotation's Details > > String propertyName = entry.getTypedKey(); > > > > Property globalProperty = getGlobalProperty(hc, propertyURI, > > propertyName); > > if (globalProperty != null) > > { > > result.add(globalProperty); > > } > > > > Result is a UniqueEList which is returned at the end. > > > > Here, when entry.getTypedKey() is "enumeration", entry.getTypedValue() > > gives > > a String having space separated enums > > > > e.g. for > > <simpleType name="ExampleRating"> > > <restriction base="string"> > > <enumeration value=""/> > > <enumeration value="Good"/> > > <enumeration value="Bad"/> > > </restriction> > > </simpleType> > > > > it gives," Good Bad" > > > > As we see in Property globalProperty = getGlobalProperty(hc, > > propertyURI, > > propertyName); the TypedKey information is > > used when forming Property with name "enumeration", but the TypedValue > > information is not stored in the Property. > > Same thing will be applicable for other facets like MinLenght, > > MaxExclusive.... > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > Questions: > > > > Thus, the question I have is, in case of following 2), what will be the > > way > > to preserve the mapping (key-value) > > information available about facets from EMF in the formed Property? And > > what > > will be better approach for TUSCANY-1360 > > and as such for any other facets? > > > > Regards, > > Amita > > > >