OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Public Comment


Comment from: tjp@connectorWorks.org

Standard Portlets (WSRP or JSR168), Remote Scripting, and Page Reloads?

I have some questions about whether Portlets that adhere to the WSRP or JSR 168 specifications can also employ technologies like remote scripting without causing the "Consumer" to rebuild the entire page. I've already had some discussion with the JSR168 group and it seems that JSR168 and Remote Scripting don't play well together. I'm wondering where WSRP is on this issue...

I'm using the term "remote scripting" in the broadest possible sense to include technologies where a sub-section of a markup fragment (<span> or <div>) is dynamically updated via an asynchronous, background call to the server. The point of JSR 168 is avoid reloading the entire Web page and to provide a richer user experience than a typical Web page using hidden requests that are transparent to the end user. This is the technology behind the "rich internet application" movement a la Macromedia, Laszlo Systems, etc. 

I have two specific examples of Remote Scripting in mind:

a) JavaScript remote scripting (JSRS) 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 in response to some user action.

My questions are:

1) From a cursory reading of the WSRP specification (and the JSR 168 spec), it seems that both specifications require that all URLs embedded in a Portlet must be URLs that have been re-written by the Consumer/Portlet Container to force all traffic from Portlets back through the container?

In other words, is a Portlet allowed to make any server requests that do not use a re-written URL?

2) Is there a way to update sub-sections of a Portlet without having the Consumer/Portlet Container reload the entire page? In other words, do these specifications have any provisions for using remote scripting inside a Portlet?

My sense is that the two techologies "standard portlets" and "remote scripting" are incompatible at this time. This is a shame because it means that providing a rich Internet application experience in a portal will require developer's to abandon these specifications in favor or Portal Server specific approaches.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]