Home » Modeling » EMF » setting default value of derived propertyi in ecore
| | | |
| Re: setting default value of derived propertyi in ecore [message #1077228 is a reply to message #1077067] |
Thu, 01 August 2013 11:58   |
 Mauro Condarelli
Messages: 428
Registered: September 2009 |
Senior Member |
|
|
Thanks Ed,
comments inline.
On 01/08/2013 09:51, Ed Merks wrote:
> Mauro,
>
> Generally you can do initialization by specializing the objects created
> for the child descriptors in the each of the generated
> org.eclipse.emf.edit.provider.ItemProviderAdapter.collectNewChildDescriptors(Collection<Object>,
> Object).
Uhm, I don't see such a class in my generated code.
NOTE: I'm using only the "Model Code", no edit nor editor.
I was thinking about hand-modifying methods in XxxFactoryImpl, but
perhaps there's a better way?
Maybe using EAnnotations.body ? (examples? "5.7.1 Annotations in EMF"
does not really explain... or I'm being dense?)
>
> On 01/08/2013 9:49 AM, Mauro Candarelli wrote:
>> Thanks Ed.
>>
>> Oops!
>> Sorry, I hit the wrong button and I sent this to Your personal account.
>>
>> On 01/08/2013 09:20, Ed Merks wrote:
>> > I suspect your issue is more of one about initializing newly create
>> > instances in the editor, and there you'll probably want to pick a
>> unique
>> > new name. Is that the case?
>> Yes.
>> Name don't need to be unique, "New Machine"/"New Station"/.../"New
>> Identifiable" are ok.
>> I would like to also initialize the "id : EInteger" (again in
>> Identifiable) with some kind of auto-increment (this needs to be
>> unique!).
>>
>> Mauro
>>
>
|
|
|
| Re: setting default value of derived propertyi in ecore [message #1077236 is a reply to message #1077228] |
Thu, 01 August 2013 12:12 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Mauro,
Comments below.
On 01/08/2013 1:58 PM, Mauro Candarelli wrote:
> Thanks Ed,
> comments inline.
>
> On 01/08/2013 09:51, Ed Merks wrote:
>> Mauro,
>>
>> Generally you can do initialization by specializing the objects created
>> for the child descriptors in the each of the generated
>> org.eclipse.emf.edit.provider.ItemProviderAdapter.collectNewChildDescriptors(Collection<Object>,
>>
>> Object).
> Uhm, I don't see such a class in my generated code.
> NOTE: I'm using only the "Model Code", no edit nor editor.
I specifically asked "I suspect your issue is more of one about
initializing newly create instances in the editor"...
>
> I was thinking about hand-modifying methods in XxxFactoryImpl, but
> perhaps there's a better way?
No, none of such things in the model are a good idea. The base factory
behavior shouldn't be changed. It must create uninitialized instances.
You could add additional factory methods, but I would have expected
that if you're creating things programmatically that you'd populate the
new instances correctly and as desired... E.g., for the Ecore model an
EClassifier must have a name, but it does no good to just initialize one
with "NewClass" in the model, because the name must be populated in a
meaningful way by any and all code that's creating Ecore instances.
So your use case isn't clear to me. I had assumed an editor is involved
and the things you wanted are for the benefit of the user of such an
editor, but now you say that's not the case...
> Maybe using EAnnotations.body ? (examples? "5.7.1 Annotations in EMF"
> does not really explain... or I'm being dense?)
>
>>
>> On 01/08/2013 9:49 AM, Mauro Candarelli wrote:
>>> Thanks Ed.
>>>
>>> Oops!
>>> Sorry, I hit the wrong button and I sent this to Your personal account.
>>>
>>> On 01/08/2013 09:20, Ed Merks wrote:
>>> > I suspect your issue is more of one about initializing newly create
>>> > instances in the editor, and there you'll probably want to pick a
>>> unique
>>> > new name. Is that the case?
>>> Yes.
>>> Name don't need to be unique, "New Machine"/"New Station"/.../"New
>>> Identifiable" are ok.
>>> I would like to also initialize the "id : EInteger" (again in
>>> Identifiable) with some kind of auto-increment (this needs to be
>>> unique!).
>>>
>>> Mauro
>>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: setting default value of derived propertyi in ecore [message #1077255 is a reply to message #1077236] |
Thu, 01 August 2013 12:47 |
Mauro Condarelli
Messages: 428
Registered: September 2009 |
Senior Member |
|
|
Sorry Ed,
I was not clear.
What I'm writing is, indeed, an editor for this model I'm building.
Application is a native JavaFX application, I am thus using EMF in
"standalone" mode.
Following Tom's advice I am using only the basic "Model Code" EMF code
generator. I am using EMF and JFX Databinding to connect Model with UI.
Question was: I would like to do some basic initialization on EClass
creation, what is the best place to insert it?
Already the basic generated code can insert default values in
attributes, but this doe not work if the value is in an ancestor class
(to be more precise: the default is in the ancestor and seems not
changeable in derived classes).
Is there a good place in EMF/ecore or should I initialize EClasses in my
editor code? Putting defaults in ecore would be very nice.
Thanks again
Mauro
On 01/08/2013 14:12, Ed Merks wrote:
> Mauro,
>
> Comments below.
>
>
> On 01/08/2013 1:58 PM, Mauro Candarelli wrote:
>> Thanks Ed,
>> comments inline.
>>
>> On 01/08/2013 09:51, Ed Merks wrote:
>>> Mauro,
>>>
>>> Generally you can do initialization by specializing the objects created
>>> for the child descriptors in the each of the generated
>>> org.eclipse.emf.edit.provider.ItemProviderAdapter.collectNewChildDescriptors(Collection<Object>,
>>>
>>> Object).
>> Uhm, I don't see such a class in my generated code.
>> NOTE: I'm using only the "Model Code", no edit nor editor.
> I specifically asked "I suspect your issue is more of one about
> initializing newly create instances in the editor"...
>>
>> I was thinking about hand-modifying methods in XxxFactoryImpl, but
>> perhaps there's a better way?
> No, none of such things in the model are a good idea. The base factory
> behavior shouldn't be changed. It must create uninitialized instances.
> You could add additional factory methods, but I would have expected
> that if you're creating things programmatically that you'd populate the
> new instances correctly and as desired... E.g., for the Ecore model an
> EClassifier must have a name, but it does no good to just initialize one
> with "NewClass" in the model, because the name must be populated in a
> meaningful way by any and all code that's creating Ecore instances.
>
> So your use case isn't clear to me. I had assumed an editor is involved
> and the things you wanted are for the benefit of the user of such an
> editor, but now you say that's not the case...
|
|
|
| Re: setting default value of derived propertyi in ecore [message #1077272 is a reply to message #1077255] |
Thu, 01 August 2013 13:14 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Mauro,
Comments below.
On 01/08/2013 2:47 PM, Mauro Candarelli wrote:
> Sorry Ed,
> I was not clear.
>
> What I'm writing is, indeed, an editor for this model I'm building.
>
> Application is a native JavaFX application, I am thus using EMF in
> "standalone" mode.
>
> Following Tom's advice I am using only the basic "Model Code" EMF code
> generator. I am using EMF and JFX Databinding to connect Model with UI.
>
> Question was: I would like to do some basic initialization on EClass
> creation, what is the best place to insert it?
That's more of a data binding question then. I'm not sure how your
editor creates new instances. You might set a breakpoint in the
constructor to determine that...
> Already the basic generated code can insert default values in
> attributes, but this doe not work if the value is in an ancestor class
> (to be more precise: the default is in the ancestor and seems not
> changeable in derived classes).
>
> Is there a good place in EMF/ecore or should I initialize EClasses in
> my editor code?
No.
> Putting defaults in ecore would be very nice.
The Ecore model only supports defaults for features and that's a fixed
constant so not really the place to try to do this. Better you
determine how/where your editor creates new instances and do
initialization there...
>
> Thanks again
> Mauro
>
> On 01/08/2013 14:12, Ed Merks wrote:
>> Mauro,
>>
>> Comments below.
>>
>>
>> On 01/08/2013 1:58 PM, Mauro Candarelli wrote:
>>> Thanks Ed,
>>> comments inline.
>>>
>>> On 01/08/2013 09:51, Ed Merks wrote:
>>>> Mauro,
>>>>
>>>> Generally you can do initialization by specializing the objects
>>>> created
>>>> for the child descriptors in the each of the generated
>>>> org.eclipse.emf.edit.provider.ItemProviderAdapter.collectNewChildDescriptors(Collection<Object>,
>>>>
>>>>
>>>> Object).
>>> Uhm, I don't see such a class in my generated code.
>>> NOTE: I'm using only the "Model Code", no edit nor editor.
>> I specifically asked "I suspect your issue is more of one about
>> initializing newly create instances in the editor"...
>>>
>>> I was thinking about hand-modifying methods in XxxFactoryImpl, but
>>> perhaps there's a better way?
>> No, none of such things in the model are a good idea. The base factory
>> behavior shouldn't be changed. It must create uninitialized instances.
>> You could add additional factory methods, but I would have expected
>> that if you're creating things programmatically that you'd populate the
>> new instances correctly and as desired... E.g., for the Ecore model an
>> EClassifier must have a name, but it does no good to just initialize one
>> with "NewClass" in the model, because the name must be populated in a
>> meaningful way by any and all code that's creating Ecore instances.
>>
>> So your use case isn't clear to me. I had assumed an editor is involved
>> and the things you wanted are for the benefit of the user of such an
>> editor, but now you say that's not the case...
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Goto Forum:
Current Time: Tue Apr 23 12:58:06 GMT 2024
Powered by FUDForum. Page generated in 0.04071 seconds |
] 
Search
Help
Register
Login
Home
