That is probably, as Craig said, because the parallel behavior is with
Actions, not ActionForms. Struts is not a page-centric framework, and
it does not react well to being treated as such.
Jack
On Apr 3, 2005 3:49 PM, Mark Lowe <[EMAIL PROTECTED]> wrote:
> > 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]
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
