Home » Modeling » EMF » Can I override/specialize an EFeature in a subclass?
| | | |
| Re: Can I override/specialize an EFeature in a subclass? [message #523811 is a reply to message #523783] |
Mon, 29 March 2010 13:16   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Jonas,
Yes, it always bothered me that and instance of the derived class cannot
be used as an instance of the base class blindly because the things you
could do with it violate constraints that aren't apparent in the base
API.
Greg,
In Java, List<B> is not a subtype of List<A> even if B is a subtype of
A, so one could not declare EList<Line> getPaths(). So no matter what,
you end up with something that's effectively an invisible constraint.
If you define a model in UML2 then UML allows this type of thing and
UML's mapping to Ecore uses annotations to capture that information and
generate something that enforces the constraint.
Jonas wrote:
> Hi,
> yes it would be doable in Java, but I dont think it would be very good
> style. If I understood your model correctly I would rather add a
> attribute in the subclass called "lines" then overloading the "path"
> attribute. Otherwise getPath.add(path) in the subclass would not
> compile which is quite confusing isnt it?
> Jonas
>
> Greg wrote:
>> Thanks Ed. I know this is certainly doable in Java so the code could
>> be generated, but out of curiosity is there a practical reason why
>> EMF doesn't support this? Are there some internal implementation
>> details that were not designed to support this? I don't see anything
>> in EFactory or EPackage that would have problems supporting it and
>> after a cursory look at EditingDomain, ItemProvider,
>> ItemProviderAdapter and Command nothing stands out there either. I
>> know that there is tons more in the EMF API so I won't be so ignorant
>> as to assume that there isn't some conflict somewhere.
>>
>> Or is it a matter of priority and time for implementing this feature?
>>
>> What is UML2's extended generator? Do you know if Rational Rose
>> supports this?
>>
>> Thanks.
>> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Can I override/specialize an EFeature in a subclass? [message #523889 is a reply to message #523783] |
Mon, 29 March 2010 18:07 |
Greg Mising name
Messages: 47
Registered: July 2009 |
Member |
|
|
Hi Jonas.
Maybe it's a matter of opinion. I prefer to enforce model integrity at design-time rather than run-time, and as low in the design stack as possible. I could use the constraint/validator approach but that puts the onus on some downstream code, probably a UI plugin to ensure the validity (integrity) of the model. I don't want my model to ever be in an invalid state.
I think my solution will be along the lines of:
1) Add constraints to the model
2) Create a custom EditingDomain class that will validate all affected objects of all commands it is asked to create before it returns the command. It will also implement a CommandValidationProvider interface so that the UI can listen, receive and process notifications when a command validation fails.
3) For complex constraints that I can't define in the eCore model, I will define custom commands and override CreateCommand in my ItemProviders to make sure that the appropriate custom command is called.
Any thoughts on that? Ed, what do you think?
Thanks.
Greg
| Jonas wrote on Mon, 29 March 2010 05:42 | Hi,
yes it would be doable in Java, but I dont think it would be very good
style. If I understood your model correctly I would rather add a
attribute in the subclass called "lines" then overloading the "path"
attribute. Otherwise getPath.add(path) in the subclass would not compile
which is quite confusing isnt it?
Jonas
Greg wrote:
> Thanks Ed. I know this is certainly doable in Java so the code could be
> generated, but out of curiosity is there a practical reason why EMF
> doesn't support this? Are there some internal implementation details
> that were not designed to support this? I don't see anything in
> EFactory or EPackage that would have problems supporting it and after a
> cursory look at EditingDomain, ItemProvider, ItemProviderAdapter and
> Command nothing stands out there either. I know that there is tons more
> in the EMF API so I won't be so ignorant as to assume that there isn't
> some conflict somewhere.
>
> Or is it a matter of priority and time for implementing this feature?
>
> What is UML2's extended generator? Do you know if Rational Rose
> supports this?
>
> Thanks.
> Greg
|
|
|
|
| Re: Can I override/specialize an EFeature in a subclass? [message #523894 is a reply to message #523889] |
Mon, 29 March 2010 13:28 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Greg,
Comments below.
Greg wrote:
> Hi Jonas.
>
> Maybe it's a matter of opinion. I prefer to enforce model integrity
> at design-time rather than run-time, and as low in the design stack as
> possible.
Both approaches for this case require runtime constraints.
> I could use the constraint/validator approach but that puts the onus
> on some downstream code, probably a UI plugin to ensure the validity
> (integrity) of the model.
The validator works without UI or even Eclipse dependencies.
> I don't want my model to ever be in an invalid state.
>
> I think my solution will be along the lines of:
> 1) Add constraints to the model
> 2) Create a custom EditingDomain class that will validate all affected
> objects of all commands it is asked to create before it returns the
> command.
Likely you edit this either by creating children, in which case you can
restrict which choices are offered, or via the properties view, in which
case you can filter the choices offered.
> It will also implement a CommandValidationProvider interface so that
> the UI can listen, receive and process notifications when a command
> validation fails.
Probably the UI should never let you make a choice that would fail.
> 3) For complex constraints that I can't define in the eCore model, I
> will define custom commands and override CreateCommand in my
> ItemProviders to make sure that the appropriate custom command is called.
I think that's generally the right track, though I expect it's even
simpler in that you can specialize the derived class'
collectNewChildDescriptors to filter out inappropriate ones as well as
do something similar for the property descriptor if it's a
non-containment reference.
>
> Any thoughts on that? Ed, what do you think?
>
> Thanks.
> Greg
>
> Jonas wrote on Mon, 29 March 2010 05:42
>> Hi,
>> yes it would be doable in Java, but I dont think it would be very
>> good style. If I understood your model correctly I would rather add a
>> attribute in the subclass called "lines" then overloading the "path"
>> attribute. Otherwise getPath.add(path) in the subclass would not
>> compile which is quite confusing isnt it?
>> Jonas
>>
>> Greg wrote:
>> > Thanks Ed. I know this is certainly doable in Java so the code
>> could be > generated, but out of curiosity is there a practical
>> reason why EMF > doesn't support this? Are there some internal
>> implementation details > that were not designed to support this? I
>> don't see anything in > EFactory or EPackage that would have problems
>> supporting it and after a > cursory look at EditingDomain,
>> ItemProvider, ItemProviderAdapter and > Command nothing stands out
>> there either. I know that there is tons more > in the EMF API so I
>> won't be so ignorant as to assume that there isn't > some conflict
>> somewhere.
>> > > Or is it a matter of priority and time for implementing this
>> feature?
>> > > What is UML2's extended generator? Do you know if Rational Rose
>> > supports this?
>> > > Thanks.
>> > Greg
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Can I override/specialize an EFeature in a subclass? [message #523912 is a reply to message #523894] |
Mon, 29 March 2010 19:27 |
Greg Mising name
Messages: 47
Registered: July 2009 |
Member |
|
|
Thanks Ed.
You commented:
> Probably the UI should never let you make a choice that would fail.
I totally agree, however ideally the Edit plugin should never let the UI present a choice that would fail. There are some cases that are unavoidable however. For example, if my objects have a name property and I have a rule/constraint (whatever) that dictates that object names within their container must be unique then the UI (PropertySheet in this case) can't prevent the SetCommand from being requested.
I do like the idea of specializing the ItemProviders' collectNewChildDescriptors and getPropertyDescriptors. I'd probably have to use stateful ItemProviders then.
I've actually done this in one case where I have an object with properties: dataType, lowValue, highValue; where the low and high values are instances of the specified dataType, which is a limited list of java object types. I can specialize my getPropertyDescriptors to regenerate when the dataType gets changed, in which case it will create a property descriptor for low and high value suitable for the new datatype. The problem is, what do I do with the current values of those properties. If the old dataType can be cast to the new dataType then it's not a problem. Otherwise I need to clear their values and let the user enter new valid ones. But where in my code do I clear the values? I could do it in the specialized getPropertyDescriptors, but if the user clicks undo then he doesn't get his old values back. I think this is a case where I'd need to specialize getPropertyDescriptors and override the SetCommand for dataType to make sure that the old values are recoverable in an undo.
So I think that I'll hold off on the following for now:
1) Add constraints to the model
2) Create a custom EditingDomain class that will validate all affected
objects of all commands it is asked to create before it returns the
command.
and do the following instead:
1) Specialize the ItemProviders' collectNewChildDescriptors and getPropertyDescriptors and make them stateful
2) For complex constraints that I can't define in the eCore model, I
will define custom commands and override CreateCommand in my
ItemProviders to make sure that the appropriate custom command is called.
3) Combine 1 and 2 where needed
The only thing this doesn't resolve is communicating back to the command requester (e.g. the UI Action or Viewer or Editor) when a command is created that would violate some constraint. I suppose (as in the object name constraint above) this would only apply to those cases where I need to override the command. So I could just have my custom EditingDomain validate the affected objects of my custom commands and send messages back to the caller via a CommandValidationProvider/Listener interface. I suppose I'd have to add constraints to the model to do this then. I could also add a static method to my custom commands, requiresValidation() since it's possible that not all of them will.
So here's my v3 proposal:
1) Add constraints to the model
2) Specialize the ItemProviders' collectNewChildDescriptors and getPropertyDescriptors and make them stateful
3) Create a custom EditingDomain class that will validate all affected objects for only my custom commands that require it that it is asked to create before it returns the command. It will also implement a CommandValidationProvider/Listener interface so that the UI can listen, receive and process notifications when a command validation fails.
4) For complex constraints that I can't define in the eCore model, I will define custom commands and override CreateCommand in my ItemProviders to make sure that the appropriate custom command is called.
5) Combine 2 and 4 where needed
Any other thoughts on this?
BTW, thanks for all your input on this 
Greg
|
|
|
| Re: Can I override/specialize an EFeature in a subclass? [message #523940 is a reply to message #523912] |
Mon, 29 March 2010 22:39 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Greg,
Comments below.
Greg wrote:
> Thanks Ed.
>
> You commented:
>> Probably the UI should never let you make a choice that would fail.
>
> I totally agree, however ideally the Edit plugin should never let the
> UI present a choice that would fail. There are some cases that are
> unavoidable however. For example, if my objects have a name property
> and I have a rule/constraint (whatever) that dictates that object
> names within their container must be unique then the UI (PropertySheet
> in this case) can't prevent the SetCommand from being requested.
The extended validation framework provide rollback support for this type
of thing. The problem is that constraints are generally expressed based
on the current state of the model, so the model has to be pushed into
that state to check them...
>
> I do like the idea of specializing the ItemProviders'
> collectNewChildDescriptors and getPropertyDescriptors. I'd probably
> have to use stateful ItemProviders then.
Not for these two cases because they depend only on the type of the object.
> I've actually done this in one case where I have an object with
> properties: dataType, lowValue, highValue; where the low and high
> values are instances of the specified dataType, which is a limited
> list of java object types. I can specialize my getPropertyDescriptors
> to regenerate when the dataType gets changed, in which case it will
> create a property descriptor for low and high value suitable for the
> new datatype. The problem is, what do I do with the current values of
> those properties. If the old dataType can be cast to the new dataType
> then it's not a problem. Otherwise I need to clear their values and
> let the user enter new valid ones. But where in my code do I clear
> the values? I could do it in the specialized getPropertyDescriptors,
> but if the user clicks undo then he doesn't get his old values back.
> I think this is a case where I'd need to specialize
> getPropertyDescriptors and override the SetCommand for dataType to
> make sure that the old values are recoverable in an undo.
I see.
>
> So I think that I'll hold off on the following for now:
> 1) Add constraints to the model
> 2) Create a custom EditingDomain class that will validate all affected
> objects of all commands it is asked to create before it returns the
> command.
I think that's challenging as I mentioned earlier, given that validation
is done against the actual state of the model.
>
> and do the following instead:
> 1) Specialize the ItemProviders' collectNewChildDescriptors and
> getPropertyDescriptors and make them stateful
I don't see you need state yet. Remember, there is one created per type.
> 2) For complex constraints that I can't define in the eCore model, I
> will define custom commands and override CreateCommand in my
> ItemProviders to make sure that the appropriate custom command is called.
> 3) Combine 1 and 2 where needed
>
> The only thing this doesn't resolve is communicating back to the
> command requester (e.g. the UI Action or Viewer or Editor) when a
> command is created that would violate some constraint. I suppose (as
> in the object name constraint above) this would only apply to those
> cases where I need to override the command. So I could just have my
> custom EditingDomain validate the affected objects of my custom
> commands and send messages back to the caller via a
> CommandValidationProvider/Listener interface. I suppose I'd have to
> add constraints to the model to do this then. I could also add a
> static method to my custom commands, requiresValidation() since it's
> possible that not all of them will.
You'll likely want to check out the extended validation framework.
>
> So here's my v3 proposal:
> 1) Add constraints to the model
> 2) Specialize the ItemProviders' collectNewChildDescriptors and
> getPropertyDescriptors and make them stateful
> 3) Create a custom EditingDomain class that will validate all affected
> objects for only my custom commands that require it that it is asked
> to create before it returns the command. It will also implement a
> CommandValidationProvider/Listener interface so that the UI can
> listen, receive and process notifications when a command validation
> fails.
> 4) For complex constraints that I can't define in the eCore model, I
> will define custom commands and override CreateCommand in my
> ItemProviders to make sure that the appropriate custom command is called.
> 5) Combine 2 and 4 where needed
>
> Any other thoughts on this? BTW, thanks for all your input on this :d
Sounds good overall.
>
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Fri Apr 26 23:09:05 GMT 2024
Powered by FUDForum. Page generated in 0.04494 seconds |
] 
Search
Help
Register
Login
Home
