On 8/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Craig McClanahan <[EMAIL PROTECTED]> wrote on 08/23/2005 06:33:35 PM: > [snip the <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? >
Congratulations, you broke the code :-). All the things you learned about good application design using Struts stil work. > > > 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 :-). Backing beans (or ViewControllers when you also use Shale) are view tier things, just like form beans in Struts were intended to be (but way to many people in the world use for other things too). > > 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 > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
