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
> >
>
>
