Hi Ted - Thanks for the input. A light went on when I read this...I'd initially wanted to just include my existing components in a thin "composition" ActionForm class - in other words, if I had a "Widget" component, I'd create a WidgetForm class with getWidget() and setWidget(), then my form would use the nested syntax, ie "widget.prop1", "widget.prop2". This was working great for the Edit and Add actions, but was probably the cause for my problems with the Save action. I'm realizing a couple of problems with this method...
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. 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? 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. thanks again for any help... -jon --- Ted Husted <[EMAIL PROTECTED]> wrote: > 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]> > __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
