Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Michael Jastram is currently offline Michael JastramFriend
Messages: 235
Registered: April 2010
Location: Düsseldorf, Germany
Senior Member
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
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 Go to previous messageGo to next message
Michael Jastram is currently offline Michael JastramFriend
Messages: 235
Registered: April 2010
Location: Düsseldorf, Germany
Senior Member
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. Smile

>> 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. Smile

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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
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/
Previous Topic:Modeling Symposium
Next Topic:Creating generic data types
Goto Forum:
  


Current Time: Thu Apr 25 20:02:01 GMT 2024

Powered by FUDForum. Page generated in 0.03048 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top