Jon Wall wrote: > 1. The String/boolean requirement. Everything I'd > tested happened to be String or boolean, but Ted > pointed out this wouldn't work for nested tags. I'm > assuming, then, that the ActionForm performs another > function that I hadn't thought about - converting the > String and boolean props that you're bringing in on > the web to the navtive structure used by the backend. > Is this true? So what you're telling me is...I not > only need to create an ActionForm class for each of my > many components (100+) that actually implements each > of the public methods, but for each of the non > String/boolean properties I need to make a sort of > formatter method.
The ActionForm is really about buffering. It gives the HTML controls persistance, until the data can be validated and/of converted to your native structures. What happens when someone tries to toss "47a" at an Integer property? HTTP is a hostile, uncontrolled environment, and the ActionForms are designed to compensate for that. But keep in mind that ActionForms are just for HTML Form input. They are not expected to be used as anything but buffers for the html form tags. You do not have to use them to retrieve widgets, just to send widgets data they need to store. Once the ActionForm is validated, the BeanUtils can be a very handy way to copy the data over to your native beans. Usually, you just need to define your ActionForm properties to match your native bean property names. The problem is, you need a place to stand if the data fails validation, and can't be transferred to your native beans. There lies the rub. > And keep up with this process with > every new component, and more difficult yet keep up > with every new method on existing components. Eeek. > I know that I can automate this kind of thing...but it > might be enough to keep me from using this framework. > I understand the ROI theory and all that, but the > unfortunate reality is that my development schedule is > way too tight to take time out to work on something > like this. Am I grasping if I ask if there's any > generic tools out there to do something like this? If you find something that works better for you, be sure to report back. We aren't jealous ;-) Adopt and adapt. > 2. This also explains my original troubles with my > Save action I think, because I was trying to nest my > components. The real issue is that i need to call > WidgetForm.setWidget() to initialize my widget's > properties to what is already in the database before > Struts autopopulates the widget properties using > values from the form. My new understanding of the > Struts paradigm (please correct me if I'm wrong) is > that the ActionForm shouldn't nest the components, but > rather should mirror it and not contain the widget at > all. Let Struts autopopulate the ActionForm, and then > use BeanUtils.populate() to copy the info over. In practice, most pre-existing components are not suited for use as a buffer for HTML controls, which is what the ActionForms do. If a component is suited as a buffer for a HTML control, then there is no reason not to nest it. A good candidate for a HTML buffer uses a String or boolean for storage, and can store invalid input before committing it to your model. Generally, most components are designed to do exactly the opposite -- accept or reject input, period. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
