Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Horizontal extension possibility for e4 tooling

Why can't you take part of the lifecycle? Correct me if I'm wrong but
dirty tracking is simply done by the EMF-Command-Stack and you can
execute commands naturally yourself (You should have an EditingDomain
available everywhere - without it you can't create the observables).

Look into the editor where we implemented persistedState handling and
you'll see how that works ;-)

Tom

On 04.02.14 12:15, Marco Descher wrote:
> Hy list, [digresses into databinding]
> 
> to store the elements in persistentState seems good, however there does not seem to be a proper solution to EMFEditDatabinding when it comes to a probably existing entry in this map. I found some entries in the net, with http://www.eclipse.org/forums/index.php/m/1239495 being the most complete. If I don’t find
> a databinding this way, I cannot participate in the isDirty() of the main part, which brings up the problem again it seems.
> 
> Tom made an approach in https://github.com/tomsontom/emf-databinding-example/blob/master/org.eclipse.emf.databinding.edit/src/org/eclipse/emf/databinding/edit/EMFEditObservables.java to provide the requested functionality; this does not work for the following reason:
> 
> o I have a writableValue, which is null on initialization, s.t. observeMapValue on (EObject) master.getValue() crashes with NPE. So it would need an observeMapDetailValue
> o The entry may or may not exist, s.t. the indexOf may fail, crashing the method.
> 
> If persistentState should be usable like that I guess we have to roll-up the databinding problem again :(
> 
> thanks guys,
> marco
> 
> 
> An 03. Februar 2014 at 20:03:24, Tom Schindl (tom.schindl@xxxxxxxxxxxxxxx) schrieb:
>>  
>> Well for the model it is just a big text-block in an attribute so  
>> the
>> overhead should be ok if it's not gigabyte of data including binaries  
>> who have to escaped useing Basic64
>>  
>> Tom
>>  
>> On 03.02.14 19:58, Marco Descher wrote:
>>> Hy Eric, Tom,
>>>
>>> thanks a lot for the information! I’m gonna try this at once!  
>> So I guess that the save thingy is not
>>> going to be needed anyways, as the persistentData should provide  
>> a solution for any case. - Just as I am curious
>>> if the e4xmi file is going to get bloated by persistedState,  
>> will this have consequences to the application performance?  
>>>
>>> Wim, thanks for your approach, I’m gonna take a look at it nevertheless  
>> the persistedState solution!!
>>>
>>> cheers,
>>> marco
>>>
>>> An 03. Februar 2014 at 19:41:08, Tom Schindl (tom.schindl@xxxxxxxxxxxxxxx)  
>> schrieb:
>>>>
>>>> On 03.02.14 19:36, Tom Schindl wrote:
>>>>> Hm - ok I see so the best solution would if we'd have a slot in  
>> the
>>>>> application model which takes an EObject. I doubt we can get  
>>>> something
>>>>> like this in into the model at this point of the lifecycle,  
>> we
>>>> need
>>>>> something like
>>>>>
>>>>> EMap metaData
>>>>>
>>>>
>>>> I revert that - it seems to danagerous to store EObjects because  
>>>> we
>>>> probably can't load the model but like Eric pointed out you  
>> could
>>>> serialize your model as XMI and store it inside the persistedState.  
>>>>
>>>> Tom
>>>> _______________________________________________
>>>> e4-dev mailing list
>>>> e4-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>>
>>>
>>> _______________________________________________
>>> e4-dev mailing list
>>> e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>
>>  
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>  
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 



Back to the top