So, you are saying that your preference would be to include no ajax
integration and leave the framework and let users integrate this as
required - either directly in the HTML or by creating custom themes?
/Ian
--
From Down & Around, Inc.
Innovative IT Solutions
Software Architecture * Design * Development
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
web: www.fdar.com
email [EMAIL PROTECTED]
phone: 617.821.5430
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[EMAIL PROTECTED] wrote:
I'm going to take a moment to chime in here as I've been watching this
thread develop. I'm going to come out in the open and say I've never used
DWR or even looked at it's documentation. When I've used ajax
functionality in the past we've simply made the XmlHttpRequest hit an
action that in turn hits a JSP page with the contentType set to xml. I've
done this on several different apps and it always works fine. We even
created a modified interceptor stack that stripped out the stuff we didn't
need and left it to the basics like authentication, validation, etc.
Furthermore using a JSP page as the result we had access to all the
taglibs we needed. I can see where this may get a bit heavy if you're
doing a lot of XmlHttpRequests (e.g. in a Google Suggest type situation)
however I think for the majority of apps it should work fine.
-Brian
On Wed, May 24, 2006 12:32 pm, Alexandru Popescu wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
