The Proposals Wiki has been deprecated in favor of creating Feature Requests in JIRA. If you wish to propose a new idea for a feature, visit the Community Ideas Dashboard and read the Feature Requests Wiki page for more information about submitting your proposal.
« Back to FrontPage

Simple Remote Portlets

Discussion of Design/Implementation Approach for the Iframe and object solutions #

Producer and consumer specification #

A) The producer must provide information to the consumer about the portlet #

The producer must provide information relative to:

  • Title
  • Recommended size for the view area of the portlet
  • Available modes of the portlet

This information should be provided in response to a call to the method getPortletInfo(). Here is an example:

 <script>
 function getPortletInfo() {
    return {
      title: 'My portlet title',
      viewArea {
           height: screen.height
      },
      portletModes: {
           edit: {
               url: '{{{http://...............}}}',
               name: 'Whatever',
               name_es: 'Lo que sea',
           },
           config: {
               URL: '{{{http://...............}}}',
               name: 'Whatever',
               name_es: 'Lo que sea',
           },
       }
 }
 </script>
 Note: It's not yet clear if it's possible for the consumer to call a function present in the content of the iframe due to security restrictions. An alternative solution would be having the iframe call a function on the parent. This alternative brings a new problem: how does the portlet inside the iframe identify itself?

JN: I guess it's too bad that both modes and window states are displayed together in the title bar... Claerly window state should just be a client side operation, but if we could iframe the title bar with the frame, then we would just get the modes already there with the correct links too. Have to think about this some more...

B) Window state change requests #

B.1) Window state is changed by clicking a link in the consumer The consumer is responsible for keeping the content that is currently being shown:

  • Solution 1: Consumer uses client size maximization (recommended)
  • Solution 2: Consumer uses server side maximization and must find out the current iframe URL to send that information to the server-side code. The server-side code must obtain this information and use it when the page is reloaded so that the iframe content that was being shown is preserved
    • Might not work when the last request inside the frame was is a POST
      • Solution: use JavaScript to keep track of the last GET request and use that + suggest portlet developers to use the REDIRECT after POST pattern if the portal does not do it for you.
    • It will not work when the portlet is using AJAX for navigation or changing contents and not updating the URL accordingly to support reload
  • Solution 3: similar to solution 2 but storing the last URL in a cookie rather than passing it to the server

B.1) Window state is changed by clicking a link in the portlet The producer must add JavaScript code in the response to notify the consumer by calling method remotePortletsContainer.setWindowState(). Example:

 <script>
   parent.remotePortletsContainer.setWindowState("maximized");
 </script>

C) Portlet mode decoration #

D) Portlet mode change requests #

  • When a mode change is performed (config, edit, etc....) a similar solution to that used for window state changes is used.

Advanced functionalities #

Portlet communication #

  • Done completely in the client side
  • Study if it's possible to implement an event system
    • Question: how does the portlet receive the event and how does it respond to it?
    • Option 1: Call to actionURL that has been associated with meta data for that event

Remote selection of portlets #

  • Simple RESTful service
  • The consumer allows the users to set a list of URLs that link to an XML or JSON listing of portlets provided by that portlet.
  • The listing provides the full URL for the initial view of each of the portlets

Discussion of Design/Implementation Approach for the proxy solution #

Comments#

Implications on Liferay Portlet Rendering Lifecycle

We should explore the idea of using this technology in Liferay's own portlet rendering cycle.Currently Liferay's parallel rendering feature is somewhat similarly implementing this idea. Once this specification is brought to fruition and implemented, the parallel render engine should use this same interface. This will give you an implicit unit test of this feature as well as following the "eat your own dog food" practice.

This is very similar to Oracle's implementation of WSRP, they use it to render their portlets internally. The MAJOR difference here is that this approach is RESTful and will not incur the performance and development overhead of WSRP.

myoung

0 Attachments
12403 Views
Average (0 Votes)
The average rating is 0.0 stars out of 5.
Comments