On 6/9/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > your further discussion lost me since I only have a vague concept of > what the terms web control and portlet actually mean.
I guess we actually need to establish some difinitions. I searched Struts list but did not find relevant info. If it is there, I would appreciate the link. Microsoft uses term "web control" or "server control" or just a "control" a lot, so I searched on ASP.NET websites for the definition. Microsoft defines web controls as "components that run on the server and encapsulate user-interface and other related functionality." Pretty generic. Digging further: "The page and the server controls it contains are responsible for executing the request and rendering HTML back to the client. Although the communication between the client and the server is stateless and disconnected, the client experience must appear to be that of a continuously executing process. This illusion of continuity is created by the ASP.NET page framework and by the page and its controls." Ok, not they talk about state. A control may have all or some of these characteristics: * View state * Properties * Ability to render itself * Life cycle (see below) * Events * Styles * Design-time functionality * Localization, licensing, and deployment ASP.NET lifecycle of a control: * Initialize * Load view state * Process postback data * Load * Send postback change notifications * Handle postback events * Prerender * Save state * Render * Dispose * Unload For comparison, JSF lifecycle: http://www-128.ibm.com/developerworks/java/library/j-jsf3/ * Retrieve component tree * Store submiteed values * Validate values * Bind values to backing properties * Handle events, invoke methods * Handle navigation * Render components So, based on above information, I would say: * A web control is a server-side component. * Web control is a stateful object. Microsoft calls this state a "view state". * Control can render itself according to its current state. * Control can process input data and events. Based on portlet spec and on my usage of <jsp:include> directive, I will also add: * A control must render itself in response to GET request. Thus, anytime a user refreshes a parent page, the control whould render a proper content. This is a simple alternative to portlet's doView() * A control must use only _one_ URL for GET requests, so that parent page did not have to modify the URL every time. That means, that control can be just "dropped" on a page using one single URL, and then it would render a proper content depending on state. Based on my hatred to POSTDATA messages, I will add: * A control should not frighten a user with POSTDATA messages. * A control should take efforts to prevent double submits. So, in my understanding, a control is a UI-enabled isolated object, which runs on server. As long as it provides a URL to render it, and accepts input data and events (button clicks), we can call it a control I did not say much in this email, did I? ;-)) Implementation details. ----------------------- By default, .NET webapps store state on the client, passing it back and forth in _viewstate hidden field. I guess, the reason for this is to save session memory. I am totally against this kind of state handling for number of reasons, which I got tired to repeat. I prefer to store state on the server. DialogAction stores viewstate in the session-scoped form bean. By doing this, it achieves a "clean" GET request, not polluted by parameters. This allows to use the same GET request for different result pages, thus preventing browser page history from growing. Also, because DialogAction uses redirection, there are no postbacks. All input events occur as a completely separate distinct POST request. There is a logical postback, though, which is every POST request after control has been initialized. The price: DialogAction has to be explicitly initialized. > So what you are saying is that really all you need to do to implement > [clean page history] feature is to keep the struts mapping the same and put > no-cache > instructions in the page header. > > I can do that anyway without using DialogAction, right? It is not just mapping, it is the request that is sent to server. I must reread HTTP specs, but it seems to me that POST request cannot be thrown out by browser, unless it is succeeded by redirect. Maybe I am wrong on this... Anyway, usually you would not have two identical POST requests, since the input data is different. And the data counts, too, not just base URL. You can do that without using DialogAction, and you will build another DialogAction yourself ;-) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
