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]
