Brad Neuberg wrote:
> On Thu, 13 May 1999, Craig R. McClanahan wrote:
>
> >
> > OK, in the case you cited as an example:
> >
> > <A HREF="somelink" jsp:onClick="bean.someMethod(event)">Look mah, a
> link!</a>
>
> Here's how you would handle this. On the server side the line right above
> would be converted into the following:
>
> <A HREF="somelink"
> onClick="sendEvent(event,'bean.someMethod(event)')">Look mah, a link</a>
>
You can write this code directly in your JSP page as well ... there's no need for
server-side translation support to get
this far.
>
> sendEvent is a javascript function that would be inserted by the JSP
> engine:
> <SCRIPT>
> function sendEvent(event, method_to_call) {
> .... defined here
> }
> </SCRIPT>
> The sendEvent javascript function sends a GET request to the server with
> the following CGI query variables at the end:
>
>?jsp_callmethod="bean.someMethod(event)"&jsp_eventid=event.id&jsp_eventtarget=event.target&jsp_eventsource=event.source
>
Ah, so it's really a JavaScript change that you're after!
I don't see any existing mechanisms for JavaScript to directly do an HTTP GET --
although you can do it by using
LIveConnect (where supported) to talk to a Java applet that does it for you -- but
again that's all client side stuff.
Now whenever the user clicks on that link the server side program can
> respond by doing some action; you could probably wrap this with the Event
> pattern so that the server side object then receives an Event object
> telling it an event has occurred (it would be a JSPEventListener).
>
Lots of people use applet->servlet requests for exactly this purpose. The applet sets
up parameters that describe what it
wants, sends an HTTP POST request to a data-serving servlet, and the servlet returns a
stream of serialized Java objects
(or whatever else makes sense for your app). Then, you can "LIveConnect" the results
back to JavaScript. The HTTP
request-response paradigm *is* an event-processing pattern already -- responding in
the form of dynamically generated HTML
is merely the most common usage.
>
> The sum result of all this is that you can truly start using HTML as your
> user interface. I don't know about you but I'd rather be using HTML and
> Dynamic HTML as my user interface than Swing.
>
I agree with the sentiment, and the desire to have the dynamic interaction
capabilities *within* a page (although this
idea works much better on an Intranet where you've got reasonable transport speeds)
... I just don't see any need to
modify JSP to get there.
Craig
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
