I happened to initiate a private discussion on the topic, so if someone interested, I am sharing it, with Michael Oliver's consent. Hopefully, it is readable ;-)
> On 6/23/05, Michael Oliver <[EMAIL PROTECTED]> > > > wrote: > > On 6/23/05, Michael Jouravlev <[EMAIL PROTECTED]> > > > wrote: > > > On 6/23/05, Michael Oliver <[EMAIL PROTECTED]> > > > wrote: > > > > > On 6/23/05, Michael Jouravlev <[EMAIL PROTECTED]> > > > wrote: > > > > > > On 6/23/05, Michael Oliver <[EMAIL PROTECTED]> > > > wrote: > > > > > > [Mike Oliver] I don't see the need for a new type of Action, there > > > > > > is > > > > > > no limitation to what methods you ADD to an ActionForm, so you may > > > > > > choose to do your business logic implementations in the ActionForm > > > > > > itself and then the various Action::execute() methods would just > > > > > > marshal the arguments and call the methods on the ActionForm that > > > > > > is passed in. > > > > > > > > [MJ] Yes, this is exactly what I am doing right now. But what is the > > > > point > > > > in an Action class, which does nothing but marshalling events to > > > > ActionForm? Would not it be better, if these events were delivered > > > > directly to ActionForm, so Action class could be dropped (in a given > > > > particular case) altogether? > > > > > > > > [Mike Oliver] I guess the key phrase here is 'better', there are some > > > > Struts gurus that would say you should have the ActionForms as light as > > > > possible, and then have your real business objects much heavier and > > > > then the > > > > Actions simply read the ActionForm submitted and call the setters on the > > > > heavier objects which are persisted, and those heavier objects could be > > > > EJBs, etc. Also keep in mind that the Dynamic forms work in Struts > > > > equally > > > > well as ActionForms but you obviously can't add methods to Dynamic > > > > forms. > > > > So 'better' seems to be more a matter of what you want to do and what > > > > you > > > > are used to, etc. > > > [MJ]There is a difference between a "view object" which I store in the > > form bean, and a business object. On the other hand, I store business > > objects in the form bean as well as nested property, works for me. > > Also, these gurus apparently do not use session-scoped form beans. > > > > I use form beans with session scope, and I use them not only for > > input, but for output as well. Thus, a form bean is not a simple > > request-to-app DTO, it is a stateful interactive UI object. Which can > > have behavior, of course. So, it is only logical for it to have > > methods. And because it is an UI object, some of these methods can be > > UI event handlers. > > > > I am not saying that this way is better than another. I am just saying > > that I would like to have another option. Stateful form bean is almost > > like a JSF backing bean, don't you think? Not that I want to covert > > good Struts people to JSF... > > > > > > > > > > [Mike Oliver] We do [marshaling from action class] that way > > > > > > > > whenever we need to, but we also use helper classes that have > > > > > > > > the methods to act upon the data in the ActionForms and call > > > > > > > > them from the Action Classes or from Axis Web Services. > > > > > > > > [MJ]Is not it more procedural than OO? Would not it be better to have > > > > data > > > > and its behavior in one place, that is in ActionForm? > > > > > > > > [Mike Oliver] No, I don't think I would go that far. Yes > > > > encapsulization > > > > is a good thing and ONE of the principles of OO, but having lots of > > > > objects > > > > does NOT make it procedural. For example taking the above example of a > > > > lightweight form, even a dynamic form and having the action transfer the > > > > data to the heavier object....then you could have several dynamic forms > > > > that > > > > had different views and subsets of the fields in the heavier object, one > > > > object to persist and the data you don't want exposed is protected and > > > > encapsulated, yes? Do you see what I mean about 'better'? Just > > > > depends on > > > > your point of view. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
