Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Horizontal extension possibility for e4 tooling

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
>  



Back to the top