[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Horizontal extension possibility for e4 tooling
|
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
>
