On Tue, 12 Oct 2004 13:29:40 -0700, Martin Cooper wrote: > * The request may not have come from a form or a link; it may have > been submitted using an XMLHttpRequest object. In such cases, forms > as we talk about them are not relevant. Instead, we may want to > provide the request input in the form of a DOM. We may also want to > think about how to handle input validation in a consistent way > across different types of requests.
+1 Conceptually, the FormContext is a type of DOM, and it would also express input validation in a consistent way, within the same model. It's the skeleton requirements of the form, without any of the markup chrome. An object that tells the view what is needs to know, without dictating how the view will render the information. (I did mention a default control attribute, but that would be a platform-independent descriptor, like the ones used by Faces. And, of course, the View could always ignore the "control" advice.) We already have to all the form information at hand, but today it's scattered about. Some specifications are on the page, some are in this Java object, and others are in this XML document or that XML document. I use the word "Form" because it is familiar and concise. But the same context could also be used to create a non-visual response, like a SOAP message to another application. The point is that the response rendering entity would have whatever it needs to know "at its fingertips". > * The response may not be HTML, even when it's headed for the > browser. It might be XML or even JavaScript code, serialised from a > data structure, and to be interpreted / evaluated in the browser. +1 The response may even be a unit test report. :) I'm just saying that the primary "response" from the framework should be a ViewContext that encapsulates the Struts API. This can then be passed to whatever rendering agent is needed. If the response is going out to a HTML page, then it can be passed in the HTTP response. If it is going somewhere else, the same ViewContext can be passed in a different way, but present a consistent interface. > * Many - perhaps even most - requests are not page-replacement > requests. That is, the response is not a complete HTML page or > frame to replace the one the request was submitted form. > > * The response may not correspond to a page or a frame. Instead, it > might be destined for a particular piece of the page (e.g. a div > element). This allows for partial page updates in interactive > applications. +1 A very good way to empower these type of response rendering agents is to expose Struts as a coherent view context. Of course, the actual view rendering (if any) is outside the scope of the Controller framework. Our job is to provide the View the data it needs to render itself. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
