Nukes Portlet and Remote Scripting?

[tjp]

I'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?

[julien1]

In short you want to be able to perform the update of the fragment of a page. If you are familliar wit the jsr-168, the iframe fragment would get HTML content from the portal by invoking render or action/render only one the target portlet.

Today nukes structure is a little bit different and we are going to move on a jsr-168 implementation for nukes 2.x.

Our implementation will give some kind of extended portlet and the action request will give the possibility to the xportlet to do more than what portlet are doing : i.e send a web resource instead of performing rendering or redirection.

[tjp]

Thank you for the response. Yes, in short, I want to update a fragment of a page without having the entire page reload in the user's browser.

I'm a little confused by your statement:

If you are familliar wit the jsr-168, the iframe fragment would get HTML content from the portal by invoking render or action/render only one the target portlet.

You seem to saying that with JSR-168 the Portal will only send back the HTML fragment from the target Portlet as the source of my IFRAME. However, from my understanding of the JSR-168 spec, there is no way tell the Portlet container to only write the HTML fragment for a specific Portlet into the response stream, i.e. with JSR-168, the source for the IFRAME would include all Portlets on the page and I would have to parse my Portlet fragments from the response with JavaScript.

In other words, it seems like any request using a render/action URL will cause the Portlet container to write all Portlets to the response stream, effectively reloading the entire page. This is my understanding of the spec...now on to Nukes, because I just need a solution on Nukes and don't care if I need to abandon the spec at this time in order to do so.

With the current version, is there a way for me to tell Nukes to only write the HTML fragment generated by the target Portlet to the response stream?

[julien1]

from my understanding of the spec : I thing that the portal can render only one portlet, that decision is taken by the portal that decides to give to the portlet container a page with only one portlet, that page will action the single portlet and then render it.

doing it with nukes would require some modifications.

[tjp]

I'm building a Nukes Module right now. I will post my findings on using Remote Scripting in a Nukes Module upon completion. Thanks for your help.

[julien1]

Now "iframe" tags are allowed in the spec errata :

http://www.jcp.org/aboutJava/communityprocess/final/jsr168/Portlet_Specification_Errata.html

Issue 7

iframe Tag

Portlet specification forbids portlet to generate HTML fragment using iframe tag.  Further discussion leads to the conclusion that iframe tag can be used, though it must be used with caution.

Resolution

PLT.B Markup Fragments

[This section replaces line 9-10 on page 113 in the Portlet 1.0 specification, iframe is removed from the list of must not use tags and extra caution is listed]


Portlets generating HTML fragments must not use the following tags: base, body, frame, frameset, head, html and title. iframe tag can be used, however it must be used with caution. The usage of the iframe tag should not break the portal paradigm.