Eclipse Community Forums: EMF » [EMF] Generated/Generated NOT mechanism at the model level

Help

Home

Home » Modeling » EMF » [EMF] Generated/Generated NOT mechanism at the model level

Show: Today's Messages :: Show Polls :: Message Navigator

[EMF] Generated/Generated NOT mechanism at the model level [message #648151]

Tue, 11 January 2011 14:02

Sylvain EVEILLARD

Messages: 556
Registered: July 2009

Senior Member

Hi,

I'm wondering how I could implement the generated/generated NOT mechanism at the model level that is having a boolean on all my EAttributes that indicates if the value has been populated automatically or modified manually.

I was thinking about using custom EDataTypes but I'm a bit worried by the xmi serialization that would result from that.
Alternatively I could have an abstract EClass "Generated" with a EBoolean attribute and create EClasses extending "Generated" for all my original EAttributes but then I would get a billon EClasses and that may also complicate things...

What would be the best solution ?

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648183 is a reply to message #648151]

Tue, 11 January 2011 16:23

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Sylvain,

Comments below.

Sylvain EVEILLARD wrote:
> Hi,
>
> I'm wondering how I could implement the generated/generated NOT
> mechanism at the model level that is having a boolean on all my
> EAttributes that indicates if the value has been populated
> automatically or modified manually.
What do you mean by the value?
>
> I was thinking about using custom EDataTypes but I'm a bit worried by
> the xmi serialization that would result from that.
Why are you worried about?
> Alternatively I could have an abstract EClass "Generated" with a
> EBoolean attribute and create EClasses extending "Generated" for all
> my original EAttributes but then I would get a billon EClasses and
> that may also complicate things...
What specific problem are you trying to solve?
>
> What would be the best solution ?
You've only told me hypothetical solutions so far, but I'm not actually
sure what problem you're trying to solve.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648186 is a reply to message #648151]

Tue, 11 January 2011 16:58

Sylvain EVEILLARD

Messages: 556
Registered: July 2009

Senior Member

Let's say I have an EAttribute extendedName in my meta-model on an EClass "Entity". I also have an external mechanism that populates automatically the extendedNames of the entities that belongs to a model.
Once populated automatically, the user can still modify the names that were generated and if that's the case there should be a mechanism able to save that this or this name was modified so that when the automatic process is ran once again, the user-modifications are kept and the modified extendedNames are not be re-populated.

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648207 is a reply to message #648186]

Tue, 11 January 2011 18:41

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Sylvain,

Comments below.

Sylvain EVEILLARD wrote:
> Let's say I have an EAttribute extendedName in my meta-model on an
> EClass "Entity". I also have an external mechanism that populates
> automatically the extendedNames of the entities that belongs to a model.
Suppose I use EcoreUtil.copy. What should happen with the new copy? Is
the external mechanism somehow aware of the creation of the copy?
> Once populated automatically, the user can still modify the names that
> were generated and if that's the case there should be a mechanism able
> to save that this or this name was modified so that when the automatic
> process is ran once again, the user-modifications are kept and the
> modified extendedNames are not be re-populated.
Isn't it sufficient to have null represent the fact that the attribute
isn't populated at all, neither by the user nor by the automatic process?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648277 is a reply to message #648151]

Wed, 12 January 2011 09:13

Sylvain EVEILLARD

Messages: 556
Registered: July 2009

Senior Member

Let's imagine extendedName = name.toUpperCase() but then the user can still refine the extendedName and if that's the case the formula is no longer to be applied on the name when it changes.

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648351 is a reply to message #648277]

Wed, 12 January 2011 14:35

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Sylvain,

How would you solve this problem if you had to write all the code by hand?

Sylvain EVEILLARD wrote:
> Let's imagine extendedName = name.toUpperCase() but then the user can
> still refine the extendedName and if that's the case the formula is no
> longer to be applied on the name when it changes.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648399 is a reply to message #648151]

Wed, 12 January 2011 17:37

Sylvain EVEILLARD

Messages: 556
Registered: July 2009

Senior Member

I'd use a "generated" checkbox next to the extendedName field, set to true when the formula is applied, set to false when the user modifies the extendedName field and can be set back to true by the user if he wants to cancel his modifications and instead use the formula.

That's for the UI though because for the serialization I guess I'd probably end up creating as many generatedXXXX booleans as needed.

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648404 is a reply to message #648399]

Wed, 12 January 2011 17:54

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Sylvain,

That sounds like an additional boolean feature; one that you'd need to
persist...

Sylvain EVEILLARD wrote:
> I'd use a "generated" checkbox next to the extendedName field, set to
> true when the formula is applied, set to false when the user modifies
> the extendedName field and can be set back to true by the user if he
> wants to cancel his modifications and instead use the formula.
>
> That's for the UI though because for the serialization I guess I'd
> probably end up creating as many generatedXXXX booleans as needed.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648522 is a reply to message #648151]

Thu, 13 January 2011 11:28

Sylvain EVEILLARD

Messages: 556
Registered: July 2009

Senior Member

Yep and I'm actually wondering what would be the best way to do that.

Quote:

I was thinking about using custom EDataTypes but I'm a bit worried by the xmi serialization that would result from that.
Alternatively I could have an abstract EClass "Generated" with a EBoolean attribute and create EClasses extending "Generated" for all my original EAttributes but then I would get a billon EClasses and that may also complicate things...

Well the last solution would be to create as many "generatedXXX" EBoolean as needed. Maybe this would be the best solution.

Report message to a moderator

Re: [EMF] Generated/Generated NOT mechanism at the model level [message #648630 is a reply to message #648522]

Thu, 13 January 2011 17:35

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Sylvain,

I can't think of any other way...

Sylvain EVEILLARD wrote:
> Yep and I'm actually wondering what would be the best way to do that.
> Quote:
>> I was thinking about using custom EDataTypes but I'm a bit worried by
>> the xmi serialization that would result from that.
>> Alternatively I could have an abstract EClass "Generated" with a
>> EBoolean attribute and create EClasses extending "Generated" for all
>> my original EAttributes but then I would get a billon EClasses and
>> that may also complicate things...
>
> Well the last solution would be to create as many "generatedXXX"
> EBoolean as needed. Maybe this would be the best solution.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	unqualified XML File
Next Topic:	Remove Empty elements from XML

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 23:04:20 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter