On 8/23/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Craig McClanahan wrote the following on 8/23/2005 4:10 PM:
>
> > The important principle is really pretty easy to articulate:
> >
> > IF you want your backing bean to implement ViewController
> > and get its event methods called, THEN the name of the
> > managed bean MUST conform to the mapping rules.
> >
> > That would mean, for a page named "/employee.jsp", then the managed
> > bean name (if you use the default mapper, which is recommended) MUST
> > be "employee", not "employeeBacking". Making that change would also
> > mean changing expressions that use "employeeBacking" now to use
> > "employee" instead, so you'd have:
> >
> > <h:dataTable value="#{employee.employees}" var="emp">
>
> Is it typical then to end up with several ManagedBean definitions for
> the same backingBean but for different mappings?
>
Why would you need that? I typically use a 1:1 mapping between JSP
pages and backing beans.
> In other words what if not just employee.jsp needed the "Employee"
> managed bean but also "employees.jsp", "employeeForm.jsp", "FooBar.jsp"
> all needed access to the managedBean? If all of them needed the
> prerender to fire off then I would think each of them would have to be
> created with separate managed bean definitions?
It might be helpful to distinguish different kinds of managed beans:
* Backing beans containing event handlers and data related
specifically to a particular page. This is what a ViewController
is in Shale. There will normally be exactly one such bean per page,
with (at least) an action method for each submit button that does
something different ("Save" versus "Cancel" for example).
* General purpose data beans that you define as managed beans
so you can leverage the dependency injection mechanism. The
names of these beans are arbitrary, and easy to share across pages.
(In apps built with Java Studio Creator, for example, we precreate
three beans like this -- one in each of request/session/application
scope -- as convenient places to pass data around). But you can
also stick your own objects into the appropriate scope whenever
you need to share. But these should be *data* or *business logic*
beans, not tied to JSF APIs. They are *not* "backing beans" by
the definition above.
Another way to look at things is to mentally translate from Struts 1.x
terms: a "backing bean" (or ViewController) is a combination of an
ActionForm and an Action. Or, more precisely, it's often a
combination of an ActionForm and a DispatchAction -- although the
multiple action methods is implemented by binding each component
individually, rather than calling a common execute() method that then
dispatches.
In general, then, each action method functionally corresponds to a
single Action.execute() method in Struts. And the best practices
about abstracting out your actual business logic into a separate tier
applies here as well -- call your DAO and business logic objects from
within the action method.
> Rick
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
