|
|
|
| Re: Reflectively modifying EObjects without notifications [message #411436 is a reply to message #411431] |
Wed, 25 July 2007 16:46   |
Eclipse User |
|
|
|
Ed Merks schrieb:
> Eike,
>
> You can turn notification off with Notifier.eSetDeliver(false).
Since this can occur from a background thread I'm not sure if this is
the best solution but I'll keep that in mind.
> Doing 1/2 a bidirectional update seems tricky. Using
> InternalEObject.eInverseAdd will help, but you don't have control over
> the position.
For to-many features I have a different approach. I use basicAdd() and
basicRemove() methods from InternalEList. Do you think your idea is
better, maybe because of things like feature maps or so?
> If what you're doing is store-based, I'm surprised you need to do this
> kind of thing...
Good point. But I'm currently implementing a new feature. In addition to
models generated for CDO or loaded dynamically (in both cases a store is
used) I start to transparently support arbirtray generated models. And
even Ecore itself. The only things that make it a bit hard are:
1. I can't intercept the accessors before they are executed.
2. Transfering state from the framework to an EObject currently works
reflectively to circumvent the notification. (models generated with
Boolean Flags = true are especially painful)
Maybe I can go with simply suspending notifications via
eSetDeliver(false) as you suggested.
Ah, and setting the resource without inverse update is not nice:
private void transferResourceToTarget(BasicEObjectImpl target,
Resource.Internal resource)
{
Method method = ReflectUtil.getMethod(BasicEObjectImpl.class,
"eSetDirectResource", Resource.Internal.class);
try
{
ReflectUtil.invokeMethod(method, target, resource);
}
catch (InvocationTargetException ex)
{
throw WrappedException.wrap(ex);
}
}
But in general it works quite well. When I'm ready I'll send you a new
Team PSF ;-)
Cheers
/Eike
>
>
> Eike Stepper wrote:
>> Eike Stepper schrieb:
>>> Hi,
>>>
>>> I need to modify the instance state of EObjects reflectively and
>>> there must not occur notifications or inverse updates. Is that
>>> somehow possible?
>> .... and that includes setting the direct containing resource.
>> for the container/containerFeatureID that seems already possible
>> through eBasicSetContainer(), right?
>>
>>>
>>> Cheers
>>> /Eike
>>>
|
|
|
| Re: Reflectively modifying EObjects without notifications [message #411437 is a reply to message #411436] |
Wed, 25 July 2007 17:08 |
| Eclipse User |
|
|
|
Eike,
Comments below.
Eike Stepper wrote:
> Ed Merks schrieb:
>> Eike,
>>
>> You can turn notification off with Notifier.eSetDeliver(false).
> Since this can occur from a background thread I'm not sure if this is
> the best solution but I'll keep that in mind.
Well, if there is a threading problem with this, there will be one with
accessing the actual data anyway I imagine.
>
>> Doing 1/2 a bidirectional update seems tricky. Using
>> InternalEObject.eInverseAdd will help, but you don't have control
>> over the position.
> For to-many features I have a different approach. I use basicAdd() and
> basicRemove() methods from InternalEList. Do you think your idea is
> better, maybe because of things like feature maps or so?
The generated eInverseAdd will call methods like that anyway. It's just
that eInverseAdd works for single or multi valued references.
FeatureMap would need more direct access as you are doing...
>
>> If what you're doing is store-based, I'm surprised you need to do
>> this kind of thing...
> Good point. But I'm currently implementing a new feature. In addition
> to models generated for CDO or loaded dynamically (in both cases a
> store is used) I start to transparently support arbirtray generated
> models. And even Ecore itself. The only things that make it a bit hard
> are:
>
> 1. I can't intercept the accessors before they are executed.
Many folks have wanted something like a read notification, but I think
this would just kill performance in general so it would need to be
optional and once it's optional, you can't generally rely on it anymore...
> 2. Transfering state from the framework to an EObject currently works
> reflectively to circumvent the notification. (models generated with
> Boolean Flags = true are especially painful)
>
> Maybe I can go with simply suspending notifications via
> eSetDeliver(false) as you suggested.
That does seem simplest...
> Ah, and setting the resource without inverse update is not nice:
>
> private void transferResourceToTarget(BasicEObjectImpl target,
> Resource.Internal resource)
> {
> Method method = ReflectUtil.getMethod(BasicEObjectImpl.class,
> "eSetDirectResource", Resource.Internal.class);
>
> try
> {
> ReflectUtil.invokeMethod(method, target, resource);
> }
> catch (InvocationTargetException ex)
> {
> throw WrappedException.wrap(ex);
> }
> }
>
If I added the method to InternalEObject, I'd have to make it public and
that could be a source incompatibility for downstream clients...
> But in general it works quite well. When I'm ready I'll send you a new
> Team PSF ;-)
Sounds cool!
>
> Cheers
> /Eike
>
>
>>
>>
>> Eike Stepper wrote:
>>> Eike Stepper schrieb:
>>>> Hi,
>>>>
>>>> I need to modify the instance state of EObjects reflectively and
>>>> there must not occur notifications or inverse updates. Is that
>>>> somehow possible?
>>> .... and that includes setting the direct containing resource.
>>> for the container/containerFeatureID that seems already possible
>>> through eBasicSetContainer(), right?
>>>
>>>>
>>>> Cheers
>>>> /Eike
>>>>
|
|
|
Powered by
FUDForum. Page generated in 0.04133 seconds
Home