On Thu, September 22, 2005 3:31 pm, Dave Newton said: > If you're going to put an ActionForm into session mightn't it make more > sense to put this in a request processor, as long as it's > Struts-dependent anyway? I dunno.
It's certainly a reasonable argument to make. :) My feeling these days though is that anything I can do in a more "generic" J2EE way, i.e., not Struts-specific, is good. If I was using 1.3 I might soften that stance a bit because it's inherently designed for extension, and something like this would probably be at the top of many peoples' lists. Putting that all aside though, today I'm not using 1.3, and I work in a shop where modifying Struts is frowned upon, so I might not even have that option available even if I wanted to go that way. I'm not even sure I'd be allowed to do it with 1.3! But at least there I can make a stronger argument that Struts isn't really being "modified" per se. > I implemented (more or less... tending towards less ;) this because it > seemed like most of my apps wanted to always have this or that object in > various scopes. It wasn't totally config-file driven but a combination > of config file which basically supplied factory class names that would > then do what I wanted. If you really do always want these objects in existance in a given scope all the time, and would prefer to not have to write the code to ensure that, then this filter I think is a good answer to that challenge. I don't claim it's on the same level as Spring or anything like that, but I think it does the job pretty nicely. :) > This solution generally worked for me, but I sometimes found the > delocalization a bit magical: "Man, I'm looking at the code for this > action and I don't see ANYTHING relating to what I'm seeing in Real Life." I have historically agreed with that viewpoint too. I've always had a bit of a problem looking at a piece of code and having to wonder "hey, where do A, B and C come from?!?". But, as with all layers of abstraction and move towards centralization, you gain things, theoretically at least, that make up for that. Having one config file to go to to see how objects are put together, not having to have the plumbing code in your classes to get their dependencies, these are just two of the benefits to any IoC implementation. Heck, it's the same arguments we made for and against JNDI years ago really :) > *poof* Why did I just have a vision of Merlin turning Bugs into a bat?!? > Dave Frank P.S. - I just threw together a quick little sample app to see if the filter can be used this way in the first place... it didn't work right off the bat, although I think it's just a mapping issue, not so much a flaw with the underlying concept. I'll reply later when I have it working, in case anyone is interested. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
