| Swapping EStores [message #411314] |
Mon, 23 July 2007 07:39  |
|
Hi,
Maybe I asked a similar question before but I couldn't find a thread
anymore.
EStoreEObjectImpl has got an eSetStore() method (even InternalEObject)
which connects the instance to or disconnects it from an EStore.
Unfortunately it is only usable *before* state has been set to the instance.
After lists habe been created lazily it is not possible anymore to
change the store because the it is stored in member fields of the lists.
There is even not a setter to change the list store after construction ;-(
With this implementation I'll have to iterate over the eSettings of the
EStoreEObjectImpl and reflectively change the eStore field.
Maybe I can overwrite createList() and createFeatureMap() to provide
collections with a setter method that can be used after explicit
downcasting.
I'm not sure if at all there is a use case for different stores in
EStoreEObjectImpl and its internal collections.
It would at least be much nicer if abstract superclasses of these
collections were provided that have an abstract eStore() method that I
could implement to return the store of the owner.
What do you think?
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Swapping EStores [message #411315 is a reply to message #411314] |
Mon, 23 July 2007 07:50  |
|
This is a multi-part message in MIME format.
--------------020903030208020807080402
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Oh no:
public static class EStoreFeatureMap extends DelegatingFeatureMap
{
protected *final *InternalEObject.EStore store;
...
Hmm, whether reflection can trick this one???
Eike Stepper schrieb:
> Hi,
>
> Maybe I asked a similar question before but I couldn't find a thread
> anymore.
>
> EStoreEObjectImpl has got an eSetStore() method (even InternalEObject)
> which connects the instance to or disconnects it from an EStore.
> Unfortunately it is only usable *before* state has been set to the
> instance.
> After lists habe been created lazily it is not possible anymore to
> change the store because the it is stored in member fields of the lists.
> There is even not a setter to change the list store after construction
> ;-(
> With this implementation I'll have to iterate over the eSettings of
> the EStoreEObjectImpl and reflectively change the eStore field.
> Maybe I can overwrite createList() and createFeatureMap() to provide
> collections with a setter method that can be used after explicit
> downcasting.
>
> I'm not sure if at all there is a use case for different stores in
> EStoreEObjectImpl and its internal collections.
> It would at least be much nicer if abstract superclasses of these
> collections were provided that have an abstract eStore() method that I
> could implement to return the store of the owner.
>
> What do you think?
>
> Cheers
> /Eike
>
--------------020903030208020807080402
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Oh no:<br>
<br>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: Swapping EStores [message #411323 is a reply to message #411319] |
Mon, 23 July 2007 13:56 |
|
Ed Merks schrieb:
> Eike,
>
> Perhaps base classes that simply fetch the store from the owner would
> be a good idea.
Shall I open an Enhancement request?
> I suppose it's also possible to use a store than can itself be
> redirected to talk to different data sources.
I already do something like that. My stores don't store the model values
themselves, i.e. they don't store instance specific state. But they have
some other data related that is common for certain groups of instances.
>
>
> Eike Stepper wrote:
>> Hi,
>>
>> Maybe I asked a similar question before but I couldn't find a thread
>> anymore.
>>
>> EStoreEObjectImpl has got an eSetStore() method (even
>> InternalEObject) which connects the instance to or disconnects it
>> from an EStore.
>> Unfortunately it is only usable *before* state has been set to the
>> instance.
>> After lists habe been created lazily it is not possible anymore to
>> change the store because the it is stored in member fields of the lists.
>> There is even not a setter to change the list store after
>> construction ;-(
>> With this implementation I'll have to iterate over the eSettings of
>> the EStoreEObjectImpl and reflectively change the eStore field.
>> Maybe I can overwrite createList() and createFeatureMap() to provide
>> collections with a setter method that can be used after explicit
>> downcasting.
>>
>> I'm not sure if at all there is a use case for different stores in
>> EStoreEObjectImpl and its internal collections.
>> It would at least be much nicer if abstract superclasses of these
>> collections were provided that have an abstract eStore() method that
>> I could implement to return the store of the owner.
>>
>> What do you think?
>>
>> Cheers
>> /Eike
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: Swapping EStores [message #411325 is a reply to message #411324] |
Mon, 23 July 2007 14:26 |
|
Ed,
I entered this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
Somehow I hit Enter before the summary was complete ;-(
It should be "Provide stateless EstoreEList and EStoreFeatureMap base classes"
Cheers
/Eike
Ed Merks schrieb:
> Eike,
>
> Yes, please open an enhancement request.
>
>
> Eike Stepper wrote:
>> Ed Merks schrieb:
>>> Eike,
>>>
>>> Perhaps base classes that simply fetch the store from the owner
>>> would be a good idea.
>> Shall I open an Enhancement request?
>>
>>> I suppose it's also possible to use a store than can itself be
>>> redirected to talk to different data sources.
>> I already do something like that. My stores don't store the model
>> values themselves, i.e. they don't store instance specific state. But
>> they have some other data related that is common for certain groups
>> of instances.
>>
>>>
>>>
>>> Eike Stepper wrote:
>>>> Hi,
>>>>
>>>> Maybe I asked a similar question before but I couldn't find a
>>>> thread anymore.
>>>>
>>>> EStoreEObjectImpl has got an eSetStore() method (even
>>>> InternalEObject) which connects the instance to or disconnects it
>>>> from an EStore.
>>>> Unfortunately it is only usable *before* state has been set to the
>>>> instance.
>>>> After lists habe been created lazily it is not possible anymore to
>>>> change the store because the it is stored in member fields of the
>>>> lists.
>>>> There is even not a setter to change the list store after
>>>> construction ;-(
>>>> With this implementation I'll have to iterate over the eSettings of
>>>> the EStoreEObjectImpl and reflectively change the eStore field.
>>>> Maybe I can overwrite createList() and createFeatureMap() to
>>>> provide collections with a setter method that can be used after
>>>> explicit downcasting.
>>>>
>>>> I'm not sure if at all there is a use case for different stores in
>>>> EStoreEObjectImpl and its internal collections.
>>>> It would at least be much nicer if abstract superclasses of these
>>>> collections were provided that have an abstract eStore() method
>>>> that I could implement to return the store of the owner.
>>>>
>>>> What do you think?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.02126 seconds
] 
Search
Help
Register
Login
Home
