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
>
