On 1/6/06, Tamas Szabo <[EMAIL PROTECTED]> wrote: > So why is it better to bind request params to business layer objects > directly without using ActionForms?
It isn't, really. People do that, but when we do, we flirt with the dark side. The problem with ActionForms, and similar strategies, is that we are going for the quick fix rather than the big fix. We try to solve the immediate problems, but we don't step back and look at the big picture. The big picture is that the presentation layer, whether it's a web layer or not, needs to know a lot about every property that is exposed by the application. We need to know the property's * view name * view type (String or boolean) * validation constraints * default control type * model name * model type * persistence type * label * data entry hint * validation message * text format (mask) But, in no one place do we itemize these facts (and any others I missed). Instead, we scatter them throughout the application, and then we wonder why programming the web presentation is so hard. It's hard because, when it comes to presentation layer properties, we still don't * Separate Concerns, and * Say It Once (DRY) I know that some people say that we have too much XML in our applications, but I think the problem is that we have too much notation in some places because there is not enough notation in other places. If we graph the properties, and then list which properties go with a form, much of the validation and form layout can be deduced, and many simple forms could be generated from a single tag. WebWork is starting to do the latter now. You can list the controls for a form, and the UI tags take care of all the formatting, including table tags, labels, and messages. I'd like to take it a step further so that we could just say "put form x here", and the rest could be generated from the object graph and style sheet. In the OverDrive whiteboard, we've been using a strategy where the input and output properties for a command (or Action) are explicit, along with which input properties are required. We also specify "processors" for each property that handle the validation and formatting concerns. Likewise, the labels, hints, and validation messages are specified *once* for each property. Nearly all the validation concerns can be deduced from a rich object graph, which eliminates a lot of bother. I expect that if you are using a rich domain object model, then annotations could be used in lieu of XML, or at least in conjunction with XML. But, regardless of how the presentation's view schema is created, I think the trick is that we need to stop repeating ourselves, and provide a central repository where all these facts can be maintained for all the view properties. Specifications like XForms imply that a view schema exists, but do not explicity define anything like a master object graph. Ideally, I believe that tit would be helpful if there were a unified set of mappings, accessible to each layer, that could describe an entity as it flows from the database, through an object graph, onto the presentation layer, and back again. (Or not, if it is a virtual property.) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
