[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Horizontal extension possibility for e4 tooling
|
Have you looked how we deal with the persistedState in the UI? Although
it is an implementation detail IIRC EMF-Maps are internally an EList as
well, so you can observe them using EMFListProperty ;-)
Tom
On 04.02.14 13:12, Marco Descher wrote:
> Hy Tom,
>
> guess I can. Thank you for your hint .. currently I’m getting crazy on such a „simple“ problem of having the Map entry databinded …
>
> all the best!
>
> An 04. Februar 2014 at 12:26:44, Tom Schindl (tom.schindl@xxxxxxxxxxxxxxx) schrieb:
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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
>
