Conflicting requirements for software development were always there. And what you say is conflicting with what I was describing. You are not supposed to open a structured binary file with a version of a software that is not compatible with it, unless you assured at least some backwards compatibility. This is not a pattern that was invented today, it is there since software was developed. The same is with loading widget states. If you make it sure that you keep backwards compatibility, newer version of the software should be open older states. If you do not have backwards compatibility in mind, then you should just refuse to load "old" state with "new" version. The compatibility could be kept at widget level as well. Would be stupid not to load a full widget hierarchy just because one of the leaf widgets changed software version...
On Wed, Mar 17, 2010 at 12:16 PM, Onur Tugcu <[email protected]> wrote: > Hi, > > About saving widget states, what happens with actively developed pages? > For example you somehow hid the details of reloading widget states, then the > widgets on the page is changed and the page is published for testing or > release, what happens when the page is reloaded by the user whose widget > state was saved? > > This might lead to strange development and release bugs if not careful. > > On Wed, Mar 17, 2010 at 11:50 AM, mobi phil <[email protected]> wrote: >> >> Hello, >> >> I wonder what would be the best strategy to save and load the session >> of a user, better say it's WTApplication state, mainly widget tree. >> This would be very useful in two different scenarios: >> >> 1. The user might be able to continue his work in a later session >> (having the same state of widget as much as possible, for example if a >> lazily loaded item is loaded, the that should be loaded etc.), after >> logged out and relogged in. >> >> 2. If one would deploy WT applications on shared hosting (what I >> probably do soon), there are some stupid robots that kill your >> applications depending on memory usage, time, etc. hell knows what >> algo. Once the WT app (fcgi) is killed, whatever the user would do, he >> will be redirected to the homepage. This effect of course does not >> happen when used with non-ajax or stateless sessions. >> >> As mentioned the idea would be to store mainly the widget tree with >> minimal overhead. When the application or session is restarted for >> whatsoever reason, based on some cookie, WT should be able to >> reconstruct the tree based on the stored information. Of course it >> would make less sense to store data, but just the tree and ID's to >> data, data could be and should be recovered from the database (it >> makes sense as inbetween data in the database could change). >> >> I would put this in the suggestions list. >> >> -- >> rgrds, >> mobi phil >> >> being mobile, but including technology >> http://mobiphil.com >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> witty-interest mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/witty-interest > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest > > -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
