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]
