REST/DirectActions is not perfect, personally I use them for "public" stuff, where we only need basic state and we can assume most people will use the back button and that they might fill a form in four hours. I wouldn't use any D2W or "regular stateful" for a public app that is mostly read-only.
As for Dojo/Gianduia/whatever, I see them as Git for Web apps, in the sense that you make changes locally and after that you can send them back to a central source. This is what node.js like: most work done on the client, and the server part is mostly a broker to manage conflicts and act as a datastore and offer "sync services" between apps. > I can see how this could work for simple CRUD stuff. It seems this would > break down when it comes to complex backtracking/flow though. > > Let's say I query -> list -> edit list object -> confirm -> save -> return to > list... that's a lot of backtrack state to maintain in the url/submitted > form. Say I'm at save and need to direct back to the user's list page. I > need to know the qualifier applied to the list, the list batch size, the list > batch index, the list sort orderings, and the authenticated user if any. > Hard, lots of work, but probably not impossible. By the time you get half > way through implementing it, a fat stateful server with D2W isn't looking so > bad. > > Or maybe I edit a relationship and create a new unsaved object related to the > list object. I can't hand that new EO to the confirm page except by temp > global id. If I restart the app on the confirm page... doom! :-) > > Stateless server is the new hotness and sounds great, but it becomes a lot of > work very quickly. I'm sure ERRest helps a lot, but short of some unreleased > fat client like Gianduia, you still end up having to invent all the state > management on the client yourself AFAIK. > > [This is where Pascal points me to his newly released Dojo awesomeness or > something to prove me wrong ;-)] > > Ramsey > > > On Dec 2, 2011, at 9:06 AM, Pascal Robert wrote: > >> >> Le 2011-12-02 à 11:03, Jean-Francois Veillette a écrit : >> >>>> I've seen this before ! >>>> >>>> What you have to do is make sure every significant state can somewhat get >>>> back to the server on the next request. >>>> For user-login you have the cookie. >>>> For specific editing context information, you can get some back in having >>>> eo-id encoded within the form. Like having a text field with a name = >>>> 'Book_01_title' that way, you could deduce that you have a text-field on >>>> the title attribute of an eo of entity Book with 1 as the primary key. >>> >>> They did push the concept further ... >>> they encoded (?bluefish?) those id so that they couldn't be forged. >>> >>> and further still ... but I do not remember it all ! >> >> Or you use ERRest HTML routing :-) >> >>> >>>> For persistency and be session independent, you have to make every action >>>> a direct-action and not require a session. You have to see Session as >>>> optional and not rely on it, just consider it as a cache that can boost >>>> request evaluation >>>> >>>> So with a combination of cookies, direct-action and special form encoded >>>> name you could reconstitute most (if not all) of your context. >>>> >>>> In fact I do not remember the implementation, but it must resemble what I >>>> just described. >>>> >>>> It was presented to me in 2000, it was a WO engineer that developed it for >>>> a client, and he showed us his application running, went to a form page, >>>> started to fill it and then stopped the application and restarted it (so >>>> obviously session id was no longer valid), he then submitted the form and >>>> the client did go along as if nothing happened server side. You can now >>>> imagine a farm of wo apps, if one of the instance goes down, no worries, >>>> another one will take the request and respond. >>>> >>>> >>>> Le 2011-12-02 à 08:47, Mahdi Mankai a écrit : >>>> >>>>> Hi, >>>>> >>>>> Thanks for the reply. >>>>> >>>>> I don't really care about the timed out session. I am more looking for >>>>> restoring my whole context even with a new session. >>>>> >>>>> Ajax won't be helpful for me, because I want to plug such a behaviour to >>>>> an existing complex application. It won't be very convenient to review >>>>> all the forms and components. >>>>> >>>>> Mahdi >>>>> >>>>> On 2011-12-02, at 1:54 PM, Jérémy DE ROYER wrote: >>>>> >>>>>> I dont think its possible, timeout is timeout >>>>>> >>>>>> May be you could auto save the form with ajax and restore it in the new >>>>>> session ? >>>>>> >>>>>> Jeremy DE ROYER >>>>>> >>>>>> Le 2 déc. 2011 à 12:11, Mahdi Mankai >>>>>> <[email protected]> a écrit : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to do something but I am not sure whether it's possible. >>>>>>> >>>>>>> I have a WO application that requires users to login. >>>>>>> >>>>>>> I am storing the user credentials in cookies to avoid having to login >>>>>>> each time. >>>>>>> >>>>>>> I'd like to handle the situation where a user tries to continue working >>>>>>> on the application after his session is timed out. >>>>>>> >>>>>>> Basically, whatever the request is (may be Direct Action or Component >>>>>>> request, with or without form values), I want to get the appropriate >>>>>>> response but with a new session (created using the credentials stored >>>>>>> in cookies). i.e. process the same request but with a different session >>>>>>> or (I don't know if it's possible) restore a timed out session. >>>>>>> >>>>>>> I don't want to extend the session timeout parameter. >>>>>>> >>>>>>> I tried to do something in >>>>>>> handleSessionRestorationErrorInContext(WOContext aContext) in >>>>>>> WOApplication class. But couldn't figure out how to reuse the same >>>>>>> context with a different session. The only thing I was able to do is to >>>>>>> redirect to a specific page. >>>>>>> >>>>>>> For example, I would like users to be able to fill a form, come back >>>>>>> tomorrow, hit save and my application should be able to handle that >>>>>>> smoothly. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Mahdi >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >>> >>> This email sent to [email protected] >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
