On Sun, 9 Jan 2005 14:57:41 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:
[snip[ > > It is my understanding that with JSF and Shale, how form data is shuffled > around and validated will, with all hope, handle those issues for the > developer. I am by no means an expert on JSF/Shale, but that will (given > enough free time) change. I am finally somewhat up-to-speed with Chain and > look forward to contributing to this effort. > Shale and JSF do indeed change things -- you don't need form beans at all. Struts uses form beans for the following things: * Save the string representation of each input field, so you can reproduce what the user expects even in case of conversion errors (this is why it is recommended that form bean properties be strings) * A place to hang validation logic * An implicit bean to be associated with a particular form so you only have to specify the property name on the JSP page (although, if you're using nested beans, you're already using more complex expressions). * As a resource that gets instantiated for you on demand, in either request or session scope. JSF components handle the first two responsibilities all by themselves, so you can do all your manipulation directly with model properties and native data types -- and the model properties don't get updated unless all of your validations have succeeded (hooking up to Commons Validator is on the list of things to be added to Shale). For the third scenario, JSF value binding expressions are a little longer (you need to include the name of the form bean on the front), but you gain the ability to bind to more than one bean if you want or need to. For the fourth responsibility, JSF generalizes the way that Struts creates form beans for you to create *any* bean on demand, including configuring its properties, in an IoC like pattern based on setter injection. The "Shale Use Cases" example app has some illustrations of what I expect to be a common pattern in JSF and frameworks based around it -- a backing bean similar to a Struts Action (except that it gets instantiated once per request, like WebWorks does it, so you don't have to worry about thread safety considerations) will contain: * Properties for each data item on the form, but using the native data types since you don't have to worry about conversions). It's also reasonable to collect properties for more than one page for things like a wizard dialog. * Event handlers for each submit button on that form, which JSF calls directly (so you don't need anything like a DispatchAction either). * Event handlers for value change events if you want to change the behavior of your application in response to these. * You can even bind to "validator" methods in the backing bean, if you need some application specific validation and don't want to go to the hassle of creating an external validator class and registering it with the component. Then, if you're updating a database or something, the event handler for your "Save" button will acquire a reference to the appropriate DAO (or Hibernate session, or EJB, or whatever) and modify it appropriately. Fewer moving parts makes for simpler code and fewer mistakes. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
