[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Horizontal extension possibility for e4 tooling
|
I'd leave it if it works ;-)
Tom
On 05.02.14 10:49, Marco Descher wrote:
> Hy Tom,
>
> thanks for your hint! With your hint from yesterday I found a solution using
> a custom IValueChangeListener on the IObservables where I use AddCommand and SetCommand (see enclosed)!
>
> So I guess I will rework it again, by considering your EFMListProperty.
>
> Thanks for your help,
> marco
>
>
> An 05. Februar 2014 at 10:28:29, Tom Schindl (tom.schindl@xxxxxxxxxxxxxxx) schrieb:
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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
