Joe Germuska wrote the following on 2/18/2005 5:37 PM:
Well, I think you're blurring things here. When I talk about "http-free" components, I'm talking about your business logic, not your controllers (actions or commands).
But for most developers, the business logic usually is already self contained somewhere else (hopefully we don't still don't see people coding JDBC from within their actions:). So for example, in an Action method someone might do:
In so far as it is, then they've already achieved the "http-free" components. I'm afraid I don't believe that's as widespread as you do, although I'm not saying that no one has figured it out.
What I seem to be seeing in the examples of CoR and Struts is the removal of the Action class and instead using a chain of Commands.
Hm. I don't think many people are really pushing this as "the future" or "best practice," but just pointing out that it's available. At least, that's how I feel about it.
This is fine and I like the idea because it does allow for the concept of coding pre and post processors without IoC, but I still each of them having a lot of ties to the Servlet model. For example, maybe before leaving all of the typical CRUD events you need to call a populate Command that will populate your Request with some needed Lists for drop downs. No longer do you have to remember to make sure to include the "populate(..)" method call in each of your dispatch methods since you could just add that to the end of the chain.
Well, if we postulate (as ActionContext does) that any request/response model will have a few maps for scopes (request/session/application) and another for request parameters, then you've already insulated yourself against the servlet API. Now, in your test class, you can just make a Map with the parameters you want to handle, without having to mess around with MockServletThis and MockServletThat.
I'm just wondering if someone could provide some more examples of possible real world benefits of the CoR used to replace Actions. I can see the standard chain looking like...
-somePreCommand (probably does your initially logging) -someActionCommand (replaces the meat of your Action dispatch method) -somePostCommand (maybe ensures some things are put into Req scope)
I'd be curious on seeing some other examples of the possible Commands you would likely see in a typical web app? Thanks again for any additional light.
I'm afraid we will still have to wait and see. What I would suggest first would be replacing the kind of chaining people currently do with requestDispatcher.forward("/to/another/StrutsAction.do") -- say to have one command for processing a submitted form and another for prepping the page -- but I'm actually thinking I'd prefer to be able to hang Commands off of ActionForwards -- the net result would be the same, but you'd have less tangled configuration if you simply said "always execute this command 'on the way' to this forward" rather than having to repeat that configuration for each action mapping that might need that page preparation behavior.
Again, I think using commons-chain Commands (or Chains) in place of an Action have yet to prove their superiority. The biggest gain I would see out of it would be a further step towards reducing dependencies on the HTTP API, which, despite your skepticism ;-) I think is a worthy goal in itself.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
