Home » Modeling » EMF » Modifying simulation model using commands?
| |
| Re: Modifying simulation model using commands? [message #759408 is a reply to message #759404] |
Mon, 28 November 2011 15:20   |
 Joel Greenyer
Messages: 170
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
thanks for the quick response. Further questions below
Joel
On 28.11.2011 16:07, Ed Merks wrote:
> Joel,
>
> Comments below.
>
> On 28/11/2011 3:49 PM, Joel Greenyer wrote:
>> Hi all,
>> we plan a simulation engine based on an EMF model where after each "event" various changes must be made to the model. The question is now whether to apply these changes by a direct manipulation of the simulation model objects from a simulation algorithm or to encapsulate the changes via commands?
> That will depend a bit on whether you want undo support...
>> I see the advantage of the second solution to be that it provides a nicer encapsulation of the logic for the simulation model changes
> Commands are more complex though...
>> and I presume that by using the ChangeCommand it would be possible to get undo support for free.
> Direct manipulation in combination with ChangeCommand does give you "free" undo support.
What do you mean by "direct manipulation in combination with ChangeCommand"?
>> This would be an easy way to support a feature where one could "step back" in the simulation.
> Yes.
>> Are there any arguments against using commands?
> They're a bit more complex than direct manipulation...
>> Also, which kind of editing domain should we use?
> Mostly it sounds like you just need a command stack...
>> I'm not sure that we need all the features provided by the EMF.Edit framework, but maybe we do if we want to build something like a JDT-like Debug perspective where the user is able to inspect the simulation model in detail -- so should we use a generated AdapterFactoryEditingDomain?
> Yes.
>> Should we write another subclass?
> No, that should suffice.
>> Should we do something else?
> If your model is very large, you'll find adding adapters to all of them with each ChangeCommand could be a bit expensive.
What do you mean by that? Could you explain what happens there (or point me to a resource where I can find more information on that)?
>> Do you know any projects that did something similar?
> I don't know of any...
>> It would be nice if we could copy some good ideas.
>>
>> Thanks
>>
>> Joel
|
|
|
| Re: Modifying simulation model using commands? [message #759412 is a reply to message #759408] |
Mon, 28 November 2011 15:33 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Joel,
Comments below.
On 28/11/2011 4:20 PM, Joel Greenyer wrote:
> Hi Ed,
> thanks for the quick response. Further questions below
>
> Joel
>
> On 28.11.2011 16:07, Ed Merks wrote:
>> Joel,
>>
>> Comments below.
>>
>> On 28/11/2011 3:49 PM, Joel Greenyer wrote:
>>> Hi all,
>>> we plan a simulation engine based on an EMF model where after each
>>> "event" various changes must be made to the model. The question is
>>> now whether to apply these changes by a direct manipulation of the
>>> simulation model objects from a simulation algorithm or to
>>> encapsulate the changes via commands?
>> That will depend a bit on whether you want undo support...
>>> I see the advantage of the second solution to be that it provides a
>>> nicer encapsulation of the logic for the simulation model changes
>> Commands are more complex though...
>>> and I presume that by using the ChangeCommand it would be possible
>>> to get undo support for free.
>> Direct manipulation in combination with ChangeCommand does give you
>> "free" undo support.
> What do you mean by "direct manipulation in combination with
> ChangeCommand"?
You can use a ChangeCommand to encapsulate arbitrary changes made
directly via the model API. A ChangeRecorder is used under the covers...
>>> This would be an easy way to support a feature where one could "step
>>> back" in the simulation.
>> Yes.
>>> Are there any arguments against using commands?
>> They're a bit more complex than direct manipulation...
>>> Also, which kind of editing domain should we use?
>> Mostly it sounds like you just need a command stack...
>>> I'm not sure that we need all the features provided by the EMF.Edit
>>> framework, but maybe we do if we want to build something like a
>>> JDT-like Debug perspective where the user is able to inspect the
>>> simulation model in detail -- so should we use a generated
>>> AdapterFactoryEditingDomain?
>> Yes.
>>> Should we write another subclass?
>> No, that should suffice.
>>> Should we do something else?
>> If your model is very large, you'll find adding adapters to all of
>> them with each ChangeCommand could be a bit expensive.
> What do you mean by that? Could you explain what happens there (or
> point me to a resource where I can find more information on that)?
Attaching a ChangeRecorder involves walking the entire containment tree
of a model; it's similar to calling ResourceSet.getAllContents().
It will be cheaper to use things like
AddCommand/RemoveCommand/SetCommand directly.
>>> Do you know any projects that did something similar?
>> I don't know of any...
>>> It would be nice if we could copy some good ideas.
>>>
>>> Thanks
>>>
>>> Joel
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Modifying simulation model using commands? [message #759591 is a reply to message #759412] |
Tue, 29 November 2011 09:48 |
Joel Greenyer
Messages: 170
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
so suppose that for many purposes I'd like to have a fast simulation, but I'd like the user also to be able to use the tool in a "Debug" mode where he should be able to "undo" simulation steps. In the latter case the performance is not so important.
What would be a nice way to realize this?
Do I use different kinds of commands? How would I avoid implementing the same logic twice? Or is there a way to dynamically turn the ChangeRecorder on and off?
Thanks
Joel
On 28.11.2011 16:33, Ed Merks wrote:
> Joel,
>
> Comments below.
>
> On 28/11/2011 4:20 PM, Joel Greenyer wrote:
>> Hi Ed,
>> thanks for the quick response. Further questions below
>>
>> Joel
>>
>> On 28.11.2011 16:07, Ed Merks wrote:
>>> Joel,
>>>
>>> Comments below.
>>>
>>> On 28/11/2011 3:49 PM, Joel Greenyer wrote:
>>>> Hi all,
>>>> we plan a simulation engine based on an EMF model where after each "event" various changes must be made to the model. The question is now whether to apply these changes by a direct manipulation of the simulation model objects from a simulation algorithm or to encapsulate the changes via commands?
>>> That will depend a bit on whether you want undo support...
>>>> I see the advantage of the second solution to be that it provides a nicer encapsulation of the logic for the simulation model changes
>>> Commands are more complex though...
>>>> and I presume that by using the ChangeCommand it would be possible to get undo support for free.
>>> Direct manipulation in combination with ChangeCommand does give you "free" undo support.
>> What do you mean by "direct manipulation in combination with ChangeCommand"?
> You can use a ChangeCommand to encapsulate arbitrary changes made directly via the model API. A ChangeRecorder is used under the covers...
>>>> This would be an easy way to support a feature where one could "step back" in the simulation.
>>> Yes.
>>>> Are there any arguments against using commands?
>>> They're a bit more complex than direct manipulation...
>>>> Also, which kind of editing domain should we use?
>>> Mostly it sounds like you just need a command stack...
>>>> I'm not sure that we need all the features provided by the EMF.Edit framework, but maybe we do if we want to build something like a JDT-like Debug perspective where the user is able to inspect the simulation model in detail -- so should we use a generated AdapterFactoryEditingDomain?
>>> Yes.
>>>> Should we write another subclass?
>>> No, that should suffice.
>>>> Should we do something else?
>>> If your model is very large, you'll find adding adapters to all of them with each ChangeCommand could be a bit expensive.
>> What do you mean by that? Could you explain what happens there (or point me to a resource where I can find more information on that)?
> Attaching a ChangeRecorder involves walking the entire containment tree of a model; it's similar to calling ResourceSet.getAllContents().
>
> It will be cheaper to use things like AddCommand/RemoveCommand/SetCommand directly.
>>>> Do you know any projects that did something similar?
>>> I don't know of any...
>>>> It would be nice if we could copy some good ideas.
>>>>
>>>> Thanks
>>>>
>>>> Joel
>>
|
|
|
| Re: Modifying simulation model using commands? [message #759696 is a reply to message #759591] |
Tue, 29 November 2011 16:31 |
Joel Greenyer
Messages: 170
Registered: July 2009 |
Senior Member |
|
|
Any suggestions?
On 29.11.2011 10:48, Joel Greenyer wrote:
> Hi Ed,
> so suppose that for many purposes I'd like to have a fast simulation, but I'd like the user also to be able to use the tool in a "Debug" mode where he should be able to "undo" simulation steps. In the latter case the performance is not so important.
> What would be a nice way to realize this?
> Do I use different kinds of commands? How would I avoid implementing the same logic twice? Or is there a way to dynamically turn the ChangeRecorder on and off?
>
> Thanks
>
> Joel
>
>
> On 28.11.2011 16:33, Ed Merks wrote:
>> Joel,
>>
>> Comments below.
>>
>> On 28/11/2011 4:20 PM, Joel Greenyer wrote:
>>> Hi Ed,
>>> thanks for the quick response. Further questions below
>>>
>>> Joel
>>>
>>> On 28.11.2011 16:07, Ed Merks wrote:
>>>> Joel,
>>>>
>>>> Comments below.
>>>>
>>>> On 28/11/2011 3:49 PM, Joel Greenyer wrote:
>>>>> Hi all,
>>>>> we plan a simulation engine based on an EMF model where after each "event" various changes must be made to the model. The question is now whether to apply these changes by a direct manipulation of the simulation model objects from a simulation algorithm or to encapsulate the changes via commands?
>>>> That will depend a bit on whether you want undo support...
>>>>> I see the advantage of the second solution to be that it provides a nicer encapsulation of the logic for the simulation model changes
>>>> Commands are more complex though...
>>>>> and I presume that by using the ChangeCommand it would be possible to get undo support for free.
>>>> Direct manipulation in combination with ChangeCommand does give you "free" undo support.
>>> What do you mean by "direct manipulation in combination with ChangeCommand"?
>> You can use a ChangeCommand to encapsulate arbitrary changes made directly via the model API. A ChangeRecorder is used under the covers...
>>>>> This would be an easy way to support a feature where one could "step back" in the simulation.
>>>> Yes.
>>>>> Are there any arguments against using commands?
>>>> They're a bit more complex than direct manipulation...
>>>>> Also, which kind of editing domain should we use?
>>>> Mostly it sounds like you just need a command stack...
>>>>> I'm not sure that we need all the features provided by the EMF.Edit framework, but maybe we do if we want to build something like a JDT-like Debug perspective where the user is able to inspect the simulation model in detail -- so should we use a generated AdapterFactoryEditingDomain?
>>>> Yes.
>>>>> Should we write another subclass?
>>>> No, that should suffice.
>>>>> Should we do something else?
>>>> If your model is very large, you'll find adding adapters to all of them with each ChangeCommand could be a bit expensive.
>>> What do you mean by that? Could you explain what happens there (or point me to a resource where I can find more information on that)?
>> Attaching a ChangeRecorder involves walking the entire containment tree of a model; it's similar to calling ResourceSet.getAllContents().
>>
>> It will be cheaper to use things like AddCommand/RemoveCommand/SetCommand directly.
>>>>> Do you know any projects that did something similar?
>>>> I don't know of any...
>>>>> It would be nice if we could copy some good ideas.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Joel
>>>
>
|
|
|
| Re: Modifying simulation model using commands? [message #759699 is a reply to message #759591] |
Tue, 29 November 2011 16:42 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Joel,
Looks like my answer got lost...
On 29/11/2011 10:48 AM, Joel Greenyer wrote:
> Hi Ed,
> so suppose that for many purposes I'd like to have a fast simulation,
> but I'd like the user also to be able to use the tool in a "Debug"
> mode where he should be able to "undo" simulation steps. In the latter
> case the performance is not so important.
Both approaches will perform the same for undo. So it's the overhead on
execution to be concerned about...
> What would be a nice way to realize this?
Simple fine grained commands (AddCommand/RemoveCommand/SetCommand) will
have less overhead for execution.
> Do I use different kinds of commands? How would I avoid implementing
> the same logic twice?
It's annoying to write the logic once with commands and once directly
using the APIs.
> Or is there a way to dynamically turn the ChangeRecorder on and off?
I imagine it should be possible to using ChangeRecorder.summarize to
produce a delta (ChangeDescription) and then reset the state of the
change recorder to forget about all changes recorded up to that point
(no method for that yet). That would have very little overhead...
>
> Thanks
>
> Joel
>
>
> On 28.11.2011 16:33, Ed Merks wrote:
>> Joel,
>>
>> Comments below.
>>
>> On 28/11/2011 4:20 PM, Joel Greenyer wrote:
>>> Hi Ed,
>>> thanks for the quick response. Further questions below
>>>
>>> Joel
>>>
>>> On 28.11.2011 16:07, Ed Merks wrote:
>>>> Joel,
>>>>
>>>> Comments below.
>>>>
>>>> On 28/11/2011 3:49 PM, Joel Greenyer wrote:
>>>>> Hi all,
>>>>> we plan a simulation engine based on an EMF model where after each
>>>>> "event" various changes must be made to the model. The question is
>>>>> now whether to apply these changes by a direct manipulation of the
>>>>> simulation model objects from a simulation algorithm or to
>>>>> encapsulate the changes via commands?
>>>> That will depend a bit on whether you want undo support...
>>>>> I see the advantage of the second solution to be that it provides
>>>>> a nicer encapsulation of the logic for the simulation model changes
>>>> Commands are more complex though...
>>>>> and I presume that by using the ChangeCommand it would be possible
>>>>> to get undo support for free.
>>>> Direct manipulation in combination with ChangeCommand does give you
>>>> "free" undo support.
>>> What do you mean by "direct manipulation in combination with
>>> ChangeCommand"?
>> You can use a ChangeCommand to encapsulate arbitrary changes made
>> directly via the model API. A ChangeRecorder is used under the covers...
>>>>> This would be an easy way to support a feature where one could
>>>>> "step back" in the simulation.
>>>> Yes.
>>>>> Are there any arguments against using commands?
>>>> They're a bit more complex than direct manipulation...
>>>>> Also, which kind of editing domain should we use?
>>>> Mostly it sounds like you just need a command stack...
>>>>> I'm not sure that we need all the features provided by the
>>>>> EMF.Edit framework, but maybe we do if we want to build something
>>>>> like a JDT-like Debug perspective where the user is able to
>>>>> inspect the simulation model in detail -- so should we use a
>>>>> generated AdapterFactoryEditingDomain?
>>>> Yes.
>>>>> Should we write another subclass?
>>>> No, that should suffice.
>>>>> Should we do something else?
>>>> If your model is very large, you'll find adding adapters to all of
>>>> them with each ChangeCommand could be a bit expensive.
>>> What do you mean by that? Could you explain what happens there (or
>>> point me to a resource where I can find more information on that)?
>> Attaching a ChangeRecorder involves walking the entire containment
>> tree of a model; it's similar to calling ResourceSet.getAllContents().
>>
>> It will be cheaper to use things like
>> AddCommand/RemoveCommand/SetCommand directly.
>>>>> Do you know any projects that did something similar?
>>>> I don't know of any...
>>>>> It would be nice if we could copy some good ideas.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Joel
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Modifying simulation model using commands? [message #759711 is a reply to message #759699] |
Tue, 29 November 2011 17:24 |
Joel Greenyer
Messages: 170
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I'm not sure if I expressed myself clearly. I imagine to have two "modes" for the simulator: one with focus on performance where the simulation just runs, recording no changes, no undo necessary. In the other mode, "Debug", the user should be able to reverse steps.
So, I see two alternatives:
1) Direct manipulation where only in the second mode a ChangeRecorder is activated that tracks the changes. Those I'd have to remember on some stack to reverse them on "step back".
2) I was thinking that maybe I could subclass the ChangeCommand and override the execute method so that for the first mode no ChangeRecorder is created or at least that it will not begin recording when doExecute() is called. For the second mode, I'd keep the default behavior.
What do you think?
Any better ideas?
Big thanks!
Joel
On 29.11.2011 17:42, Ed Merks wrote:
> Joel,
>
> Looks like my answer got lost...
>
> On 29/11/2011 10:48 AM, Joel Greenyer wrote:
>> Hi Ed,
>> so suppose that for many purposes I'd like to have a fast simulation, but I'd like the user also to be able to use the tool in a "Debug" mode where he should be able to "undo" simulation steps. In the latter case the performance is not so important.
> Both approaches will perform the same for undo. So it's the overhead on execution to be concerned about...
>> What would be a nice way to realize this?
> Simple fine grained commands (AddCommand/RemoveCommand/SetCommand) will have less overhead for execution.
>> Do I use different kinds of commands? How would I avoid implementing the same logic twice?
> It's annoying to write the logic once with commands and once directly using the APIs.
>> Or is there a way to dynamically turn the ChangeRecorder on and off?
> I imagine it should be possible to using ChangeRecorder.summarize to produce a delta (ChangeDescription) and then reset the state of the change recorder to forget about all changes recorded up to that point (no method for that yet). That would have very little overhead...
>>
>> Thanks
>>
>> Joel
>>
>>
>> On 28.11.2011 16:33, Ed Merks wrote:
>>> Joel,
>>>
>>> Comments below.
>>>
>>> On 28/11/2011 4:20 PM, Joel Greenyer wrote:
>>>> Hi Ed,
>>>> thanks for the quick response. Further questions below
>>>>
>>>> Joel
>>>>
>>>> On 28.11.2011 16:07, Ed Merks wrote:
>>>>> Joel,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> On 28/11/2011 3:49 PM, Joel Greenyer wrote:
>>>>>> Hi all,
>>>>>> we plan a simulation engine based on an EMF model where after each "event" various changes must be made to the model. The question is now whether to apply these changes by a direct manipulation of the simulation model objects from a simulation algorithm or to encapsulate the changes via commands?
>>>>> That will depend a bit on whether you want undo support...
>>>>>> I see the advantage of the second solution to be that it provides a nicer encapsulation of the logic for the simulation model changes
>>>>> Commands are more complex though...
>>>>>> and I presume that by using the ChangeCommand it would be possible to get undo support for free.
>>>>> Direct manipulation in combination with ChangeCommand does give you "free" undo support.
>>>> What do you mean by "direct manipulation in combination with ChangeCommand"?
>>> You can use a ChangeCommand to encapsulate arbitrary changes made directly via the model API. A ChangeRecorder is used under the covers...
>>>>>> This would be an easy way to support a feature where one could "step back" in the simulation.
>>>>> Yes.
>>>>>> Are there any arguments against using commands?
>>>>> They're a bit more complex than direct manipulation...
>>>>>> Also, which kind of editing domain should we use?
>>>>> Mostly it sounds like you just need a command stack...
>>>>>> I'm not sure that we need all the features provided by the EMF.Edit framework, but maybe we do if we want to build something like a JDT-like Debug perspective where the user is able to inspect the simulation model in detail -- so should we use a generated AdapterFactoryEditingDomain?
>>>>> Yes.
>>>>>> Should we write another subclass?
>>>>> No, that should suffice.
>>>>>> Should we do something else?
>>>>> If your model is very large, you'll find adding adapters to all of them with each ChangeCommand could be a bit expensive.
>>>> What do you mean by that? Could you explain what happens there (or point me to a resource where I can find more information on that)?
>>> Attaching a ChangeRecorder involves walking the entire containment tree of a model; it's similar to calling ResourceSet.getAllContents().
>>>
>>> It will be cheaper to use things like AddCommand/RemoveCommand/SetCommand directly.
>>>>>> Do you know any projects that did something similar?
>>>>> I don't know of any...
>>>>>> It would be nice if we could copy some good ideas.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Joel
>>>>
>>
|
|
|
| Re: Modifying simulation model using commands? [message #759734 is a reply to message #759711] |
Tue, 29 November 2011 19:21 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Joel,
Comments below.
On 29/11/2011 6:24 PM, Joel Greenyer wrote:
> Hi Ed,
> I'm not sure if I expressed myself clearly. I imagine to have two
> "modes" for the simulator: one with focus on performance where the
> simulation just runs, recording no changes, no undo necessary. In the
> other mode, "Debug", the user should be able to reverse steps.
I see.
> So, I see two alternatives:
> 1) Direct manipulation where only in the second mode a ChangeRecorder
> is activated that tracks the changes. Those I'd have to remember on
> some stack to reverse them on "step back".
Yep.
> 2) I was thinking that maybe I could subclass the ChangeCommand and
> override the execute method so that for the first mode no
> ChangeRecorder is created or at least that it will not begin recording
> when doExecute() is called. For the second mode, I'd keep the default
> behavior.
A change command without a change recorder is kind of pointless... If
you look closely at how a change command works, it just creates change
descriptions so you could keep a list of those without ever using commands.
>
> What do you think?
If the debug mode being slow isn't a problem, your approach sounds fine...
> Any better ideas?
>
> Big thanks!
>
> Joel
>
> On 29.11.2011 17:42, Ed Merks wrote:
>> Joel,
>>
>> Looks like my answer got lost...
>>
>> On 29/11/2011 10:48 AM, Joel Greenyer wrote:
>>> Hi Ed,
>>> so suppose that for many purposes I'd like to have a fast
>>> simulation, but I'd like the user also to be able to use the tool in
>>> a "Debug" mode where he should be able to "undo" simulation steps.
>>> In the latter case the performance is not so important.
>> Both approaches will perform the same for undo. So it's the overhead
>> on execution to be concerned about...
>>> What would be a nice way to realize this?
>> Simple fine grained commands (AddCommand/RemoveCommand/SetCommand)
>> will have less overhead for execution.
>>> Do I use different kinds of commands? How would I avoid implementing
>>> the same logic twice?
>> It's annoying to write the logic once with commands and once directly
>> using the APIs.
>>> Or is there a way to dynamically turn the ChangeRecorder on and off?
>> I imagine it should be possible to using ChangeRecorder.summarize to
>> produce a delta (ChangeDescription) and then reset the state of the
>> change recorder to forget about all changes recorded up to that point
>> (no method for that yet). That would have very little overhead...
>>>
>>> Thanks
>>>
>>> Joel
>>>
>>>
>>> On 28.11.2011 16:33, Ed Merks wrote:
>>>> Joel,
>>>>
>>>> Comments below.
>>>>
>>>> On 28/11/2011 4:20 PM, Joel Greenyer wrote:
>>>>> Hi Ed,
>>>>> thanks for the quick response. Further questions below
>>>>>
>>>>> Joel
>>>>>
>>>>> On 28.11.2011 16:07, Ed Merks wrote:
>>>>>> Joel,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> On 28/11/2011 3:49 PM, Joel Greenyer wrote:
>>>>>>> Hi all,
>>>>>>> we plan a simulation engine based on an EMF model where after
>>>>>>> each "event" various changes must be made to the model. The
>>>>>>> question is now whether to apply these changes by a direct
>>>>>>> manipulation of the simulation model objects from a simulation
>>>>>>> algorithm or to encapsulate the changes via commands?
>>>>>> That will depend a bit on whether you want undo support...
>>>>>>> I see the advantage of the second solution to be that it
>>>>>>> provides a nicer encapsulation of the logic for the simulation
>>>>>>> model changes
>>>>>> Commands are more complex though...
>>>>>>> and I presume that by using the ChangeCommand it would be
>>>>>>> possible to get undo support for free.
>>>>>> Direct manipulation in combination with ChangeCommand does give
>>>>>> you "free" undo support.
>>>>> What do you mean by "direct manipulation in combination with
>>>>> ChangeCommand"?
>>>> You can use a ChangeCommand to encapsulate arbitrary changes made
>>>> directly via the model API. A ChangeRecorder is used under the
>>>> covers...
>>>>>>> This would be an easy way to support a feature where one could
>>>>>>> "step back" in the simulation.
>>>>>> Yes.
>>>>>>> Are there any arguments against using commands?
>>>>>> They're a bit more complex than direct manipulation...
>>>>>>> Also, which kind of editing domain should we use?
>>>>>> Mostly it sounds like you just need a command stack...
>>>>>>> I'm not sure that we need all the features provided by the
>>>>>>> EMF.Edit framework, but maybe we do if we want to build
>>>>>>> something like a JDT-like Debug perspective where the user is
>>>>>>> able to inspect the simulation model in detail -- so should we
>>>>>>> use a generated AdapterFactoryEditingDomain?
>>>>>> Yes.
>>>>>>> Should we write another subclass?
>>>>>> No, that should suffice.
>>>>>>> Should we do something else?
>>>>>> If your model is very large, you'll find adding adapters to all
>>>>>> of them with each ChangeCommand could be a bit expensive.
>>>>> What do you mean by that? Could you explain what happens there (or
>>>>> point me to a resource where I can find more information on that)?
>>>> Attaching a ChangeRecorder involves walking the entire containment
>>>> tree of a model; it's similar to calling ResourceSet.getAllContents().
>>>>
>>>> It will be cheaper to use things like
>>>> AddCommand/RemoveCommand/SetCommand directly.
>>>>>>> Do you know any projects that did something similar?
>>>>>> I don't know of any...
>>>>>>> It would be nice if we could copy some good ideas.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Joel
>>>>>
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 11:47:12 GMT 2024
Powered by FUDForum. Page generated in 0.04414 seconds |
] 
Search
Help
Register
Login
Home
