Nukes Portlet and Remote Scripting?
tjp Apr 8, 2004 6:09 PMI'm a Nukes newbie and have some questions about whether Nukes-specific Portlets can employ technologies like remote scripting without causing the Portal to rebuild the entire page?
I've already had some discussion with the JSR-168 group and it seems that JSR-168 and Remote Scripting don't play well together.
Consequently, I'm surveying the various Portals to see if using the Portal specific Portlet framework (vs. JSR-168 or WSRP) allows a Portlet to make background calls to the server to update sub-sections of the Portlet without having reload the entire page.
I'm using the term "remote scripting" in the broadest possible sense to include technologies where a sub-section of a markup fragment ( or ) is dynamically updated via an asynchronous, background call to the server.
The point of "remote scripting" is to avoid reloading the entire Web page in order to provide a richer user experience than a typical Web page. This is the technology behind the "rich internet application" movement a la Macromedia, Laszlo Systems, etc. where single-page solutions are the cornerstone.
I have two specific examples of Remote Scripting in mind:
a) JavaScript remote scripting (JSRS) is a JavaScript framework that uses a hidden IFRAME embedded into the Portlet markup fragment to make asynchronous calls to the server to dynamically update sections of the Portlet without reloading the entire Portlet. Briefly, JSRS works as follows:
1. JSRS uses a hidden IFRAME to make background calls to the Server
2. JSRS sets the URL for the IFRAME's src to invoke a Servlet; updating the SRC in JavaScript triggers a call to the Server.
3. The response written by the Servlet is just HTML that uses an onLoad JavaScript event handler to callback into the JSRS framework
4. The onLoad event is fired when the browser loads the new page for the hidden IFRAME, this triggers the JSRS callback mechanism that allows my Portlet to update a section (using a SPAN or DIV) on the Portlet in a dynamic, asynchronous manner.
(see Brent Ashley's JSRS site: www.ashleyit.com/rs)
b) Flash Remoting. If my Portlet is a Flash Movie (the HTML fragment generated by the Portlet uses a Object/Embed tags to include an SWF), then the Flash Movie could use an XMLSocket object in ActionScript or the Flash Remoting API to talk to a Web service to dynamically update sub-sections of the Portlet, such as dynamically populating a ListBox with a database query in response to some user action.
I have two (2) questions:
1) From a cursory reading of the JSR-168 specification, it seems that all action-oriented URLs embedded in a Portlet must be Action URLs that have been re-written by the Portlet Container to force all traffic from Portlets back through the container. Does Nukes impose a similar restriction on the Portlet designer?
In other words, is a Nukes specific Portlet allowed to make any server requests that do not use a re-written Action/Render'ish URL? For example, can a Portlet include JavaScript that uses a hidden IFRAME to send a GET request to a Servlet running in another Web application in the same JBoss instance?
I understand there are single sign-on issues that need to be addressed when crossing Web application boundaries, but assuming you configure the application server so that security credentials propagate from the Portlet Web app to this other Servlet, can you do this with Nukes?
2) If you cannot use something like JSRS or Flash Remoting, is there a Nukes-specific way to update sub-sections of a Portlet without having Nukes reload the entire page? In other words, does Nukes have any provisions for Portlets that need to make background calls to the server to update sub-sections of the Portlet UI?