On Wed, March 9, 2005 4:07 pm, Rick Reumann said: > (Hope you take the right way Frank.. because it is very cool:)
Of course I do Rick... YOU HATE ME!! :) Seriously though... I do agree with much of what you say... I've always been of the "get those stupid XML files away from me and just write some CODE!"... I guess my mindset is changing a little bit lately as I see more the benefit of the declarative approach. One more point to add to this... In my environment, we have a rather convoluted change management process in place. Any code that gets deployed to production takes on average 96 hours to get through it all. Painful to say the least. This isn't exactly unusual in large enterprise environments (maybe not quite THAT long though!). However, the people in charge of that process DO NOT have a problem with me changing config files and restarting the app any time I need to. So, for me, the more that is declarative the better. Certainly not every place is like that, it might even be the minority, but its not unheard of. Something like this could be a big help. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
