On 7/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > +1 as well, and this matches the historical reason that form beans > were invented in the first place. > > Form beans are part of the *view* tier, not the model ... their > purpose in life is to represent the server side state of the HTML > elements on a form, even if that state is invalid (i.e. not currently > passing all the validations). That way, you can reproduce what the > user typed so he or she can fix it, rather than presenting them with a > completely blank screen. (This is why you generally use string fields > in a form bean). > > In a component oriented framework like JSF or Tapestry, you don't need > to worry about keeping track of this state information ... the > components do it for you. But in Struts it is the application > developer's responsibility to understand the correct design patterns > -- and this is one of the most fundamental principles of how Struts > was designed.
Yes, compared to component-based frameworks, one feature ActionForms provide is to act as an input buffer. Component controls have a built-in string field, but since the Struts tags are not designed as components, we need the ActionForms to provide the missing buffer. Of course, ActionForms also provide for input validation, so they are also more than a simple component buffer. One of the things that confuse people about ActionForms is that they have a complex life cycle, and serve different roles at different times. Of course, there are many ways to reduce the ActionForm maintenance burden. One strategy is to use a coarsely-grained ActionForm that represents several (or all) of the input fields in your application, and then subclass the base form to provide for different validations (if needed). Another technique is to use a flavor of DynaActionForm. In my own work, I tend to think of an enterprise-grade application as a set of overlapping rings, like the Olympics logo. * http://www.olympic.org/ In the Blue ring live the view members, like custom tags or UI components, and the HTTP request and response objects. This is the layer where our appliction interacts with the rest of the world. Some of the Blue ring members also interact with the presentation controller components that live in the Gold ring, like the Struts Actions, ActionForms, and JSF backing beans. This is the layer that "interprets user gestures" to decide which view to display next, and may also convert or format data as needed. In turn, Gold ring components interact with your own business objects, which live in the Black ring. The business compnents could also be chains of commands, representing services, rather than conventional object representing domain entities. This layer often acts as a "liaison" between the view-centric Blue and Gold rings, and the data-centric Green and Red rings. To be useful, most business objects need to access persistent data. Rather than talk to the native database API, most of us use data access objects, that live in the Green ring. Here we find components like iBATIS or Hibernate, JDO, or just plain JDBC. This layer links specific business methods to general-purpose persistence methods. Finally, in the Red ring, we find our dragon -- the physical database. In some applications, the database is a deep crimson that represents our solution to the domain's problems. Other times, the domain logic lives in the black ring, and the red ring is a pale pink shoebox. In some applications, the rings are separated by framework or package lines, like Struts and iBATIS. In other applications, the rings may exist as separate classes in the same package, or even different methods on the same class. But, eventually, in my experience, any long-lived, well-factored application will find itself using all five rings, or all five separations of concern, in one way or the other. Of course, in a conventional MVC application, the Black and Blue rings intersect, forming a triad, and the Green and Red rings are not described. Though, I expect, the other rings did still exist, but were simply hidden behind the event horizon of MVC's Black ring. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
