struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Date Tue, 23 Aug 2005 22:33:35 GMT
On 8/23/05, <> wrote:
> Rick Reumann <> wrote on 08/23/2005 04:53:35 PM:
> > If that's the case, though, I'd find that as a severe limitation of JSF.
> > In Struts my DispatchActions can be called from anywhere and there isn't
> > really a need for a tight coupling. "getEmployee" returns "success" and
> > any form or JSP can use this Action (assuming they also use the
> > ActionForm also).

Note that navigation rules *themselves* can be shared ... by virtue of
the fact that you can use wildcard expressions.  So, you get the
benefits of global forwards in Struts too, so "success" goes the same
place no matter which action returns it.

 > In JSF I keep wishing there was a way I can through in a "use this
> > managed bean" in the navigation rules - but I'm guessing that's because
> > I've been using Struts for so long. Hopefully this will all start to
> > "click" at some point.
> >

But, I would caution you to avoid a mistake that lots of Struts users
make as well -- think of an outcome (JSF) or an ActionForward (Struts)
as a description that says "this is what happened", not "this is where
to go next".  Let's consider an example (applicabe to either
technology) to show you what I mean.

How many apps have you built that has a little search field to, for
example, look up the customers that match the first few characters you
type (yes, in today's world, you'd probably use an Ajax-ish code
completion widget, but bear with me).  If you think about it, the
action that executes the lookup has three significant possible

* Zero matches were found

* Exactly one match was found

* More than one match was found

A quick and dirty implementation would always present a table or list
of the matches, allowing the user to select the customer they actually
wanted.  For that, you would only need one outcome.  A more
sophisticated UI, however, might want to do three different things:

* In the zero matches case, go back to the query screen,
  perhaps adding a message like "I'm sorry, no customers matched
  your criteria.  Please broaden your search criteria."

* In the one match case, go directly to the customer details screen
  for that customer.

* In the multiple matches case, list the options as before.

I would advocate that the developer coding the lookup action should
return outcomes like "No Matches", "One Match", and "Multiple
Matches".  It should be up to the application architect desgning the
overall flow.  And she should be able to change her mind about whether
to go to one place or three, *without* changing the lookup action code
at all.

Outcomes are about "what happened", not about "where to go next".

> ok, I'm probably being quite stupid here and should think this over a bit
> more.. but hey, what the hell..;)
> Ok, maybe you could have many different managed beans (I mean with
> different names) but all "pointing to the same class/bean?..

It's not clear what you mean by "pointing" in this scenario.

> Though perhaps (from Craig's earlier note), really we are supposed to
> think of backing beans as kind of very basic and specific to a page or
> something.. 

That is the correct viewpoint.  The backing bean is (along with the
page itself) your view tier, and it interacts with model tier stuff
the same way you would do it in a Struts app.

> and thus not *have to* share it across many pages.

I would go one stronger, and say you should *not* share this kind of
bean -- although there is a subtle exception to that ... you can
compose your view out of multiple smaller pieces (either by using
<jsp:include> or Tiles).  You'd want to have a backing bean *per Tile*
in this case, so the backing bean, plus its corresponding JSP, are
being reused.  But they are a unit, and should be thought of that way.

> If you have
> logic in there which you have to share, then move it to another layer once
> removed perhaps..

Yep, for all the standard reasons (this logic should be independent of
the web tier APIs, so it can be unit tested easily and reused in other
scenarios).  And, you can optionally use the managed beans facility to
configure such objects and put them in the right scope (or use Spring,
or use JNDI lookups, or use either of the above transparently via
value binding expressions in Shale).

The best practices here (separate business logic from presentation
logic) are exactly the same as they are for a Struts based app.

> But you are right, this isn't sinking in like it should..(:(
> > Rick
> Geeta


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message