Joe Germuska wrote the following on 2/18/2005 12:32 PM:
Yes. If I may, what Ted, Vic, Don, and I are saying is that you should treat Struts as an adapter between HTTP requests and an application which has nothing to do with HTTP. Minimal business logic should be embedded in the Struts layer, whether embedded in Actions, ActionForms, or chain Commands. Struts should do input validation, interface flow control, and translation from HTTP request parameters to application objects and from application objects and data to HTML views.
Ted and Vic, in particular, are saying that commons-chain is a good way to write one of these applications-which-has-nothing-to-do-with-HTTP.
The problem I run into is this above always sounds great in "theory." Reality though is (when dealing with web applications) is that we need handles to HTTP (or at least a handle to a pojo that works with it in the background) and I don't see that ending - unless you go with a different framework like JSF or ww2 which seems to hide the HTTP out of the way and lets you use standard backing beans.
Sure you want a seperation between business logic and view presentation, but there are too many times that these are often very related to each other. In other words, sometimes you need stick stuff into the Request or Session based on the results of business logic. So in a case where you coded a set of chains without using an Action class, how do you accomplish this?
Let me create a dumb example to illustrate...
1) user submit form data 2) log the user's form data he submitted 2) run a query based on form data. build List of query results, make available in request for display 3) After looking at the query if X condition ends up coming back in the query results, I need to peform another query and make an ojbect from the results and stuff this object into the request 4) Else just stick the initial query into a List of objects, stick in Request.
Another example is imagine a chain set up
A_chainEvent B_chainEvent C_chainEvent D_chainEvent
To summarize my question, what if you need to stuff different things into the Request/Session based on things that happen in chains like B_chainEvent and C_chainEvent?
The problem I see is many times you'll be stuck in the middle of a chain cycle and you then need to interact with Request or Session (HTTP). It's this kind of ambigous logic that I find the most frustrating in web apps and I think ends up creating the most headaches for developers. The logic that deals with setting stuff up for display based on certain 'if logic' concerns that need to be looked at. In a pure commons-chain scenario (no Action, no Http tie in?) how are these kinds of things accomplished?
If I add stuff from a chain component into the Context object, will my front-end view have access to it? If so, then the commons-chain would be perfect. Without a concept of a backing bean in the Context (which ultimately I guess will be in Session or Request yet transparent to the user), I don't see how using a pure chain set up will be that useful in many situations.
-- Rick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
