On 5/24/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
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.
Would you rather prefer to have your requests served directly by your
services? Or by the domain model objects? I think that an action is a
pretty good idea of a gateway.
>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 think you are looking in the wrong direction here. Things are much
more simpler than you imagine and they need almost no duplication. I
have done this... and the proof is online and working. All my
teammates were very happy with this solution and it brought a lot of
reusability in our sourcecode.
> > 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
I guess that for some the square pegs are not square or at least they
fit extremely well into the round wholes :-).
./alex
--
:Architect of InfoQ.com:
.w( the_mindstorm )p.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
