At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote:
On Wed, May 24, 2006 11:12 am, Joe Germuska wrote:
> Forgive me if this has been covered elsewhere, but I'm still confused
about why someone would want to "integrate" DWR with Struts? I've
only used it a bit, but in each case, I didn't really see much value
in coaxing it to work through Struts' request processing model.
They co-exist quite peacefully in a webapp without needing to know
anything about each other.
I think I can answer that by asking what you would want DWR to call? I
would say that in a "properly-constructed" webapp, you have a business
facade, and that is what you would want to call via DWR. In that case, I
would tend to agree, integration probably isn't a big gain.
If you are intent on calling Actions though, that's where I think
integration makes sense...
but if you want to model best practices, then you have to ask "why
would you be intent on calling Actions"? I'm not trying to build
walls so that people can't just get-the-job-done, but I do know from
experience that people tend to overload Actions with too much
business responsibility, and integrating DWR with Struts would only
encourage that.
I tend to view an pplication as a collection of loosely-coupled services,
and an Action is the gateway into a given service. The Action is still
doing little other than delegating to some business class, but it's still
the starting point that the external world (i.e., the client-side of my
app) sees. To that way of thinking, making a call via DWR should go to an
Action, not directly to the business facade, because it's really just a
different calling syntax to the same service.
But then you raise the question you had earlier, which is that
Actions are generally written so that they can assume certain context
which is established by Struts before they are called; duplicating
all of that behavior in DWR seems peculiar at best.
> I would think it probably better to advise people to use
ServletFilters where they want common behavior on every request.
Then what's the point of Webwork? :) Interceptors are quite akin to
filters conceptually, yet we're all thrilled with the idea of interceptors
in SAF2.
But we're thrilled with interceptors when we have a common process
for receiving input (http request parameters) and a roughly common
process for responding (by dispatching to a view). A DWR request has
neither of these, and it seems like square pegs and round holes to
try to get a DWR request to fit into a Struts request-handling
process.
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
