|
| Re: ECP with generics [message #1391831 is a reply to message #1391785] |
Tue, 01 July 2014 13:26   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
On 01/07/2014 2:10 PM, Christian Reuter wrote:
> Hi,
>
> I tried to use generics with ECP.
> I created a generic class "Property<T>" with the attributes name
> (String) and value (T).
>
> This seems to "almost work" in ECP.
> I can create and edit properties and even a TableControl shows a list
> of poperties.
>
> However there are 2 problems:
> 1. The editor which opens on a double click on a property element in
> the model explorer tree does not show the value attribute at all.
In terms of it's erasure, such an unbounded type parameter looks to be
of type EJavaObject.
> 2. The TableControl allows editing of the value attribute but if I try
> to do so the value is something like "ACED000570" by default and can
> not be modified.
Yes, that's how EJavaObject serialized, i.e., as a Base64 encoding of
the Serializeable value.
>
> I suppose that generics are not officially supported yet.
It is, but we'd have to make much more extensive use of
org.eclipse.emf.ecore.EClass.getFeatureType(EStructuralFeature) rather
than calling EStructuralFeature.getEType(), which returns the erased type.
> Is there any plan to do so?
It's quite well supported for references (because EObject is the erasure
for that case), but making this work for attributes is more complex,
e.g., the serializer would have to be smarter as well...
> Is there a chance that someone can take a look at this and provide a
> fix or a workaround?
It's probably better you consider it a limitation. You might model the
feature as an operation on Property, and provide strongly typed features
in each subclass. Note that without an explicit subclass, there is no
possibility to use rectification to do a better job; the object simply
doesn't know which type parameters were used to instantiate it. This is
the same limitation as in Java, i.e., a runtime instance of new
ArrayList<Foo>() has no way to determine Foo.
>
> Thx,
>
> chris
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: ECP with generics [message #1391967 is a reply to message #1391890] |
Tue, 01 July 2014 17:26 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
On 01/07/2014 5:06 PM, Christian Reuter wrote:
> Ed,
>
> thank you for your quick answer. This is the answer I was afraid to get.
>
> Of course I see the point why this feature is quite complex.
> Besides the problems you mentioned the user also needs to be able to
> define the actual class of the generic attribute during the
> instantiation of the object.
> However this could for example be solved by an annotation of the
> domain model providing a list of class names which may be used and
> extending the context menu entry "Property" by these classes ("String
> Property", "Integer Property", ...)
Then you'd need subclasses and then you could just define the feature in
that subclass. Everything would work and nothing else would be needed.
>
> Too bad there is no way to use ECP with a more generic domain model.
> The model needs to be tailored very narrowly to a specific customer's
> requirements if it is impossible to use some sort of properties of
> which the type can be determined at runtime.
Dynamic models are possible to make things dynamic at runtime.
> Plus that it is impossible to create new attributes at runtime.
With dynamic models you can create all kinds of things at runtime, you
just can't modify generated models (nor modify dynamic models once
instances exist in the runtime).
> I also tried to use another approach with an abstract Property class
> which only defines the name attribute and the derived classes String
> Property, Integer Property, etc. which define the value attribute.
> This works with ECP in general but it is currently not possible to
> create a TableControl for the property list of an object which must
> hold a referencees to the abstract class Property. The value attribute
> of the derived classes can not be selected as a table column in this
> case.
>
> To conclude this discussion I think it would be very desirable to
> support generics and TableControls of derived classes to allow more
> dynamic domain models in general.
With the use of dynamic models this should all be possible.
>
> Cheers,
>
> chris
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04625 seconds
] 
Search
Help
Register
Login
Home
