Home » Modeling » EMF » Extend CreatChildCommand
| Extend CreatChildCommand [message #808852] |
Tue, 28 February 2012 08:13  |
 Markus Jo
Messages: 83
Registered: January 2012 |
Member |
|
|
Hi,
in my project we need to extend the CreateChild-Behavior....when a new child is created in the EMF Editor Tree View we need to initialize the element.
For this initialization we need to know the whole model so we are not able to do this in the elements impl class.
So we wanted to extend the CreateChildCommand.....it does not work.
We tried to do our own CreateChildAction and there to create our extending command in OurCreateChildAction:
protected Command createActionCommand(EditingDomain editingDomain, Collection<?> collection)
{
if (collection.size() == 1)
{
Object owner = collection.iterator().next();
return OurCreateChildCommand.create(editingDomain, owner,
descriptor, collection);
}
return UnexecutableCommand.INSTANCE;
}
Because of this section in the
public Command createCommand(Class<? extends Command> commandClass, CommandParameter commandParameter)
method of the AdapterFactoryEditingDomain which looks like this:
else if (commandClass == CreateChildCommand.class)
{
// For CreateChildCommand, we will find the owner by calling EditingDomain.getParent() on the first selected object
Collection<?> sel = commandParameter.getCollection();
Object parent = sel == null ? null : getParent(sel.iterator().next());
if (parent == null)
{
return UnexecutableCommand.INSTANCE;
}
return createCommand(CreateChildCommand.class, new CommandParameter(parent, commandParameter.getFeature(), commandParameter.getValue(), commandParameter.getCollection(), commandParameter.getIndex()));
}
we jump over the line which creates our command. Its hard coded in here that he handles only the CreateChildCommand.class.
How can we extend the CreateChildCommand behavior....extend the class does not work because does always instantiates CreateChildCommand.class. If we give our own class in there the menu is empty.
Any expert here able to help ?
Regards
|
|
|
| Re: Extend CreatChildCommand [message #808869 is a reply to message #808852] |
Tue, 28 February 2012 08:35  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Markus,
Comments below.
On 28/02/2012 9:13 AM, Markus Jo wrote:
> Hi,
> in my project we need to extend the CreateChild-Behavior....when a new
> child is created in the EMF Editor Tree View we need to initialize the
> element.
>
> For this initialization we need to know the whole model so we are not
> able to do this in the elements impl class.
Initialization for child creation should generally be done in the item
providers, not in the model...
>
> So we wanted to extend the CreateChildCommand.....it does not work.
>
> We tried to do our own CreateChildAction and there to create our
> extending command in OurCreateChildAction:
>
> protected Command createActionCommand(EditingDomain editingDomain,
> Collection<?> collection)
> {
> if (collection.size() == 1)
> {
> Object owner = collection.iterator().next();
> return OurCreateChildCommand.create(editingDomain, owner,
> descriptor, collection);
> }
> return UnexecutableCommand.INSTANCE;
> }
>
I'd expect specialization of the item providers should be sufficient,
not the action.
>
>
> Because of this section in the public Command createCommand(Class<?
> extends Command> commandClass, CommandParameter commandParameter)
>
> method of the AdapterFactoryEditingDomain which looks like this:
>
>
> else if (commandClass == CreateChildCommand.class)
> {
> // For CreateChildCommand, we will find the owner by calling
> EditingDomain.getParent() on the first selected object
> Collection<?> sel = commandParameter.getCollection();
> Object parent = sel == null ? null :
> getParent(sel.iterator().next());
> if (parent == null)
> {
> return UnexecutableCommand.INSTANCE;
> }
> return createCommand(CreateChildCommand.class, new
> CommandParameter(parent, commandParameter.getFeature(),
> commandParameter.getValue(), commandParameter.getCollection(),
> commandParameter.getIndex()));
> }
>
>
> we jump over the line which creates our command. Its hard coded in
> here that he handles only the CreateChildCommand.class.
>
> How can we extend the CreateChildCommand behavior....extend the class
> does not work because does always instantiates
> CreateChildCommand.class. If we give our own class in there the menu
> is empty.
Is it really just an issue of initializing the new object being added?
In that case, specializing the
AbcItemProvider.collectNewChildDescriptors method of the Abc object that
will contain the new child should do the trick; you don't need to use
commands to initialize the new object (because such initialization
doesn't need to be undone during undo).
For fancier logic (things that must be done only when the command is
executed), you'd need to specialize
AbcItemProvider.createCreateChildCommand. You'll see in
EGenericItemProvider we have some logic for both, i.e., so that only
meaningful children are suggested (specialized
collectNewChildDescriptors) and so we don't allow things like both the
lower bound and the upper bound to be populated (specialized
createCreateChildCommand).
>
> Any expert here able to help ?
>
> Regards
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Extend CreatChildCommand [message #808960 is a reply to message #808942] |
Tue, 28 February 2012 10:23 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Markus,
Comments below.
On 28/02/2012 11:05 AM, Markus Jo wrote:
> Depends on how you interprete "initialization"......this is logic
> which also has to be done when an object is pasted to some where.
> (e.g. we have a Train and move it to another timetable. Then we have
> to copy some info of the timetable to the train, set an user which is
> in the model root and so on).
So specializing the create child action is clearly not the way to go.
>
> So we need this logic a copy/pasty, at move, at create, set...... and
> that for every object (about one hundred) in the model.
All such specializations should be done by specializing commands. If
there is a generic way to do it for all things in your model, you can
could make use of "Provider Root Extends Class" to do it in some
extended ItemProviderAdapter from which all your generated
AbcItemProviders extend...
> And as said....this logic needs to access the whole model. And I have
> to say that we use a TransactionalEditingDomain....every change has to
> be done inside a command.
Only changes that happen to objects contained in the resource set. So a
newly created object that's not attached to anything yet don't need to
use commands.
> So the best way to do this we thought would be to append this command
> to the SetCommand/ CreateCommand and so on....to prevent duplication
> of code an to prevent overriding 100 collectNewChildDescriptors methods.
Yes, specializing commands is the way to go.
> We already have a command for this and appended it so the SetCommand
> by creating our own SetCommand and hoped we can do this the same way
> by creating our own CreateChildCommand.
Yes, you can do that. But your original post focused on specializing
actions, which isn't a good approach.
>
> Can you see our problem ? The mass of model elements and the
> TransactionalEditingDomain...
So if there's a good generic way, a specialized ItemProviderAdapter
that's reused by all your generated item providers is the best approach.
>
> How would you solve this ?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Extend CreatChildCommand [message #809002 is a reply to message #808974] |
Tue, 28 February 2012 11:15 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Markus,
Comments below.
On 28/02/2012 11:41 AM, Markus Jo wrote:
> Ok, when I use the "Provider Root Extends Class".....can I make use of
> my already implement InitializeCommand which I currently chain to the
> SetCommand ?
I don't know the context where you do this chaining...
> Can I execute it in the "Provider Root Extends Class" ?
The item providers only create the commands. I.e., they act as a
factory for commands. Execution comes later.
> What method do I have to override ?
The methods that create the commands.
> You say that on create we do not need a Command..but we have the
> set/move/copy case too.
No, read my words carefully.
> This seems to be just the solution for the CreateChild case and for
> our other cases we have to do all the logic again somewhere else.
No, I wouldn't suggest something that's not general for the problem you
described.
>
> There are many createCreateChildCommand, createDragAndDropCommand,
> createAddCommand in more than one variation.....do I have to override
> all ?
No, don't override the deprecated ones.
Note that drag and drop command is really a composition of other
commands like add command and set command, so it's not so likely you'll
have to do something special with drag and drop.
> Can I be sure that, if I override them and wirte the new code in there
> that all cases where an modelobject is moved/setted/created are handled ?
Testing.
>
> To have the init code at our own SetCommand AND in this "Provider Root
> Extends Class" would be bad.
If it's fully generic, you can have it just once (just as it's currently
there once in ItemProviderAdapter.
> And how could I get our ItemProviders to extend our "Provider Root
> Extends Class"....
By setting that property in the GenModel.
> can this be generated or do I have to adapt the "extends..." statement
> by hand ?
No, with that property in the GenModel.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 12:11:25 GMT 2024
Powered by FUDForum. Page generated in 0.03355 seconds |
] 
Search
Help
Register
Login
Home
