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 ([email protected]) > 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 ([email protected]) >> 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 >>>>> ([email protected]) >>>> 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 >>>>>>> ([email protected]) >>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> e4-dev mailing list >>>>>>> [email protected] >>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> e4-dev mailing list >>>>>> [email protected] >>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> e4-dev mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>> >>>> >>>> _______________________________________________ >>>> e4-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>> >>> >>> _______________________________________________ >>> e4-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>> >> >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> >> >> >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
