Home » Modeling » EMF » How to do lazy object creation with editingDomain?
How to do lazy object creation with editingDomain? [message #775579] |
Fri, 06 January 2012 09:55 |
|
Hi all,
I am facing the scenario where some model elements may not exist, and I would like to create them when they are accessed the first time. Example:
GeneralConfiguration generalConfig = toolExtension.getGeneralConfiguration();
generalConfig may or may not be null - I'd like to always get a non-null element, and if it is in fact null, I'd like the GeneralConfiguration to be created on the fly.
Of course I could override ToolExtensionImpl.getGeneralConfiguration() - but if I do this, then I don't have access to the editingDomain. Therefore the object creation would bypass the undo/redo stack.
Of course, I could check for null and create the GeneralConfiguration with a command if it's null, but this seems ugly and error prone.
Is there an elegant way of achieving this?
Thanks,
- Michael
|
|
|
Re: How to do lazy object creation with editingDomain? [message #775597 is a reply to message #775579] |
Fri, 06 January 2012 10:27 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
On 06/01/2012 10:55 AM, Michael Jastram wrote:
> Hi all,
>
> I am facing the scenario where some model elements may not exist, and
> I would like to create them when they are accessed the first time.
> Example:
>
> GeneralConfiguration generalConfig =
> toolExtension.getGeneralConfiguration();
Is this a GMF thing?
> generalConfig may or may not be null - I'd like to always get a
> non-null element, and if it is in fact null, I'd like the
> GeneralConfiguration to be created on the fly.
The configuration is part of the serialized model?
>
> Of course I could override ToolExtensionImpl.getGeneralConfiguration()
> - but if I do this, then I don't have access to the editingDomain.
> Therefore the object creation would bypass the undo/redo stack.
Given it's done lazily, but the user will notice the editor becomes
dirty, what user action will cause this to happen?
>
> Of course, I could check for null and create the GeneralConfiguration
> with a command if it's null, but this seems ugly and error prone.
There's only one way to change the model state in and editor, and that's
with a command, so it seems one way or the other, you're going to use
this approach to solve the problem.
>
> Is there an elegant way of achieving this?
I'm not sure there's enough contextual information to answer this question.
>
> Thanks,
>
> - Michael
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: How to do lazy object creation with editingDomain? [message #775608 is a reply to message #775597] |
Fri, 06 January 2012 10:58 |
|
Hi Ed,
>> GeneralConfiguration generalConfig =
>> toolExtension.getGeneralConfiguration();
> Is this a GMF thing?
No, it's an RMF GUI (ProR) thing.
>> generalConfig may or may not be null - I'd like to always get a
>> non-null element, and if it is in fact null, I'd like the
>> GeneralConfiguration to be created on the fly.
> The configuration is part of the serialized model?
Yes - the ReqIF format allows tools to store their own data in the model, this is what I am doing here.
>> Of course I could override ToolExtensionImpl.getGeneralConfiguration()
>> - but if I do this, then I don't have access to the editingDomain.
>> Therefore the object creation would bypass the undo/redo stack.
> Given it's done lazily, but the user will notice the editor becomes
> dirty, what user action will cause this to happen?
Yes, that's find with me, although it may be confusing to the user. In this particular case, the user would open a configuration dialog. Upon opening, the generalConfig element would be created on the fly. Changes in the dialog would add additional element to generalConfig.
From a usage point of view, it would probably be better to create the generalConfig element only if the use needs to add an element to it. I could even combine them in a CompoundCommand, therefore rolling the lazy creation into the action that the user expects. In this case, I was willing to sacrifice a little user experience for cleaner code.
>> Of course, I could check for null and create the GeneralConfiguration
>> with a command if it's null, but this seems ugly and error prone.
> There's only one way to change the model state in and editor, and that's
> with a command, so it seems one way or the other, you're going to use
> this approach to solve the problem.
Then I'll leave it as that - this is pretty much what I am doing right now. For my taste there are just too many checks for null that trigger object creations via commands.
>> Is there an elegant way of achieving this?
> I'm not sure there's enough contextual information to answer this question.
Actually, you did answer my question: A lot of code has to be written to get things really "right" - no shortcuts.
Best,
- Michael
|
|
|
Re: How to do lazy object creation with editingDomain? [message #775618 is a reply to message #775608] |
Fri, 06 January 2012 11:23 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
On 06/01/2012 11:58 AM, Michael Jastram wrote:
> Hi Ed,
>
>>> GeneralConfiguration generalConfig =
>>> toolExtension.getGeneralConfiguration();
>
>> Is this a GMF thing?
>
> No, it's an RMF GUI (ProR) thing.
Oh, so this is a model access...
>
>>> generalConfig may or may not be null - I'd like to always get a
>>> non-null element, and if it is in fact null, I'd like the
>>> GeneralConfiguration to be created on the fly.
>
>> The configuration is part of the serialized model?
>
> Yes - the ReqIF format allows tools to store their own data in the
> model, this is what I am doing here.
>
>>> Of course I could override
>>> ToolExtensionImpl.getGeneralConfiguration() - but if I do this, then
>>> I don't have access to the editingDomain. Therefore the object
>>> creation would bypass the undo/redo stack.
>
>> Given it's done lazily, but the user will notice the editor becomes
>> dirty, what user action will cause this to happen?
>
> Yes, that's find with me, although it may be confusing to the user.
> In this particular case, the user would open a configuration dialog.
> Upon opening, the generalConfig element would be created on the fly.
No, it seems to me it should be created when you hit OK. If they hit
cancel, nothing should be done.
> Changes in the dialog would add additional element to generalConfig.
The whole dialog interaction should result in a single undoable command,
and then only if they hit OK.
>
> From a usage point of view, it would probably be better to create the
> generalConfig element only if the use needs to add an element to it.
> I could even combine them in a CompoundCommand, therefore rolling the
> lazy creation into the action that the user expects. In this case, I
> was willing to sacrifice a little user experience for cleaner code. :)
Absolutely that the only good way to handle this.
>
>>> Of course, I could check for null and create the
>>> GeneralConfiguration with a command if it's null, but this seems
>>> ugly and error prone.
>
>> There's only one way to change the model state in and editor, and
>> that's with a command, so it seems one way or the other, you're going
>> to use this approach to solve the problem.
>
> Then I'll leave it as that - this is pretty much what I am doing right
> now. For my taste there are just too many checks for null that
> trigger object creations via commands.
As we discussed above, all state changes should be triggered by hitting
OK, not before.
>
>>> Is there an elegant way of achieving this?
>
>> I'm not sure there's enough contextual information to answer this
>> question.
>
> Actually, you did answer my question: A lot of code has to be written
> to get things really "right" - no shortcuts. :)
Doing the right thing is often difficult. :-P
>
> Best,
>
> - Michael
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 20:02:01 GMT 2024
Powered by FUDForum. Page generated in 0.03048 seconds
|