Rick Reumann wrote: > > With this approach, most JSP pages could have a single Java class -- > > a SimpleActionForm subclass that handles both validation and > > processing for the page: > > Well they certainly wouldn't have a 'single' java class, you > would have > a LOT of them.
Sorry -- I meant a single Java class per JSP page, instead of _two_ Java classes (an Action and an ActionForm) per JSP page. > I don't think you meant for that to be abstract. But notice you know > have an execute in all your ActionForms? How is that different than > simply the processing done in different Actions as Struts is now? All > you've done is pushed down the processing to a different place.. > ActionForm vs Action. Yes -- it is supposed to be abstract -- each ActionForm subclass must define an execute() method to perform the processing for that form. You're right in saying that All I've done is push the processing to a different place -- but it's for the purpose of combining the Action and the ActionForm to reduce the number of separate Java classes needed for a typical Struts app, hopefully reducing complexity. > If you like this approach definitely check out StrutsDialog. Thanks for the tip. I took a brief look, but I don't see how StrutsDialogs corresponds to what I'm suggesting. It appears to maintain a separation of Action and ActionForm, which I am proposing to combine. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
