On 7/14/05, Ted Husted <[EMAIL PROTECTED]> wrote: > <<Switching to dev list>> > > On 7/13/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > On 7/13/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > > Most importantly, I'd make very sure that all my "code-behind > > > ActionForms" were request scope, probably by changing the factory > > > default. > > > > In this case this form would not be stateful. At least for me, it is > > the whole point of sticking data and behavior and state in one place. > > Redirection does not work well with request scope. And redirection is > > the must to cleanly separate input phase from output phase. > > Yes, a stateful page mitigates the need to redirect. The workflow > becomes less reliant on URIs and more reliant on the state of the > controls. Using techniques like hidden panels, many workflows that > consume multiple stateless pages, can be done via one stateful page > with multiple panels. > > If I wanted to add a "viewstate" to Struts Classic, then I might > serialize the ActionForm to the page, probably by extending the > html:form tag. It already writes one hidden field to support > single-submits, why not have it write another to retain the original > ActionForm? For 1.2.x, the ActionForm could be deseralized as part of > validate, being sure to not overwrite any non-null fields. For 1.3.x, > the catalog could be amended to deserialize the ActionForm before > populating it from the request.
You mean, to have analog of _viewstate in ASP.NET? I know that JSF supports it too, but in JSF state is saved on server by default, which is a relief. JSF backing beans have "session" scope by default, no hidden fields are used. Thus, you are free to leave the application, browse somewhere else, and then return back. And separation between input and output is a snap, just add <redirect> element in the navigation rule, and voila! The view will be loaded with a separate GET request, and will be rendered using data, stored on the server. I would switch to JSF only for that. Thus, JSF [in its default configuration] allows to produce more robust and more user-friendly apps then ASP.NET and Struts [in their default configuration]. Contrary, with _viewstate it is impossible to use two-phase request processing. Microsoft geniuses thought that storing data in the session puts too much load on a web farm, so they decided to spread the load over the Net. Of course, they themselves knew different ways to track the state, and they suggested to developers to weigh all pro and cons and either use _viewstate, or turn it off and use session or even persisted-to-database data to track the state. But who would bother analysing, if most examples of ASP.NET code is based on _viewstate? The consequences are devastating: * tens of kilobytes of useless junk (especially if you display bunch of rows of data) are moved around the wire * all pages must be HTML forms to store hidden fields * a user cannot jump out from the application, and then navigate back using direct URL in the address bar, because there is nothing in the session * result page is returned immediately in response to submitted HTML form to keep hidden fields, thus clean page reload is impossible and results in double submit. * It is impossible to get read of POSTDATA situation, though it can be processed on the server. * Overall user experience is horrid. My friend works in a company, which uses ASP.NET for a pretty large project with warehouse, shopping carts, etc. They do not use _viewstate. Instead, they store data from each request in the database. Expensive? Maybe. But it is much easier to add more database servers in the cluster. Database clustering is very robust, and from an application point of view, they still use one single database, so the app structure is very simple. Even storing data in the session is not *that* expensive. Servers are cheap, memory is cheap. If needed, I would call Cameron to haggle over the price for Coherence ;) Anyway, conceptually storing state on server is better. If a problem can be solved by adding more memory, this is not a problem, after all. Microsoft proves it with every Windows release. Applications are made for users. Storing state on server provides better user experience. The choice should be clear. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
