On Wed, May 24, 2006 11:12 am, Joe Germuska wrote: > At 10:46 AM -0400 5/24/06, Frank W. Zammetti wrote: >>I haven't seen your work, so I can't talk intelligently about it... I >>would agree though that if DWR is going to make HTTP calls to execute >>Actions (a suggestion I might add that I made about two months ago to Joe >>with regard to how to better integrate with Struts), then that certainly >>alleviates my concern. > > 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... 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. In my case, I have external security that secures each "service". And I'd still want a call made via DWR to leverage that security. There might also be, if we start talking about Webwork, interceptors that deal with some cross-cutting concerns that I'd still want executed (maybe logging, as an admittedly lame example). As DWR stands today, the servlet effectively bypasses any of this sort of thing, so integration I think starts to make sense there in order to make sure those things still happen with a DWR request. > I'd think a well designed application would have both Struts Actions > and DWR remote objects obtaining services they need from the > ServletContext, Spring, or some other independent mechanism, and DWR > doesn't need to render a view in any conventional way... so what is > left for Struts to do? Right, basically what I said above :) But as I mentioned, I'm not sure calling the business facade directly is the right answer (this is at least debatable), and I'm not sure I see the point in having extra classes that are specially present for DWR to call... sounds like extra work to me :) My goal is to have any external request, of any form I intend to support, going through the same "stack" of operations, excepting the things that necessarily have to be different (i.e., an incoming request in the form of a SOAP message can't, without extra processing, go through a step that populates some bean with request parameters obviously). > I admit that I did extend DWR so that the ExecutionContext could > provide a reference to a Struts 1.3 ActionContext (or rather, my > custom subclass of it), so that I could maintain consistency in how I > interacted with various session attributes... but it seems to me that > anyone who is extending ActionContext is also in a position to extend > DWR where necessary. True, but if the intergration was there from the start they likely wouldn't have to do it themselves :) > 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. My point is that while I agree that advising the use of filters for common behavior is a good idea, and also jives with the advice I tend to give in those situations, not having to do that extra work because there is integration that eliminates the need is even better :) > Help me out here... Did I? ;) > Joe Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
