On Mon, March 7, 2005 2:23 pm, Rick Reumann said: > 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.
Keep making up those words Rick! :) I think the debate, in my mind at least, is what the term "page-centric" really means. The definiton I've been going with is that if all the functionality for a given page is specific to that page, then it is indeed a page-centric design. The problem I personally have with that is that if you have a dropdown on three different screens that just happens to have the same data in it (not something unusual really... think maybe a list of U.S. states), then you have no elegant way to deal with that IMHO. A good developer is going to have some sort of class to get the data for the dropdown, but then you have to call on it from three places. I'd prefer something like that be declarative. You make a comment later on that I absolutely agree with about having the code in front of you instead of having to dig through config files and figure out what some framework is doing for me behind the scenes. Generally I agree with that. But, I think there are places its better to go the declarative route, and I sense this might be one of them. > 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. <SNIP> Your approach is indeed nice and simple, and echoes what I tend to do. But, I'd prefer to not even have to write that code into every Action where such setup-type functions apply. I'd prefer it be configurable, like so much else of Struts is. > 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.) The thing is, I'm not convinced the scneario you point out as being not too common actually IS that uncommon :) I haven't done a ton with DispatchActions, but I *have* on many ocassions had an Action that was callable from a number of different pages, and the forwards were indeed different. My experience would tell me that such a scenario happens more than the 10% of the time you think it does :) In such cases, being able to declaratively specify which setup functions to perform based on the particular mapping would save me a lot of redundant coding. I handle it now by forwarding to Actions that do the setup I need, but that makes for a more verbose struts-config.xml. Just as annoying but in a different way! > 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. No argument here! Hence the reason I didn't want to add a new config file at all... my solution centers on the idea of adding one new element to an Action mapping, <actionSetup> (although, as I wrote that just now, I think <mappingSetup> maybe makes more sense... perhaps even making these attributes of a <forward> makes more sense... eh, thinking out loud now!). I doubt very many people would find this onerous. > 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. That's the point I liked! :) And I don't at all argue with your suggestion to Ben. What you propose works, is simple, and I'd bet would meet his needs. But, we've kind of hijacked poor Ben's thread and dovetailed into proposing a more general solution to this very common problem :) I was hoping to get a chance to implement this today and post it for everyone to see, but I got hammered at work. If I can get some time tonight I may be able to throw it together. I think then we'd see the benefits or problems with the idea much clearer. > -- > Rick -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
