Craig McClanahan <[EMAIL PROTECTED]> wrote on 08/23/2005 06:33:35 PM: > <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> >
Correct. And I have indeed coded for situations similar to your search example, for Struts apps in the past. What i mean is (continuing your example) my (Struts) action returned perhaps forwards for say "noMatch", "oneMatch" or "manyMatches". However, the forwards for that action in struts-config then had to have paths for something like noMatches.jsp, oneMatch.jsp, manyMatches.jsp. So the architect can indeed decide to change the "where to go next" piece without touching the action code by simply fixing struts-config.xml. And, as I understand it, we code the the Shale/JSF framework also similarly. The backing bean returns an outcome and the faces-config.xml maps the outcome to the view. So, I don't mean to sound impertinent or anything :), but really, you *do* in fact return an "outcome" in either case and "outcomes" are indeed about "what happened" and not "where to go next".. Except you *do* of course go somewhere next, and therefore have to code that information (in config files in either framework). So what am i missing? I mean, where's the difference between the Struts way and the Shale/JSF way? > > 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. Well, just kind of a stupid way of doing things. ;) I meant that in faces-config.xml, we can have two <managed-bean> defintions, one with managed-bean-name as say page1 and the other as page2 but both having managed-bean-class as the same bean class say MyBeanClass. In that case, page1.jsp and page2.jsp would both share the same bean..(Would have to set the managed-bean-scope to session though I'd guess in order to share it across both pages..?) I imagine that would work.. but, yes, I understand you have said it isn't a good idea..:) > 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. > Yes, I think we shouldn't have a problem with that..;-) > Craig Once again, many thanks for your time! Geeta
