On 5/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
On Wed, May 24, 2006 10:32 am, Alexandru Popescu wrote:
> In the DWR-WW action invocation toy I have used when building
> InfoQ.com, 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 :-).
./alex
--
.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
