On 8/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Rick Reumann <[EMAIL PROTECTED]> 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. > > <soapbox> 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 outcomes: * 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". </soapbox> > > 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 > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
