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
