I think a simple approach is using tiles Controllers. They're WAY simple. Having said that I might be over SIMPLIFIYING the problem
http://www.theserverside.com/articles/article.tss?l=Tiles101 On Mon, 07 Mar 2005 14:23:07 -0500, Rick Reumann <[EMAIL PROTECTED]> wrote: > Ben Taylor wrote the following on 3/5/2005 3:03 AM: > > Hi, > > > > Can anyone tell me if there is an easy way to put information > > (required to populate drop down boxes using data from a db) in to the > > request, without having to write a setup Action for each page as is > > done here: http://www.reumann.net/struts/lesson2/step9.do . > > I started reading a bunch of these threads in reply to the above and I > do think that I'm seeing a trend of over-complification here (yea, made > up word:). I do like the concept that JSF takes, but from some of the > posts I've read, some are complaining about JSF being too page-centric. > Personally I like the page-centric approach and find that it fits the > mold of how typical web apps work. I'd say 99% of the time people use > Struts in a page-centric manner. > > Sure you can create a ton of cool ways to handle the setup of Lists into > scope, but I still find it very simple to have in my Dispatch Action a > simple prep() method that handles this. > > (The above mentioned SetUp Action in the article was because I didn't > want to introduce a dispatch action at that point, but look at the > http://reumann.net/struts/articles/request_lists.jsp article for more > specifics on how I'd do it using Struts 1.1 and a simple Dispatch Action). > > So to summarize typically I'd have > > //:SomeDispatchAction > > update(..) { > //do stuff > prep(request); > //return forward > } > > prep(Request request) { > request.setAttribute("yourList", service.getYourList() ); > } > > The only time the above is annoying is if you happen to use your update > dispatch method from several different places and your resulting forward > can go to many different pages (not all of which would need the "list" > placed in request scope.) (Even if you end up going to different pages > from reusing the above Dispatch update method, the worst case scenario > is that you'd typically have a few extra things stuffed into the > request. Yes, if logic is way different you could need to use different > lists with the same name, etc.. but again how common is this? I still > tend to think it's best to solve and code for the 90% rule.) > > And although many have proposed nice ideas one of the problems is as > Leon mentioned: > > "I find it hard enough to manage all the config files I have to manage > right now (struts-config, resources, tiles-definitions, factories, and > so on), I would be the last one to introduce one more." > > And the above point is the exact problem with some of the solutions. And > yes Tak I have looked at OzStruts briefly and to me it overcomplicates > things because it's just one more thing a developer needs to learn, when > the standard practices solve 90% of the problems. > > To the initial poster (Ben), I'd opt for the simple prep() method unless > it doesn't meet your needs. Another benefit is if someone has to look at > the code, it's easy to find what is going on. Nothing to me is more > frustrating than working on someone's application and trying to figure > out what configuration file is injecting what where and how, or what pre > and post operations are taking place that are setup somewhere else. > Sometimes these solutions are needed, I just don't think for the vast > majority of cases they are. > > -- > Rick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -Dave [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
