Home » Modeling » EMF » CreateChildCommand and EStore
| CreateChildCommand and EStore [message #423193] |
Wed, 24 September 2008 16:52  |
Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Hello !
It's me and my EStore again :o)
Whenever a model object is created, I want to be sure that it has an
EStore set, because all my model objects need to have an EStore.
There's no problem when I use "model" code. But when using commands, (at
the "edit" level,) model objects are created by the framework and
doesn't have any EStore.
I can manually change every "collectNewChildDescriptors" methods (in
every generated ItemProviderAdapters) so that they don't use "standard"
model object creation (AModelFactory.createAnEClass()), but the
"store's" model object creation
(store.create(AModelPackage.Literals.AN_E_CLASS)) instead.
Is it the right place to do this ???
I may also override every "AddCommand"s, so that before it is executed,
I can check that the model object to be added has an EStore...
Is this a better solution ???
Is there another (better) solution ??????
Thanks in advance !!!!!!!!!!!
Stephane
|
|
|
| Re: CreateChildCommand and EStore [message #423195 is a reply to message #423193] |
Wed, 24 September 2008 17:07  |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Stephane,
Comments below.
SWT wrote:
> Hello !
>
> It's me and my EStore again :o)
If only if was an online store with real profits and you shared them. :-P
>
> Whenever a model object is created, I want to be sure that it has an
> EStore set, because all my model objects need to have an EStore.
That's a bit of a problem because model objects are created with a
factory and unless all instances share just one global store you really
don't have a store when you first create them.
> There's no problem when I use "model" code. But when using commands,
> (at the "edit" level,) model objects are created by the framework and
> doesn't have any EStore.
>
> I can manually change every "collectNewChildDescriptors" methods (in
> every generated ItemProviderAdapters) so that they don't use
> "standard" model object creation (AModelFactory.createAnEClass()), but
> the "store's" model object creation
> (store.create(AModelPackage.Literals.AN_E_CLASS)) instead.
>
> Is it the right place to do this ???
I suppose. The CDO approach was to treat the objects as if they were
dynamic objects (the data is stored in the settings as for a dynamic
EObject) and only when the object is attached to the parent is the store
of the parent associated with it. After all, most of the children
created won't actually be used, so you wouldn't want them to be cached
or worse yet, persisted in the store...
>
>
> I may also override every "AddCommand"s, so that before it is
> executed, I can check that the model object to be added has an EStore...
>
> Is this a better solution ???
Maybe Eike will explain how CDO manages this...
>
> Is there another (better) solution ??????
I think so. Methods like ResourceImpl.attached/attachedHelper would be
useful for having the resource associate a store with the object when it
becomes attached to the resource... Again, I think CDO has implemented
quite a nice solution for all this...
>
> Thanks in advance !!!!!!!!!!!
> Stephane
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: CreateChildCommand and EStore [message #423196 is a reply to message #423195] |
Wed, 24 September 2008 17:27 |
| Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Ed,
Comments below :)
Ed Merks wrote :
> Stephane,
>
> Comments below.
>
>
> SWT wrote:
>> Hello !
>>
>> It's me and my EStore again :o)
> If only if was an online store with real profits and you shared them. :-P
Hehe ^^
>>
>> Whenever a model object is created, I want to be sure that it has an
>> EStore set, because all my model objects need to have an EStore.
> That's a bit of a problem because model objects are created with a
> factory and unless all instances share just one global store you really
> don't have a store when you first create them.
Right...
>> There's no problem when I use "model" code. But when using commands,
>> (at the "edit" level,) model objects are created by the framework and
>> doesn't have any EStore.
>>
>> I can manually change every "collectNewChildDescriptors" methods (in
>> every generated ItemProviderAdapters) so that they don't use
>> "standard" model object creation (AModelFactory.createAnEClass()), but
>> the "store's" model object creation
>> (store.create(AModelPackage.Literals.AN_E_CLASS)) instead.
>>
>> Is it the right place to do this ???
> I suppose. The CDO approach was to treat the objects as if they were
> dynamic objects (the data is stored in the settings as for a dynamic
> EObject) and only when the object is attached to the parent is the store
> of the parent associated with it. After all, most of the children
> created won't actually be used, so you wouldn't want them to be cached
> or worse yet, persisted in the store...
If I understand well, in CDO, model objects are dynamic EObjects until they have an EStore set.
This seems to be the best!
How can I mix the two behaviours ?
>>
>>
>> I may also override every "AddCommand"s, so that before it is
>> executed, I can check that the model object to be added has an EStore...
>>
>> Is this a better solution ???
> Maybe Eike will explain how CDO manages this...
Eike, Eike !!! Where are you ?!?! :p
>>
>> Is there another (better) solution ??????
> I think so. Methods like ResourceImpl.attached/attachedHelper would be
> useful for having the resource associate a store with the object when it
> becomes attached to the resource... Again, I think CDO has implemented
> quite a nice solution for all this...
I already did this.
When an EObject is attached to a Resource, I set the store... (and set it back to null when it is detached...)
I also coded the EStore so that whenever a child object is set (on a parent object which is managed by the store),
I check that this child has a store (if it's not the case, I set it...)
Thanks again for your patience !
I hope Eike will read this and help me :)
>>
>> Thanks in advance !!!!!!!!!!!
>> Stephane
|
|
|
| Re: CreateChildCommand and EStore [message #423202 is a reply to message #423196] |
Wed, 24 September 2008 18:29 |
|
Hi Stephane,
Sorry that I forgot what the purpose of your EStore is. Would you mind
to give a short explanation?
In CDO the integration of a model with a backend is mainly based on two
classes:
- CDOObjectImpl:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOObjectImpl.java?revision=1.68&root= Modeling_Project
- CDOStore:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStore.java?root=Modeling_Project&vi ew=co
An important aspect of the design is that each CDOObject has a CDOState
which is managed by the CDOStateMachine:
- CDOState:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOState.java?root=Modeling_Project&view=co
- CDOStateMachine:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStateMachine.java?revision=1.86&roo t=Modeling_Project
If an object is in state TRANSIENT it uses the eSettings array for its
data and in all other states it delegates to the CDOStore.
Cheers
/Eike
SWT schrieb:
> Ed,
>
> Comments below :)
>
> Ed Merks wrote :
>> Stephane,
>>
>> Comments below.
>>
>>
>> SWT wrote:
>>> Hello !
>>>
>>> It's me and my EStore again :o)
>> If only if was an online store with real profits and you shared them.
>> :-P
>
> Hehe ^^
>
>>>
>>> Whenever a model object is created, I want to be sure that it has an
>>> EStore set, because all my model objects need to have an EStore.
>> That's a bit of a problem because model objects are created with a
>> factory and unless all instances share just one global store you
>> really don't have a store when you first create them.
>
> Right...
>
>>> There's no problem when I use "model" code. But when using commands,
>>> (at the "edit" level,) model objects are created by the framework
>>> and doesn't have any EStore.
>>>
>>> I can manually change every "collectNewChildDescriptors" methods (in
>>> every generated ItemProviderAdapters) so that they don't use
>>> "standard" model object creation (AModelFactory.createAnEClass()),
>>> but the "store's" model object creation
>>> (store.create(AModelPackage.Literals.AN_E_CLASS)) instead.
>>>
>>> Is it the right place to do this ???
>> I suppose. The CDO approach was to treat the objects as if they were
>> dynamic objects (the data is stored in the settings as for a dynamic
>> EObject) and only when the object is attached to the parent is the
>> store of the parent associated with it. After all, most of the
>> children created won't actually be used, so you wouldn't want them to
>> be cached or worse yet, persisted in the store...
>
> If I understand well, in CDO, model objects are dynamic EObjects until
> they have an EStore set.
> This seems to be the best!
> How can I mix the two behaviours ?
>
>>>
>>>
>>> I may also override every "AddCommand"s, so that before it is
>>> executed, I can check that the model object to be added has an
>>> EStore...
>>>
>>> Is this a better solution ???
>> Maybe Eike will explain how CDO manages this...
>
> Eike, Eike !!! Where are you ?!?! :p
>
>>>
>>> Is there another (better) solution ??????
>> I think so. Methods like ResourceImpl.attached/attachedHelper would
>> be useful for having the resource associate a store with the object
>> when it becomes attached to the resource... Again, I think CDO has
>> implemented quite a nice solution for all this...
>
> I already did this.
> When an EObject is attached to a Resource, I set the store... (and set
> it back to null when it is detached...)
> I also coded the EStore so that whenever a child object is set (on a
> parent object which is managed by the store),
> I check that this child has a store (if it's not the case, I set it...)
>
> Thanks again for your patience !
> I hope Eike will read this and help me :)
>
>>>
>>> Thanks in advance !!!!!!!!!!!
>>> Stephane
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CreateChildCommand and EStore [message #423224 is a reply to message #423202] |
Thu, 25 September 2008 08:57 |
| Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Eike,
My EStore has quite the same purpose as CDOStore. The two main
differences are that I use WebServices to send and receive model
objects, and that I have quite a complex client-server mapping. I don't
know the other differences in details, because I didn't have much time
to learn CDO (and I'm still an EMF newbie ^^).
Here is the little story (you can directly go to the next chapter ^^) :
After seeing that CDO was not directly usable in my project, I choose to
create my own communication system, but I didn't know about EStore at
that time. After working with proxies for a while, and facing many
problems, Martin told me about EStore. This was the best choice for me
so I changed my design to use EStore. At that time I should have
switched to using CDO (and contributing the additions I needed). But I
didn't, and now it's too late :'(
My "CommEStore" is nearly finished. I'm now facing problems using the
"edit" generated code... That's the cause of this mailing...
For the moment, I'll take a deep look at these classes.
Thanks a lot !
Stephane
Eike Stepper a écrit :
> Hi Stephane,
>
> Sorry that I forgot what the purpose of your EStore is. Would you mind
> to give a short explanation?
>
> In CDO the integration of a model with a backend is mainly based on two
> classes:
>
> - CDOObjectImpl:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOObjectImpl.java?revision=1.68&root= Modeling_Project
>
> - CDOStore:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStore.java?root=Modeling_Project&vi ew=co
>
>
> An important aspect of the design is that each CDOObject has a CDOState
> which is managed by the CDOStateMachine:
>
> - CDOState:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOState.java?root=Modeling_Project&view=co
>
> - CDOStateMachine:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStateMachine.java?revision=1.86&roo t=Modeling_Project
>
>
> If an object is in state TRANSIENT it uses the eSettings array for its
> data and in all other states it delegates to the CDOStore.
>
> Cheers
> /Eike
>
>
>
> SWT schrieb:
>> Ed,
>>
>> Comments below :)
>>
>> Ed Merks wrote :
>>> Stephane,
>>>
>>> Comments below.
>>>
>>>
>>> SWT wrote:
>>>> Hello !
>>>>
>>>> It's me and my EStore again :o)
>>> If only if was an online store with real profits and you shared them.
>>> :-P
>>
>> Hehe ^^
>>
>>>>
>>>> Whenever a model object is created, I want to be sure that it has an
>>>> EStore set, because all my model objects need to have an EStore.
>>> That's a bit of a problem because model objects are created with a
>>> factory and unless all instances share just one global store you
>>> really don't have a store when you first create them.
>>
>> Right...
>>
>>>> There's no problem when I use "model" code. But when using commands,
>>>> (at the "edit" level,) model objects are created by the framework
>>>> and doesn't have any EStore.
>>>>
>>>> I can manually change every "collectNewChildDescriptors" methods (in
>>>> every generated ItemProviderAdapters) so that they don't use
>>>> "standard" model object creation (AModelFactory.createAnEClass()),
>>>> but the "store's" model object creation
>>>> (store.create(AModelPackage.Literals.AN_E_CLASS)) instead.
>>>>
>>>> Is it the right place to do this ???
>>> I suppose. The CDO approach was to treat the objects as if they were
>>> dynamic objects (the data is stored in the settings as for a dynamic
>>> EObject) and only when the object is attached to the parent is the
>>> store of the parent associated with it. After all, most of the
>>> children created won't actually be used, so you wouldn't want them to
>>> be cached or worse yet, persisted in the store...
>>
>> If I understand well, in CDO, model objects are dynamic EObjects until
>> they have an EStore set.
>> This seems to be the best!
>> How can I mix the two behaviours ?
>>
>>>>
>>>>
>>>> I may also override every "AddCommand"s, so that before it is
>>>> executed, I can check that the model object to be added has an
>>>> EStore...
>>>>
>>>> Is this a better solution ???
>>> Maybe Eike will explain how CDO manages this...
>>
>> Eike, Eike !!! Where are you ?!?! :p
>>
>>>>
>>>> Is there another (better) solution ??????
>>> I think so. Methods like ResourceImpl.attached/attachedHelper would
>>> be useful for having the resource associate a store with the object
>>> when it becomes attached to the resource... Again, I think CDO has
>>> implemented quite a nice solution for all this...
>>
>> I already did this.
>> When an EObject is attached to a Resource, I set the store... (and set
>> it back to null when it is detached...)
>> I also coded the EStore so that whenever a child object is set (on a
>> parent object which is managed by the store),
>> I check that this child has a store (if it's not the case, I set it...)
>>
>> Thanks again for your patience !
>> I hope Eike will read this and help me :)
>>
>>>>
>>>> Thanks in advance !!!!!!!!!!!
>>>> Stephane
|
|
|
| Re: CreateChildCommand and EStore [message #423226 is a reply to message #423224] |
Thu, 25 September 2008 09:22 |
|
SWT schrieb:
> Eike,
>
> My EStore has quite the same purpose as CDOStore.
An indication that CDOStore might be used instead of another solution to
the same problem.
> The two main differences are that I use WebServices to send and
> receive model objects, and that I have quite a complex client-server
> mapping.
I don't know what you mean by "client-server mapping" but I can't
remember that you asked how CDO could be used with webservices. Maybe we
had found a nice solution...
> I don't know the other differences in details, because I didn't have
> much time to learn CDO (and I'm still an EMF newbie ^^).
I bet the time you spent with your own solution was more expensive
already ;-)
>
> Here is the little story (you can directly go to the next chapter ^^) :
> After seeing that CDO was not directly usable in my project, I choose
> to create my own communication system, but I didn't know about EStore
> at that time. After working with proxies for a while, and facing many
> problems, Martin told me about EStore. This was the best choice for me
> so I changed my design to use EStore. At that time I should have
> switched to using CDO (and contributing the additions I needed). But I
> didn't, and now it's too late :'(
It's never too late to revise wrong decisions :)
Cheers
/Eike
> My "CommEStore" is nearly finished. I'm now facing problems using the
> "edit" generated code... That's the cause of this mailing...
>
> For the moment, I'll take a deep look at these classes.
> Thanks a lot !
>
> Stephane
>
>
> Eike Stepper a écrit :
>> Hi Stephane,
>>
>> Sorry that I forgot what the purpose of your EStore is. Would you
>> mind to give a short explanation?
>>
>> In CDO the integration of a model with a backend is mainly based on
>> two classes:
>>
>> - CDOObjectImpl:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOObjectImpl.java?revision=1.68&root= Modeling_Project
>>
>> - CDOStore:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStore.java?root=Modeling_Project&vi ew=co
>>
>>
>> An important aspect of the design is that each CDOObject has a
>> CDOState which is managed by the CDOStateMachine:
>>
>> - CDOState:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOState.java?root=Modeling_Project&view=co
>>
>> - CDOStateMachine:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStateMachine.java?revision=1.86&roo t=Modeling_Project
>>
>>
>> If an object is in state TRANSIENT it uses the eSettings array for
>> its data and in all other states it delegates to the CDOStore.
>>
>> Cheers
>> /Eike
>>
>>
>>
>> SWT schrieb:
>>> Ed,
>>>
>>> Comments below :)
>>>
>>> Ed Merks wrote :
>>>> Stephane,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> SWT wrote:
>>>>> Hello !
>>>>>
>>>>> It's me and my EStore again :o)
>>>> If only if was an online store with real profits and you shared
>>>> them. :-P
>>>
>>> Hehe ^^
>>>
>>>>>
>>>>> Whenever a model object is created, I want to be sure that it has
>>>>> an EStore set, because all my model objects need to have an EStore.
>>>> That's a bit of a problem because model objects are created with a
>>>> factory and unless all instances share just one global store you
>>>> really don't have a store when you first create them.
>>>
>>> Right...
>>>
>>>>> There's no problem when I use "model" code. But when using
>>>>> commands, (at the "edit" level,) model objects are created by the
>>>>> framework and doesn't have any EStore.
>>>>>
>>>>> I can manually change every "collectNewChildDescriptors" methods
>>>>> (in every generated ItemProviderAdapters) so that they don't use
>>>>> "standard" model object creation (AModelFactory.createAnEClass()),
>>>>> but the "store's" model object creation
>>>>> (store.create(AModelPackage.Literals.AN_E_CLASS)) instead.
>>>>>
>>>>> Is it the right place to do this ???
>>>> I suppose. The CDO approach was to treat the objects as if they
>>>> were dynamic objects (the data is stored in the settings as for a
>>>> dynamic EObject) and only when the object is attached to the parent
>>>> is the store of the parent associated with it. After all, most of
>>>> the children created won't actually be used, so you wouldn't want
>>>> them to be cached or worse yet, persisted in the store...
>>>
>>> If I understand well, in CDO, model objects are dynamic EObjects
>>> until they have an EStore set.
>>> This seems to be the best!
>>> How can I mix the two behaviours ?
>>>
>>>>>
>>>>>
>>>>> I may also override every "AddCommand"s, so that before it is
>>>>> executed, I can check that the model object to be added has an
>>>>> EStore...
>>>>>
>>>>> Is this a better solution ???
>>>> Maybe Eike will explain how CDO manages this...
>>>
>>> Eike, Eike !!! Where are you ?!?! :p
>>>
>>>>>
>>>>> Is there another (better) solution ??????
>>>> I think so. Methods like ResourceImpl.attached/attachedHelper
>>>> would be useful for having the resource associate a store with the
>>>> object when it becomes attached to the resource... Again, I think
>>>> CDO has implemented quite a nice solution for all this...
>>>
>>> I already did this.
>>> When an EObject is attached to a Resource, I set the store... (and
>>> set it back to null when it is detached...)
>>> I also coded the EStore so that whenever a child object is set (on a
>>> parent object which is managed by the store),
>>> I check that this child has a store (if it's not the case, I set it...)
>>>
>>> Thanks again for your patience !
>>> I hope Eike will read this and help me :)
>>>
>>>>>
>>>>> Thanks in advance !!!!!!!!!!!
>>>>> Stephane
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CreateChildCommand and EStore [message #423227 is a reply to message #423226] |
Thu, 25 September 2008 10:00 |
| Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Eike Stepper wrote :
> SWT schrieb:
>> Eike,
>>
>> My EStore has quite the same purpose as CDOStore.
> An indication that CDOStore might be used instead of another solution to
> the same problem.
>
>> The two main differences are that I use WebServices to send and
>> receive model objects, and that I have quite a complex client-server
>> mapping.
> I don't know what you mean by "client-server mapping" but I can't
> remember that you asked how CDO could be used with webservices. Maybe we
> had found a nice solution...
You're right, I should have asked it. :'( :'(
I'll explain "client-server mapping" :
For instance, I have a "client" class (an EObject). I also have a
"server" class, or more clearly, a DTO class (Data Transfer Object
class) which is equivalent to "CDOClass" (if I'm not mistaken...)
So I "map" each features of the "client" class to the "server" class.
The simple case is when a feature exists on both classes (on the
"server" side, it's not called a feature but a "bean property"...).
There are some cases where a feature on the "client" is mapped by nested
bean properties.
There also are some cases where a feature doesn't exist at all on the
"server" side. But the opposite feature may exist on the "server" side
(and mapped via a bean property), so I can use it to retrieve the
feature value.
If the opposite feature does not exist, I have some other ways to "map"
the feature, that is to say, make the right call on the server side to
get (or set) the feature value... (I won't describe this in detail, but
it's in these case that I have "complex mapping" which is often
project-specific...)
Another case can also be seen : When there is no DTO ("server") class
corresponding to a local model class. I didn't handle this case for the
moment...
It seems that CDO handles all this a bit differently...
>
>> I don't know the other differences in details, because I didn't have
>> much time to learn CDO (and I'm still an EMF newbie ^^).
> I bet the time you spent with your own solution was more expensive
> already ;-)
>
>>
>> Here is the little story (you can directly go to the next chapter ^^) :
>> After seeing that CDO was not directly usable in my project, I choose
>> to create my own communication system, but I didn't know about EStore
>> at that time. After working with proxies for a while, and facing many
>> problems, Martin told me about EStore. This was the best choice for me
>> so I changed my design to use EStore. At that time I should have
>> switched to using CDO (and contributing the additions I needed). But I
>> didn't, and now it's too late :'(
> It's never too late to revise wrong decisions :)
It is too late : My boss won't let me change this now... But he knows
about it, and if I have another project which is based on the same kind
of design later, I will have time to spend on CDO :)
Regards,
Stephane
>
> Cheers
> /Eike
>
>> My "CommEStore" is nearly finished. I'm now facing problems using the
>> "edit" generated code... That's the cause of this mailing...
>>
>> For the moment, I'll take a deep look at these classes.
>> Thanks a lot !
>>
>> Stephane
>>
>>
>> Eike Stepper a écrit :
>>> Hi Stephane,
>>>
>>> Sorry that I forgot what the purpose of your EStore is. Would you
>>> mind to give a short explanation?
>>>
>>> In CDO the integration of a model with a backend is mainly based on
>>> two classes:
>>>
>>> - CDOObjectImpl:
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOObjectImpl.java?revision=1.68&root= Modeling_Project
>>>
>>> - CDOStore:
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStore.java?root=Modeling_Project&vi ew=co
>>>
>>>
>>> An important aspect of the design is that each CDOObject has a
>>> CDOState which is managed by the CDOStateMachine:
>>>
>>> - CDOState:
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOState.java?root=Modeling_Project&view=co
>>>
>>> - CDOStateMachine:
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStateMachine.java?revision=1.86&roo t=Modeling_Project
>>>
>>>
>>> If an object is in state TRANSIENT it uses the eSettings array for
>>> its data and in all other states it delegates to the CDOStore.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>> SWT schrieb:
>>>> Ed,
>>>>
>>>> Comments below :)
>>>>
>>>> Ed Merks wrote :
>>>>> Stephane,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> SWT wrote:
>>>>>> Hello !
>>>>>>
>>>>>> It's me and my EStore again :o)
>>>>> If only if was an online store with real profits and you shared
>>>>> them. :-P
>>>>
>>>> Hehe ^^
>>>>
>>>>>>
>>>>>> Whenever a model object is created, I want to be sure that it has
>>>>>> an EStore set, because all my model objects need to have an EStore.
>>>>> That's a bit of a problem because model objects are created with a
>>>>> factory and unless all instances share just one global store you
>>>>> really don't have a store when you first create them.
>>>>
>>>> Right...
>>>>
>>>>>> There's no problem when I use "model" code. But when using
>>>>>> commands, (at the "edit" level,) model objects are created by the
>>>>>> framework and doesn't have any EStore.
>>>>>>
>>>>>> I can manually change every "collectNewChildDescriptors" methods
>>>>>> (in every generated ItemProviderAdapters) so that they don't use
>>>>>> "standard" model object creation (AModelFactory.createAnEClass()),
>>>>>> but the "store's" model object creation
>>>>>> (store.create(AModelPackage.Literals.AN_E_CLASS)) instead.
>>>>>>
>>>>>> Is it the right place to do this ???
>>>>> I suppose. The CDO approach was to treat the objects as if they
>>>>> were dynamic objects (the data is stored in the settings as for a
>>>>> dynamic EObject) and only when the object is attached to the parent
>>>>> is the store of the parent associated with it. After all, most of
>>>>> the children created won't actually be used, so you wouldn't want
>>>>> them to be cached or worse yet, persisted in the store...
>>>>
>>>> If I understand well, in CDO, model objects are dynamic EObjects
>>>> until they have an EStore set.
>>>> This seems to be the best!
>>>> How can I mix the two behaviours ?
>>>>
>>>>>>
>>>>>>
>>>>>> I may also override every "AddCommand"s, so that before it is
>>>>>> executed, I can check that the model object to be added has an
>>>>>> EStore...
>>>>>>
>>>>>> Is this a better solution ???
>>>>> Maybe Eike will explain how CDO manages this...
>>>>
>>>> Eike, Eike !!! Where are you ?!?! :p
>>>>
>>>>>>
>>>>>> Is there another (better) solution ??????
>>>>> I think so. Methods like ResourceImpl.attached/attachedHelper
>>>>> would be useful for having the resource associate a store with the
>>>>> object when it becomes attached to the resource... Again, I think
>>>>> CDO has implemented quite a nice solution for all this...
>>>>
>>>> I already did this.
>>>> When an EObject is attached to a Resource, I set the store... (and
>>>> set it back to null when it is detached...)
>>>> I also coded the EStore so that whenever a child object is set (on a
>>>> parent object which is managed by the store),
>>>> I check that this child has a store (if it's not the case, I set it...)
>>>>
>>>> Thanks again for your patience !
>>>> I hope Eike will read this and help me :)
>>>>
>>>>>>
>>>>>> Thanks in advance !!!!!!!!!!!
>>>>>> Stephane
|
|
|
Goto Forum:
Current Time: Thu Apr 18 05:34:34 GMT 2024
Powered by FUDForum. Page generated in 0.01676 seconds |
] 
Search
Help
Register
Login
Home
