Home » Modeling » EMF » Overriding createCreateChildCommand
| Overriding createCreateChildCommand [message #483199] |
Mon, 31 August 2009 14:42  |
 Greg Mising name
Messages: 47
Registered: July 2009 |
Member |
|
|
I want to override createCreateChildCommand to return a compound command
that does some initialization work on the new child (including adding some
default children to it). Now this type of new child can be a child of
several different types of objects - e.g. A can be added as a child of B,
C or D.
The createCreateChildCommand is overridden in the item providers of B, C
and D. Instead of repeating the compound command logic in each of B, C,
and D item providers I was thinking that they could each ask A's item
provider for the custom compound command - something like this:
Class BItemProvider {
...
Command createCreateChildCommand( ... ) {
adapter = domain.getAdapterFactory().adapt( value,
IEditingDomainItemProvider.class );
command = adapter.createAddACommand( domain, owner, feature, value,
index, collection );
return command;
}
}
AItemProvider obviously has a method createAddACommand that does the work
of creating the compound command that combines custom initialization
commands and a command that creates the new A object as a child of the
specified owner & feature.
So, my question is: is that a reasonable way to use reusable code to
accomplish what I set out to do? Is there a better or more commonly
acceptable way of doing the same?
Thanks.
Greg
|
|
|
| Re: Overriding createCreateChildCommand [message #483220 is a reply to message #483199] |
Mon, 31 August 2009 15:41  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Greg,
Comments below.
Greg wrote:
> I want to override createCreateChildCommand to return a compound
> command that does some initialization work on the new child (including
> adding some default children to it).
Initialization of the new child doesn't need to be done using a
command. You could populate it as part of creating the descriptor,
i.e., in collectNewChildDescriptors.
> Now this type of new child can be a child of several different types
> of objects - e.g. A can be added as a child of B, C or D.
> The createCreateChildCommand is overridden in the item providers of B,
> C and D. Instead of repeating the compound command logic in each of B,
> C, and D item providers I was thinking that they could each ask A's
> item provider for the custom compound command - something like this:
>
> Class BItemProvider {
> ..
> Command createCreateChildCommand( ... ) {
> adapter = domain.getAdapterFactory().adapt( value,
> IEditingDomainItemProvider.class );
> command = adapter.createAddACommand( domain, owner, feature, value,
> index, collection );
> return command;
> }
> }
>
> AItemProvider obviously has a method createAddACommand that does the
> work of creating the compound command that combines custom
> initialization commands and a command that creates the new A object as
> a child of the specified owner & feature.
It seems you could put the initialization logic anywhere perhaps has a
static method...
>
> So, my question is: is that a reasonable way to use reusable code to
> accomplish what I set out to do? Is there a better or more commonly
> acceptable way of doing the same?
Try the descriptor approach first.
>
> Thanks.
> Greg
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Overriding createCreateChildCommand [message #483224 is a reply to message #483220] |
Mon, 31 August 2009 16:10 |
Greg Mising name
Messages: 47
Registered: July 2009 |
Member |
|
|
Thanks for your reply, Ed.
I'm not really following you on the collectNewChildDescriptors solution.
Whenever a new A object is created I need to set some of its properties
and add a couple of children to it. If I do this as part of collecting
new child descriptors (presumably for one of its parents: B, C or D) are
you suggesting that I define a custom CommandParameter that encapsulates
my initialization requirements? I came up with the compound command idea
because I wanted to make sure that the create command remained undoable
although I suppose that if I'm only touching properties and children of
the created object then it won't matter because undoing it will remove the
new object and its children anyways. It just seems like a bad precedent to
set because if you end up directly modifying any related objects that
aren't contained (owned) by the newly created object then those changes
wouldn't get undone.
Ed Merks wrote:
> Greg,
> Comments below.
> Greg wrote:
>> I want to override createCreateChildCommand to return a compound
>> command that does some initialization work on the new child (including
>> adding some default children to it).
> Initialization of the new child doesn't need to be done using a
> command. You could populate it as part of creating the descriptor,
> i.e., in collectNewChildDescriptors.
>> Now this type of new child can be a child of several different types
>> of objects - e.g. A can be added as a child of B, C or D.
>> The createCreateChildCommand is overridden in the item providers of B,
>> C and D. Instead of repeating the compound command logic in each of B,
>> C, and D item providers I was thinking that they could each ask A's
>> item provider for the custom compound command - something like this:
>>
>> Class BItemProvider {
>> ..
>> Command createCreateChildCommand( ... ) {
>> adapter = domain.getAdapterFactory().adapt( value,
>> IEditingDomainItemProvider.class );
>> command = adapter.createAddACommand( domain, owner, feature, value,
>> index, collection );
>> return command;
>> }
>> }
>>
>> AItemProvider obviously has a method createAddACommand that does the
>> work of creating the compound command that combines custom
>> initialization commands and a command that creates the new A object as
>> a child of the specified owner & feature.
> It seems you could put the initialization logic anywhere perhaps has a
> static method...
>>
>> So, my question is: is that a reasonable way to use reusable code to
>> accomplish what I set out to do? Is there a better or more commonly
>> acceptable way of doing the same?
> Try the descriptor approach first.
>>
>> Thanks.
>> Greg
|
|
|
| Re: Overriding createCreateChildCommand [message #483230 is a reply to message #483224] |
Mon, 31 August 2009 16:26 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Greg,
Comments below.
Greg wrote:
> Thanks for your reply, Ed.
> I'm not really following you on the collectNewChildDescriptors
> solution. Whenever a new A object is created I need to set some of
> its properties and add a couple of children to it. If I do this as
> part of collecting new child descriptors (presumably for one of its
> parents: B, C or D) are you suggesting that I define a custom
> CommandParameter that encapsulates my initialization requirements?
No, just pass the initialized object to the command parameter.
> I came up with the compound command idea because I wanted to make
> sure that the create command remained undoable although I suppose that
> if I'm only touching properties and children of the created object
> then it won't matter because undoing it will remove the new object and
> its children anyways.
All that's necessary is that the initialized objects is added and
removed, the process of initializing it doesn't need to be undoable...
> It just seems like a bad precedent to set because if you end up
> directly modifying any related objects that aren't contained (owned)
> by the newly created object then those changes wouldn't get undone.
Yes, that would be bad, but one doesn't generally expect creating a new
child to do more than adding a new child...
>
> Ed Merks wrote:
>
>> Greg,
>
>> Comments below.
>
>> Greg wrote:
>>> I want to override createCreateChildCommand to return a compound
>>> command that does some initialization work on the new child
>>> (including adding some default children to it).
>> Initialization of the new child doesn't need to be done using a
>> command. You could populate it as part of creating the descriptor,
>> i.e., in collectNewChildDescriptors.
>>> Now this type of new child can be a child of several different types
>>> of objects - e.g. A can be added as a child of B, C or D. The
>>> createCreateChildCommand is overridden in the item providers of B, C
>>> and D. Instead of repeating the compound command logic in each of B,
>>> C, and D item providers I was thinking that they could each ask A's
>>> item provider for the custom compound command - something like this:
>>>
>>> Class BItemProvider {
>>> ..
>>> Command createCreateChildCommand( ... ) {
>>> adapter = domain.getAdapterFactory().adapt( value,
>>> IEditingDomainItemProvider.class );
>>> command = adapter.createAddACommand( domain, owner, feature,
>>> value, index, collection );
>>> return command;
>>> }
>>> }
>>>
>>> AItemProvider obviously has a method createAddACommand that does the
>>> work of creating the compound command that combines custom
>>> initialization commands and a command that creates the new A object
>>> as a child of the specified owner & feature.
>> It seems you could put the initialization logic anywhere perhaps has
>> a static method...
>>>
>>> So, my question is: is that a reasonable way to use reusable code to
>>> accomplish what I set out to do? Is there a better or more commonly
>>> acceptable way of doing the same?
>> Try the descriptor approach first.
>>>
>>> Thanks.
>>> Greg
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:25:00 GMT 2024
Powered by FUDForum. Page generated in 0.03253 seconds |
] 
Search
Help
Register
Login
Home
