> Best practices for separating model tier objects from your view tier
> objects, and keeping them independent of view tier APIs, are pretty
> much the same with JSF as they are with Struts. In other words, you
> won't want your view tier managed beans (typically in request scope)
> to be exposed to your model tier classes -- instead, think of the
> event handlers as adapters between the view tier (web API dependent)
> and the model (web API independent), the same way you should be doing
> with Actions in Struts.
This was the bit I was curious about, as there are various integration
libraries around that seem to dig using model tier beans as backing
beans. While i can see this as useful for injecting a service to the
model, it seemed to me like you could get into a pickle if you tried
to reuse model tier obejcts as backing beans, but the way that jsf
deals with more than strings for form properties made it more feasible
than with action form.
Thanks
Mark
On Apr 3, 2005 10:34 PM, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Apr 3, 2005 2:34 AM, Mark Lowe <[EMAIL PROTECTED]> wrote:
> > Craig
> >
> > This is a deviation from the topic slightly, but is related to struts and
> > jsf.
> >
> > With struts there's the clear idea of having all you view tier beans
> > (actionforms) that have nothing to do with the model, and so on.
> >
> > With JSF the conversions are taken care of, would persisting backing
> > beans be considered generally and evil thing to do, or is this the
> > idea? I know there are various choices that are made depending on each
> > project, but generally speaking what's your postion on this?
> >
>
> In a JSF app, you will still often find yourself writing backing beans
> that correspond to a Struts Action, rather than to an ActionForm.
> These will typically have event handlers for each of your submit
> buttons (and value change event handlers if you've registered those).
> Because you don't need an ActionForm per se, there are a couple of
> reasonable strategies for making the updated values (on your input
> fields) available inside the backing bean:
>
> * Bind the *value* of an input component to a corresponding property
> on the backing bean:
>
> <h:inputText ... value="#{mybean.customerName}" .../>
>
> public String getCustomerName() { ... }
> public void setCustomerName(String customerName) { ... }
>
> * Bind the components themselves to corresponding properties
> on the backing bean
>
> <h:inputText ... binding="#{mybean.customerName}" .../>
>
> public HtmlInputText getCustomerName() { ... }
> public void setCustomerName(HtmlInputText customerName) { ... }
>
> The former strategy makes the backing bean feel like a combination of
> an ActionForm and an Action (but you can deal with model data types
> instead of just strings). The values of all your input fields are
> immediately available as instance variables, ready to be processed in
> an event handler. (This is the also architecture that WebWorks uses.)
> The latter strategy will be familiar if you've used ASP.Net code
> behind files, or other similar scripting technologies. Its easiest
> when a tool does the setup for you (as Sun Java Studio Creator does --
> when you drop a component on the design surface, it creates a
> corresponding property on the backing bean for you, and initializes
> the binding expression automatically).
>
> Its also possible to dispense with binding *anything* into the backing
> bean, and use FacesContext.getViewRoot().findComponent() to locate
> component instances by their client ids (similar to using the
> getElementById() method in JavaScript to navigate the client side
> DOM). This certainly works, but is likely to be more work for the
> person writing the backing bean. It also requires the backing bean
> developer to know about the nesting hierarchy of the component tree,
> since this nesting drives the creation of the client identifiers of
> the components.
>
> In most cases, you will want to make the backing bean handling each
> HTTP request into a request scoped managed bean, so that the JSF
> framework creates it for you on demand. In addition, because a new
> bean is created for each request, you don't have to worry about thread
> safety like you do with Actions, and you can use instance variables in
> the backing bean for request specific state.
>
> As with everything, there can be exceptions to this general rule. One
> possible exception is where you need to collect state information from
> a number of different pages (like a wizard dialog) ... in that
> scenario, you might want to keep the corresponding backing bean in
> session scope instead, for the duration of that conversation.
>
> > Have view tier and model tier objects (like struts) or persisting
> > backing beans is a perfectly okay thing to be doing? So far I've been
> > just following the struts way of doing things albeit with JSF.
> >
>
> Best practices for separating model tier objects from your view tier
> objects, and keeping them independent of view tier APIs, are pretty
> much the same with JSF as they are with Struts. In other words, you
> won't want your view tier managed beans (typically in request scope)
> to be exposed to your model tier classes -- instead, think of the
> event handlers as adapters between the view tier (web API dependent)
> and the model (web API independent), the same way you should be doing
> with Actions in Struts.
>
> The only time you would need to persist view tier objects would likely
> be to accumulate state from several requests into a session scope
> managed bean. There, the only interesting wrinkle is how to get rid
> of it when you're done.
>
> > Mark
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
