Fogleson, Allen wrote the following on 3/9/2005 3:21 PM:
I have been there enough times, and I am sure others have, to know that changing that all in a single file is a LOT faster than going through hundreds of files searching for "SetupClass1.setupMethod1(request)". Or the worse case searching for that in a project that you got attached to at the last minute and need to make the change... are you sure you caught them all?
(How long can we keep this thread going:) anyway....
I'm not so sure the above is really fair and realistic and, to a point, I actually see Shey's frustration and it is why, that even though I really like the stuff Frank came up with, I probably won't use it.
Going with this declarative approach is nice but only to a point. I tend to think people are starting to go XML config crazy with some stuff. (Eventually are we even going to write Java classes:) But let's back up...
Typically I still will argue that writing a simple prep method is not a lot of code and doesn't result in 100s of places to search and replace. Typically, I have a few UIHelper methods that might load up some Lists... ie put a list of "Car types" into scope. All the Action prep() method does is call this one method (UIHelper.loadCarTypes()). Remember the prep method is only defined 'once' per Action class. The UIHelper method(s) go in this 'one' spot. So let's talk real world here... I tend to like finding what I need in my Dispatch action classes. I actually am more likely to have several different action mappings refer to one DispatchAction than have lots of different dispatch Actions calling the same exact UIHelper methods. Maintaining the XML file when things change can actually create more work. Say I also now need a drop down of "Car Dealerships" to show up along with my "Car types." For me it's as simple as adding my one method UIHelper.loadCarDealerships() to my one dispatchAction prep() method. For the declarative approach it involves finding all the potential mappings that point to this Action. I really do think this is the rub. Where will you actually be defining *more* of the things you need to replace? I think you'll find you'll end up having more hunting to do withing the XML file than you will within Actions.
I'm not saying I dislike the declarative approach (I'll actually end up using the chain stuff in Struts 1.3 in my mappings). I'm just stating that I doubt it really helps maintenance "that" much, if any, and I think it can potentially add more maintenance. The main benefit I do see is that you avoid having to recompile a Java class (or classes) when you need to use some different prep/setup methods. I don't find this 'that' much of a time saver. I'm also often frustrated with a lot of injection approaches where I have to hunt around to figure out what got injected. A developer on your project now has to remember "Oh yea, that List I'm looking at got set based on the param in the config file." Oh, and another nice time saver to the Java approach is that I can quickly jump to that class from the Action. Take a typical example... you are working with some Struts actions and then you realize in your view that something doesn't look right in the list that's appearing. Well, using the Java approach, I can quickly see what method is being called and I can jump right to it (using any halfway decent IDE). With the declartive approach I know have to figure out what mapping called that Action and look there to figure out what setup was called declaratively and then go back and load up the class/method. Granted, not a super big deal.. but since we are quibbling over characters, I'd argue that takes up more time than having to type the import name of my Helper class (which again is automatically imported when you use any decent IDE and type the class name in your code).
Overall, though, I think both approaches are fine, I just think it's more "neat/eloquent" rather than really a great "benefit/time-saver." (Hope you take the right way Frank.. because it is very cool:)
-- Rick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
