On Wed, May 24, 2006 12:09 pm, Joe Germuska 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.
That would echo my experience as well... and I'm sure if we both look back, we were probably guilty of it ourselves at one early time or another :) I agree it's best practices to call the business facade directly, but what I'm saying is I'm not sure it *should* be best practices... If we were to assume that developers wrote Actions correctly, i.e., very thin and not much more than an entry point, then I think the benefits you get of calling the Actions, i.e., common security, all that the request processing does for you, only having one thing to call regardless of how the call is made, and so on, outweighs any negative there may be, and I'm not sure what negative there really is if the Actions really are thin :) I'm not so sure integrating it in the way Alexandru has apparently done would encourage bad design... I mean, certainly we've all drilled it into each others' heads for a while now that Actions shouldn't include business logic of any substanative amount... if someone chooses to ignore that admonishment just because DWR is there, I think there's a bigger problem, right?? LOL >>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'm not sure I follow this point... I would absolutely agree that if any Struts behavior is duplicated in DWR it's, as you say, peculiar at best. That's why I like what Alexandru has done, which is exactly what I had suggested on the DWR list a while back: instead of essentially an IPC call from the DWR servlet to some class (inter-JVM I guess is more accurate), be it an Action or not, instead make an HTTP request through Struts (or WW, or JSF, or whatever) to the appropriate end-point, of course an Action in the case of Struts. This requires that the incoming request to the DWR servlet be marshaleld into a new HTTP request, and from that point on, Struts simply does its thing. The question that remains of course is what is the response? My guess is that Alexandru has a JSP that renders XML or JSON or something like that, which then gets marshalled back into whatever form DWR sends back to the client. I suppose that's an implementation detail though :) >> > 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. You are of course right, you don't have any of that with a DWR request... well, I suppose technically you *do* have request parameters, but I'm not sure what form they are in... maybe JSON in a POST body? Your right though, it's clearly not the same as a form submission to an Action. But again, if DWR makes a new HTTP request to an Action, and can then take whatever the response is and marshall it into the form it sends back to the client, that doesn't sound like a square peg in a round hole to me... it's just DWR acting as a marshalling proxy to Struts or WW or whatever else. In another reply to Alexandru, I mentioned the possibility of swapping out the class DWR calls in his application and swapping in one that creates a SOAP message and sends it to a remote Web Service. That I think is a fantastic capability because the calling syntax on the client is identical in both cases. The details are hidden behind the DWR servlet. The same is true of making a request to a Struts Action. This is a fantastic discussion by the way, I really think a lot of good ideas are coming out of it, from both points of view :) > Joe Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
