Following the Struts perspective, the Command Validator is designed to validate a JavaBean. But, when the input is coming in from HTTP, I don't really want a JavaBean. I want to validate the parameters and, if they pass, then I might want to put them on a JavaBean or a Map, or whatever my business layer expects. If validation fails, I don't really want to display the object I'm validating (following the Validator perspective), I want to redisplay the original input.
What I really want to do is take a list of parameters, validate the parameters, and if they pass, set them to an arbitrary target object. I also don't want to catch every matching parameter, I just want the ones I need for this workflow (or "form"). And, if validation fails, I want to redisplay the original input.
Which is what FormProc does. =:0)
I had to patch the original input list so that it could be exposed. Next I want to make the stock converters bi-directional. So, if it's supposed to take a String like "12/31/2003" and turn it into a Date, I can also hand it a Date and get back a String like "12/31/2003". This way I can pass my Model object to the form and get a list of String parameters to expose to the server page.
When I mentioned XML, I mean define a object deployment descriptor in XML, same as the struts-config.xml, web.xml, and validator.xml. But, neither Validator or FormProc goes far enough. I want a form object that describes everything about the form, so that I could actually hand that object to a tag or Velocimacro or something and have it render a default HTML input form for me, just as we hand it the output from that form so that it can tender a default validation.
-Ted.
Peter A. Pilgrim wrote:
Ted Husted wrote:
I working on something similar right now too, but using the FormProc package. I believe that we should represent entire input form in XML, including things like the default control type and field labels, and so forth, along with prompts, error messages, validations, and type conversions. Ideally, we should be able to write a default form just by reference to an XML element.Ted
What I like about FormProc is that is not focussed on JavaBeans, but on the process of validating a list of parameters against a form definition and then transferring the validated properties to some target object. The object can also be a Map, which makes for a very nifty hand-off to something like a Context. =:)
In fact, expanding on the DynaForm idea, it might also be possible to create a type-safe Context backed by a XML-configured form object. We could then use the same XML document on both layers. On the presentation layer, it can generate and/or validate the data-entry form. On the business layer, it can define the properties expected by a Context.
Of course, this is much like what we've been talking about doing for the Validator, but right now the emphasis there seems to be on the JavaBean and moving away from the form, where I believe we should be emphasizing the form and moving away from (pure) JavaBeans.
You lost me over the architecture. What I dont understand is that the current browsers are communicating HTML on HTTP. So how in the first do you get XML in the front end? Are proposing that there are new types of browsers that communicate exclusively XML over HTTP?
If so then it makes for interesting future, where the HTTP request representing
a HMTL Form for example, a POST method, is a XML document and the output
is XML.
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
