The browsers universally accept HTML documents as output over HTTP, but they do not input HTML or XML, but a simple list of parameters. We've been experimenting with transforming that list into JavaBeans, and I'm not sure that the experiment has succeeded. It made writing tags more convenient but maintaining the JavaBeans has been costly. Especially when, for a lot of teams, the formbeans correspond 1:1 with their model beans, except for a few native parameters.
The list being the CGI parameters ( terminology from my PERL/ CGI days / pre-servlet ) on the servlet request. I assume that the JavaBeans are capturing subset of the servlet request parameter of which they can be an arbitary size. Consider a loginform bean with only username and password, I would argue that you only want to capture these two CGI parameter. You can define a dyna bean for this two. So I disagree that the model design is wrong.
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.
So what you want to is not instantiate or populate a form bean, but transfer the CGI parameters into an XML document object. You want to validate that XML document and then pass that doc to the business tier layer. You are assuming in your business delegate or whereever you have an XML document to EJB or JDO or whatever ValueObject transformation. In other words the XML doc is used to instantiate a business value object and populate it.
I can see that this is flawed, because if you are calling several business tier methods with your XML doc then every call to the business tier involves a transformation. Is this correct? If it is not then you must cache this transformation somewhere?
Secondly you need to alter the taglibs for struts. The standard tags understand a form bean and property. Are you suggesting that the tags are changed or modified to support XPath syntax.
<xmlbean:write path="/myform/mydoc/myproperty" />
Which is what FormProc does. =:0)
Where is this FormProc? What is the URL?
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.
Are you going against advice in your book here? I am sure that you recommend not exposing the model object in your form bean, because some one could fake a primary key or data. For example if you store a value object directly in a action form you then it might expose "employeeId" and "salaryId" unless to make provision to protect these properties.
Also some field in the form bean should be always be Strings and we should perform the conversion between String and Date in the form bean. But if we dont have a form bean, but a list of CGI parameters how do we do this? Is this what your FormProc does? Sounds to me like a fancy hash map of sorts.
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.
Sounds to me like inject intermediate language that is look and feel neutral, between the Struts Action and the view (JSP or Velcity or otherwise)
--////--
-- Peter Pilgrim __ _____ _____ _____ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___//____//____//____/ + Intrinsic Motivation On Line Resume || \\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
