| Re: [e4-dev] Horizontal extension possibility for e4 tooling |
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 >
Attachment:
PersistedStateValueChangeListener.java
Description: Binary data