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
