Mark Wrote: The problem i see here is, this contact form will always be processed by the same action servlet, and forwarded to the same forward. What If I had several different scenarios that needed to edit/view the contact data, maybe even Different contact data such as User Contact, Customer Contact, etc. So that means that the "save" functionality might be different, and the next page, the "results" might be different.
Jacob Writes: You might want to look at WSDL to handle business logic. Struts acts as a presentation controller, the things you are describing can be retained in your business logic layer. That's not to say that you can't chain Actions or even look at DispatchActions to complete your specified tasks. For me, when handling business logic like this, I go with extremely fine granularity (no dispatch actions, I think they are bad news and you can use abstraction and the template method pattern to essentially accomplish the same thing). "For every action, there is an equal reaction-- or a few of them in a chain using the visitor pattern" or something like that. Going back to your requirements of handling different types of Contacts: Let's say we have a ContactActionForm object. I'm assuming the Contact information will change for each type of Contact. Then create an ActionForm for each type that extends ContactActionForm. For each form, bind them to a name in your struts-config. Another possibility is to do a single "Concrete" or "Flat" ActionForm that has all possible attributes for every Contact. Then you can bind that single ActionForm type under multiple names. The reason you want to have multiple bindings, even though they are the same ActionForm is so you can leverage the Validator libraries which act on a bind name basis (same ActionForm, different rules for each bind). For your Actions, lets say you are wanting to save these Contacts. Again, just like you did for the ActionForm, create something that is extensible and leverage the template method pattern so you can outline a path of logic and have each Contact be handled differently. Again, bind each SaveAction to a different name. I think Struts is extremely flexible, just don't depend on it to handle your business logic, but only as a presentation/transport layer for your REAL business objects/services. -Jacob -----Original Message----- From: Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 9:59 PM To: [EMAIL PROTECTED] Subject: Is struts-config too verbose? Looking at struts-config i see an inflexible application skeleton that makes it hard for me to do somethings, or maybe I dont know how the Struts way is...Can someone enlighten me please? I have a Contact form. I want to be able to reuse this contact form, which has standard information such as name, address, etc, in several places in my application. Looking at how action mappings work and all, the form's action field is constant.. Therefore, if i have this: <action path="/Contact/save" ..... > <forward name="success" path="contact.Saved"/> </action> in my jsp: <html:form name="contactForm" action="/Contact/save"> .... THen inside my action class I have the code to process the form, and forward to the "success" forward. The problem i see here is, this contact form will always be processed by the same action servlet, and forwarded to the same forward. What If I had several different scenarios that needed to edit/view the contact data, maybe even Different contact data such as User Contact, Customer Contact, etc. So that means that the "save" functionality might be different, and the next page, the "results" might be different. Im befuddled how to handle this elegantly. I want to reuse my views. That should be simple shouldnt it? I think im missing something. Thanks in advance. Regards, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
