|
| Re: "Stale" attribute values on a proxy [message #687528 is a reply to message #687527] |
Wed, 22 June 2011 03:09   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dan,
Comments below.
Dan Pollitt wrote:
> In our EMF-based Eclipse application we have an in-memory instance of
> the application's domain model that is the preferred location for
> application components to interrogate or listen to the model. That
> model instance is backed by a single ResourceSet. The application
> currently uses xmi serialization to several resource files.
>
> To cope with changes to the persisted model that happen outside of the
> in-memory objects (for example by an editor that uses it's own
> ResourceSet so that changes made in the editor are isolated until
> saved), we recently enhanced the application to listen for workspace
> changes to files backing resources in our ResourceSet. When detected
> those resources that were modified are unloaded (much like in the
> generated sample editor code).
>
> We want to allow parts of the application to retain references to
> model objects and be unaware of the concepts of loading/proxying. They
> should also be allowed to attach adapters for change notification and
> expect those to be active for the life of the application.
>
> The resource unloading gets us part of the way - the referenced model
> objects held by the app are set to be proxies, navigating references
> from the retained reference after an unload causes the referenced
> objects to be resolved, and the newly loaded object's state reflects
> that of the latest persistant form. The main problems are around the
> retained reference to a now proxy model object:
>
> - The attribute values of this object remain as before the object was
> unloaded, these values can now be stale (differ from newer persistent
> form).
Definitely. They'll only change if you change them, but that would be
kind of pointless...
> - If a navigation is performed across the model to the "same" object
> to which the reference is held (loading as we go) they will be
> different objects.
Definitely. Proxies are resolved by replacing the reference with a
reference to the actual different resolved object.
>
> I wanted to see if there was something we were missing to enable us to
> both keep references to model objects but also reload them if they
> change externally but with the elements of the application holding the
> references being ignorant of what's going on behind the scenes. I
> don't want them to have to deal with URIs/resolving etc.
Anything that's directly referencing objects will notice that the object
has become a proxy and will need to do something; note that unloading
will remove all adapters on the object, so that's one way to find out
it's time to look for the new resolved replacement.
>
> One idea that was discussed briefly was wrapping the model object
> instances in a delegating proxy object that swapped out the delegate
> reference for a new one (and moving across adapters etc) when a
> reference or a proerty was accessed and the wrapped instance had been
> turned into a proxy. I think this would be relatively simple to do but
> don't want to set off down that road if there's just a better way to
> use the EMF APIs out of the box.
No, that's pretty much the only type of approach.
>
> Looking forward to hearing your thoughts,
>
> Thanks,
> Dan
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: "Stale" attribute values on a proxy [message #687530 is a reply to message #687528] |
Wed, 22 June 2011 06:04 |
Dan Pollitt
Messages: 55
Registered: August 2010 |
Member |
|
|
Hi Ed,
Ok - thanks for the quick response, we'll start investigating the
wrapping approach.
Dan
On 22/06/2011 04:09, Ed Merks wrote:
> Dan,
>
> Comments below.
>
>
> Dan Pollitt wrote:
>> In our EMF-based Eclipse application we have an in-memory instance of
>> the application's domain model that is the preferred location for
>> application components to interrogate or listen to the model. That
>> model instance is backed by a single ResourceSet. The application
>> currently uses xmi serialization to several resource files.
>>
>> To cope with changes to the persisted model that happen outside of the
>> in-memory objects (for example by an editor that uses it's own
>> ResourceSet so that changes made in the editor are isolated until
>> saved), we recently enhanced the application to listen for workspace
>> changes to files backing resources in our ResourceSet. When detected
>> those resources that were modified are unloaded (much like in the
>> generated sample editor code).
>>
>> We want to allow parts of the application to retain references to
>> model objects and be unaware of the concepts of loading/proxying. They
>> should also be allowed to attach adapters for change notification and
>> expect those to be active for the life of the application.
>>
>> The resource unloading gets us part of the way - the referenced model
>> objects held by the app are set to be proxies, navigating references
>> from the retained reference after an unload causes the referenced
>> objects to be resolved, and the newly loaded object's state reflects
>> that of the latest persistant form. The main problems are around the
>> retained reference to a now proxy model object:
>>
>> - The attribute values of this object remain as before the object was
>> unloaded, these values can now be stale (differ from newer persistent
>> form).
> Definitely. They'll only change if you change them, but that would be
> kind of pointless...
>> - If a navigation is performed across the model to the "same" object
>> to which the reference is held (loading as we go) they will be
>> different objects.
> Definitely. Proxies are resolved by replacing the reference with a
> reference to the actual different resolved object.
>>
>> I wanted to see if there was something we were missing to enable us to
>> both keep references to model objects but also reload them if they
>> change externally but with the elements of the application holding the
>> references being ignorant of what's going on behind the scenes. I
>> don't want them to have to deal with URIs/resolving etc.
> Anything that's directly referencing objects will notice that the object
> has become a proxy and will need to do something; note that unloading
> will remove all adapters on the object, so that's one way to find out
> it's time to look for the new resolved replacement.
>>
>> One idea that was discussed briefly was wrapping the model object
>> instances in a delegating proxy object that swapped out the delegate
>> reference for a new one (and moving across adapters etc) when a
>> reference or a proerty was accessed and the wrapped instance had been
>> turned into a proxy. I think this would be relatively simple to do but
>> don't want to set off down that road if there's just a better way to
>> use the EMF APIs out of the box.
> No, that's pretty much the only type of approach.
>>
>> Looking forward to hearing your thoughts,
>>
>> Thanks,
>> Dan
|
|
|
| Re: "Stale" attribute values on a proxy [message #687531 is a reply to message #687528] |
Wed, 22 June 2011 06:06 |
Dan Pollitt
Messages: 55
Registered: August 2010 |
Member |
|
|
Hi Ed,
Ok - thanks for the quick response, we'll start investigating the
wrapping approach.
Dan
On 22/06/2011 04:09, Ed Merks wrote:
> Dan,
>
> Comments below.
>
>
> Dan Pollitt wrote:
>> In our EMF-based Eclipse application we have an in-memory instance of
>> the application's domain model that is the preferred location for
>> application components to interrogate or listen to the model. That
>> model instance is backed by a single ResourceSet. The application
>> currently uses xmi serialization to several resource files.
>>
>> To cope with changes to the persisted model that happen outside of the
>> in-memory objects (for example by an editor that uses it's own
>> ResourceSet so that changes made in the editor are isolated until
>> saved), we recently enhanced the application to listen for workspace
>> changes to files backing resources in our ResourceSet. When detected
>> those resources that were modified are unloaded (much like in the
>> generated sample editor code).
>>
>> We want to allow parts of the application to retain references to
>> model objects and be unaware of the concepts of loading/proxying. They
>> should also be allowed to attach adapters for change notification and
>> expect those to be active for the life of the application.
>>
>> The resource unloading gets us part of the way - the referenced model
>> objects held by the app are set to be proxies, navigating references
>> from the retained reference after an unload causes the referenced
>> objects to be resolved, and the newly loaded object's state reflects
>> that of the latest persistant form. The main problems are around the
>> retained reference to a now proxy model object:
>>
>> - The attribute values of this object remain as before the object was
>> unloaded, these values can now be stale (differ from newer persistent
>> form).
> Definitely. They'll only change if you change them, but that would be
> kind of pointless...
>> - If a navigation is performed across the model to the "same" object
>> to which the reference is held (loading as we go) they will be
>> different objects.
> Definitely. Proxies are resolved by replacing the reference with a
> reference to the actual different resolved object.
>>
>> I wanted to see if there was something we were missing to enable us to
>> both keep references to model objects but also reload them if they
>> change externally but with the elements of the application holding the
>> references being ignorant of what's going on behind the scenes. I
>> don't want them to have to deal with URIs/resolving etc.
> Anything that's directly referencing objects will notice that the object
> has become a proxy and will need to do something; note that unloading
> will remove all adapters on the object, so that's one way to find out
> it's time to look for the new resolved replacement.
>>
>> One idea that was discussed briefly was wrapping the model object
>> instances in a delegating proxy object that swapped out the delegate
>> reference for a new one (and moving across adapters etc) when a
>> reference or a proerty was accessed and the wrapped instance had been
>> turned into a proxy. I think this would be relatively simple to do but
>> don't want to set off down that road if there's just a better way to
>> use the EMF APIs out of the box.
> No, that's pretty much the only type of approach.
>>
>> Looking forward to hearing your thoughts,
>>
>> Thanks,
>> Dan
|
|
|
Powered by
FUDForum. Page generated in 0.03171 seconds
] 
Search
Help
Register
Login
Home
