On 7/6/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > I pity the poor noob who asked the original question! Little did he > suspect that he would spark off a dialog on advanced MVC design. > > This debate has come up before and for me, it is one of the weak points > of struts - I remember a couple of years back someone on the list > complaining that Struts wasn't 'OO' because the data and logic were > seperated into Actions and ActionForms. I remember Craig M. almost > agreeing.
Looking at JSF backing beans, he ultimately agreed. > Now there is talk of Struts in the future containing ActionCommands > which can be substituted in place of Actions, and strung together in a > chain, and presumably can perform View-Controller logic. My previous design used chaining of different actions, like to chain from 'create' to 'edit' to implement 'add new' operation. But now I use a single action class with dispatch-style handlers and redirecting to itself for rendering. Technically, it is not even chaining, because I do not use in-server forwarding, I use redirection. On 7/6/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote the following on 7/6/2005 12:26 PM: > > > So, you use action forms both for input and output. This is great. > > Change the scope to "session", throw in some methods, and you get > > yourself a backing bean. This is what it should be. > > Well, not really. I should be able to use a POJO/ValueObject not tied to > Struts packages. A true backing bean could be used on the backend and > front interchangeably. Sure, if I wanted to tie my entire backend to > Struts I could be passing around the ActionForm everywhere, but I don't > really like doing that (the whole seperation thing again:). Right, I would like to use a POJO/VO/BO outside Struts too. Let us establish a use case: to use a BO in input/output mode, that is to [semi-]automatically populate it from request, and to have it provide values for JSP page. So, I see two choices for this use case: (A) Define getters and setters for all properties of BO right in the form bean. This way all form bean properties are defined as strings. This helps to retain values from request, even if they are incorrect, because no conversion to native type is made. The values can be validated with standard validate method, and I don't have to worry about consistency of a real BO. I would need to define setters/getters again, and to copy values from/to BO. On the other hand, I would need to copy those values only at init and then at store. If a user makes several submit attempts, I copy nothing to BO. (B) Set up a BO as a property of the form bean. Struts will access it as nested property and will be able to set and read its internal fields. I will need to use qualifiers to access properties of a BO from JSP page. In this case BO should accept string values, and should have built-in validation and conversion mechanisms. In this case I have a pretty isolated BO, which can handle raw string data, and can validate it. I think this way is better for systems where Struts is not the only front end, and there is a lot business logic and business validation on the backend. > I often use the same > ActionForm in many diffrent cicumstances. I wouldn't want it always > being populated (the "add" was just one example) so you'd need a > mechanism to decide when and when not to call the populate and, not only > that, but what gets populated might need to change based on what the > ActionForm is being used for. For example, you might have a generic > UserForm (name and ID - for simplicity)- this form might sometimes be > used for dealing with Accounting users or sometimes HR Users. In order > to resuse this form in many different circumstances you'd have to have a > bunch of conditional logic in your ActionForm. I find it cleaner to > avoid that logic. I find it cleaner to bind that userForm to different > ActionMappings and thus the resulting Action takes care of knowing what > to do, vs putting all the responsibility on the ActionForm knowing how > to populate itself. A-ha. You keep your action form clean and "multipurpose" so you can reuse it. But your action class performs business logic specific for every use case, so you cannot reuse it. If you were to create a library, you would have to provide base action forms, which would be reused or subclassed, but a user of your library would have to define a new action class anyway. Now, let's look at it from another side. The action class is multipurpose, it can be either subclassed or in many cases used as is. This is a clean benefit for a user of a library. The action class provides the event contract, while the action form does the dirty work. The library does not have a clue about real data in every different case, but in might have some knowledge about the protocol, and about lifecycle. So, the library provides an interface which action form implements. This way it behaves according to protocol, but has the concrete logic for a particular business object. Also, using action forms implementing certain interface does not preclude from subclassing certain useful action form like ValidateForm. Stateful action form contains all needed data, so methods can easily access this data without needing to have a reference to a form and to cast it to proper type every time. Did I convince you that having business logic in an action form is better? Action class provides external I/O contract and manages messages and navigation, while action form performs operations on business data, *where it is actually stored* . > > The simplification of this approach is using of dispatch action and > > redirecting from it to itself. Commands like 'create', 'edit', 'view' > > are dispatched to handlers, which load or create an object, then > > handlers redirect to the same action, which displays whatever is in > > the form. See details here: > > http://struts.sourceforge.net/strutsdialogs/crudaction.html > > All CRUD operations are neatly provided by one class, but of course it > > should be backed by an action form, which does the dirty work ;) > > Guess I'm too old skool, I like the dirty work called from my Action > dispatch (CRUD) methods. See above. Maybe you give it a second thought ;) Michael. -- Dialogs for Struts http://struts.sourceforge.net/strutsdialogs --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
