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
