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
