Jon Wall wrote: > > I've been lurking on this list for a while, and I > finally have time to look hard at Struts for a web > application that I'm working on. I have a coupla > questions.. 1. This first question I found reference > to in the archives > (http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html) > but couldn't find an answer.
We tried making the ActionForm an interface in the first place, but, in practice, there were simply too many side effects. http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg03590.html http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html If your JavaBean only uses String and boolean properties, and doesn't make immediate state changes to your model, you can nest it and use the dotted syntax. Otherwise, it's a wild goose chase. > In the application I'm > working on the business logic is already written and > is being added to by another team (it's supporting > other applications besides the web). So I've got a > whole slew of JavaBeans (100+) already written for me, > but now I'm facing the task of wrapping them in > ActionForm subclasses, cursing under my breath that it > isn't an interface. I understand that the purpose of > the ActionForm is as a buffer..perform validation and > all that. But my beans already contain the validation! > Besides, performing the validation in the ActionForm > is effectively tying business logic (data validation) > to the web framework dontya think? It's really more about correction than validation. The validate method can wrap methods from the business layer, or the Action can do that instead and then return the ActionForm itself. But the main thing is that most existing beans expect native types that can't be properly represented by a HTML control. Your beans may contain validation, but can they return the invalid input to the user for correction? That's what ActionForms are for. To buffer data so it ~can be~ validated, and returned for correction if it is not. So, you take the data from the ActionForm, and present it to your bean. If your bean rejects it, you use the ActionForm to ferry the whole she-bang back to the user, so they can fix it and try again. The ActionForm also serves as firewall, since the autopopulation mechanism can be used to affect any public method on your JavaBean, not just the ones you put on the form. This is exploitable by a hostile user. > Rules such as no > invoice numbers under 1000 (Ted's example) should be > handled by the business logic, and given my situation > (probably a common one), this logic needs to be shared > between applications. I can't go into the server > system and fit ActionForm into the class heirarchy, > but I sure could have thrown an interface in there. It should not be in your heirarchy, but used to transfer data *to* your heirarchy. One good way to do this is to match the ActionForm properties to the properties on your JavaBeans, and use the reflection methods in BeanUtils to punch it over. If you put describe and populate together, you can populate just about anything from just about anything. > Input on this is appreciated. 2. This has to have come > up before, but I couldn't find any references. All of > my JavaBeans map to persistent components, all of > which have id's. I've written some actions to display > lists of these components and the like and everything > works great. I also started to try the Add/Edit/Save > pattern, which occurs everywhere in the app, and I'm > having a problem with the Save action. The issue is > that I need to retrieve the object from the datastore > (using the id) *before* the ActionForm is populated > with the request parameters. > What I'd like is to have > the bean populated from the database, and then any > parameters that are present on the request object set > on the bean, then persist. I can't figure out how to > initialize the bean to the datastore before it gets to > me in the Action. Go to the Action first, populate the ActionForm and then forward to the JSP. The form tags will see the ActionForm, and use it to populate themselves. Then when the form is submitted, it is populated from the request parameters "again", closing the loop. -- 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]>
