struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <>
Subject Re: JavaOne Ajax Discussion
Date Wed, 24 May 2006 15:10:55 GMT
On 5/24/06, Frank W. Zammetti <> wrote:
> On Wed, May 24, 2006 10:32 am, Alexandru Popescu wrote:
> > In the DWR-WW action invocation toy I have used when building
> >, the action invocation passes through exactly the same
> > process as a normal request, so I have no concerns.
> 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.  However, that's a completely different calling
> mechanism for DWR, as I mentioned when I originally made the suggestion...
> I suggested something of a pluggable architecture in terms of the calling
> mechanism from DWR to the target object, so you could do an IPC call as it
> basically does not, or an HTTP request, or RMI, or whatever else... I
> don't see that as being a problem, but it *does* fundamentally change the
> way DWR works now, at least (a) as far as I understand it and (b) in this
> case specifically for WW, as it obviously couldn't be the *only* way it
> works.

Not sure how to read it, but call it request, or XMLHttpRequest it is
still a request hiting your server. Probably on the comet-part things
may be different, but that's completely another story.

About the other things I fully agree: a framework should never provide
something that  shoots the user in his foot... but a framework will
never be able to guarantee that if the user especially wants this to
happen it will not be able to do it :-).

.w( the_mindstorm )p.

> > That's in fact a good example of my arguement: good developers will
> > always know what to do to protect their site. Bad developers will not
> > know this. We are preparing a framework so that they are gonna use. If
> > they want to use it the wrong way, I would say that this is definitely
> > their problem. From my pov I just want that the simple things to be
> > extremely simple, and complex things possible. Other than this, it is
> > developers talent.
> Well, you certainly won't get any argument from me that you have to count
> on developers to be smart to a large extent :)
> That being said, I think there is still a difference between simply
> providing a framework where developers can either be smart or shoot
> themselves in the foot, and providing things that either (a) directly do
> something that a smart developer probably wouldn't do or (b) make it seem
> like it's the right way to do things.
> For an example of (a), imagine Webwork provides a Google Suggests widget
> that makes an Ajax request on each keystroke... that's something a smart
> developer wouldn't do, as I think we just agreed! :-), so WW shouldn't
> provide that out-of-the-box.  For an example of (b), even if such a widget
> was only part of an example app, people tend to look at those as defining
> best practices, so doing something that, at least arguably, isn't a best
> practice, should be avoided there too.
> As for the simple things extremely simple and the complex things
> possible... so long as the simple things aren't made extremely simple by
> doing them in a less than optimal way (i.e., a widget sending requests on
> each keystroke), then of course I agree :)
> > ./alex
> Frank
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message