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

Lifelets Framework

Project Description#

This project proposes the implementation of a framework to support Lifelets as a complement to portlet development.

When are Lifelets useful? #

Lifelets are specially useful in portal deployments for hosting environments or portals with a large user base. In this scenario it is very difficult for a system administrator to know in advance all the functionalities that the users may want or need so the best solution is to provide them with a tool to create their own applications. The largest portals in the world such as Google, Yahoo and MSN, have already acknowledge this fact and are already offering a way in which the users can implement their own applications that themselves or other users can later use in their customized pages.

A second scenario in which Lifelets are useful is related to the increasing importance of Mashup technologies. These technologies allow users to develop applications by gathering information from different resources, generally using client side technologies such as HTML and Javascript. Lifelets can act as a framework that helps in the creation of this type of applications in a way that integrates seamlessly with existing tools for portal environments developed as portlets.

What is a Lifelet? #

A Lifelet is any application that can be developed directly by portal users as a way to improve the functionality provided by the portal. It provides the following benefits when compared to portlets:

  • It requires less time and knowledge to develop
  • A Lifelet is immediately useful once developed because it is build using a web interface provided by the Lifelet framework (which is part of the portal)

On the other hand a Lifelet framework:

  • Does not offer a full development environment that would allow any type of application
  • It does not support server side technologies throughly to avoid security issues

In conclusion, a Lifelet should be seen as a way to develop not very complex applications that will be available for use right away. They also provide an easier entry point for people wanting to develop applications for portals, lowering the learning curve usually associated with portlet development. For more complex applications the use of portlet frameworks is still preferred.

Why the name? #

A Lifelet is a Liferay Application and the name follows the same convention as applets, servlets, portlets, etc.

Another suggested name that also expresses its purpose and its relationship with portlets is Live Portlets.

Project Requirements/Objectives#

The development of a Lifelet framework involves the following modules (all will be implemented as portlets):

  • A Lifelet Creator: It is a portlet that allows users to create and administer their Lifelets
  • A Lifelet Runner: It is a portlet that executes a Lifelet

Once a Lifelet has been created it will appear to the users that have access to it in the 'Add content' pop-up just as portlets are now shown. The Lifelets will also be organized in categories.

The Lifelet framework will provide a flexible architecture that allows different Lifelet Engines to be plugged in. An engine contains the code necessary to aid the user in the creation of an specific type of Lifelet and to run it. This extensibility helps to overcome the simplicity imposed to development of Lifelets by allowing engines to have the complex functionality for very specific types of applications. The following initial engines are planned:

  • Gadget: It's a generic type of portlet that allows the creation of applications using server side technologies (inspired by Google Gadgets).
  • Exhibit: is a type of Lifelets that uses Exhibit from the SIMILE project to allow creation of data oriented applications through the web interface requiring only HTML and basic Javascript knowledge. The data is obtained in JSON through any of the following methods:
    • An external URL: This allows aggregating and showing external data into the Lifelet. It's specially useful thanks to the availability of REST APIs such as that provided by Yahoo that offers the response in JSON format
    • A portal URL: The portal will provide an API to retrieve relevant data (Calendar, MB, Journal, ...) a JSON format
    • Explicit data: This allows users to directly specify the data in a textarea.
  • Stored Preferences: It's the simplest type of Lifelet and consists of a reference to an installed portlet and a set of preferences for it. An example would be an RSS portlet. This portlet when added to a page is empty or has the configuration provided by the administrator. Through the Lifelet framework, the user can store several configurations of it as Lifelets such as "Latest news of the world", "Sport news", "Technology news".

In addition to the specific steps required by each engine, the Lifelet framework will offer a tool that will allow Lifelet creators to add configurability for them through preferences. When creating the Lifelet a form will be defined that will be later interpreted by the Lifelet Runner to allow the final user to specify the desired preferences for each specific Lifelet instance.

Initial Project Scope#

The project is planned in the following phases:

  1. Implementation of Lifelet Creator and Lifelet Runner and the Gadget engine
  2. Implementation of the Exhibit engine
  3. Implementation of the Stored Preferences engine.
  4. Global sharing
  5. Export as a WAR/XML
  6. Add an API to portlets with relevant data (Calendar, MB, Journal, ...) to access it in a JSON format

Optional future developments:

  1. A server side filter to convert XML into JSON: would allow doing mashups with Exhibit of data that is originally provided in XML instead of JSON
  2. Other engines

Discussion of Design/Implementation Approach#

The Lifelet Creator portlet will store each Lifelet in a table in the database. The columns of this table would be:

  • id: long
  • ownerId: determines the scope of the Lifelet
  • name: XML with the name of the Lifelet in several languages
  • preferencesDefinition: XML specifying the form to show the end users to set the preferences for a portlet instance
  • engineDefinition: XML specific to each engine

The XML used for the preferencesDefinition will be the same (or be inspired by) the one currently used by the Journal portlet to define content structures.

The engineDefinition for each of the defined engines will have the following fields:

  • Gadget engine:
    • Code
  • Exhibit engine:
    • JsonURL
    • JsonData (only one of JsonURL or JsonData will be used for one specific data)
    • Code: HTML
  • Stored Preferences engine:
    • Preferences (same XML as that used to set default preferences in the portlet.xml file)

Comments#

Server-side Lifelets

We should also explore using [Groovy | ]/[Grails | ] or similar to implement server-side mash-ups. This will allow you to create complex applications on the fly due to the dynamic class creation ability of these scripting languages

myoung


Server-side Lifelets

Groovy is pretty wild don't you think? I was just at the New England Java Users Group for a presentation on grails and groovy.

Another thing we might think about is allowing people to leverage XFORMS (chiba). We could the provide a set or ready-made controllers to manage the XML on the way in and out.


I like the idea of Groovy or other scripting languages, but as they are executed in the server some security issues could arise. I think that's something that has to be thought carefully. A similar alternative that someone suggested me was using velocity, because Liferay already has a way to access it's services from it. And it was the advantage of being less powerful and thus having less harm potential.

Related to Xforms it's certainly a great idea. Ray is already doing some work on that direction.

Jferrer|Jferrer 04:00, 11 February 2007 (PST)


XForms support would be great, and regarding serverside security i was liking idea of full client side (javascript) implementation of XForms http://www.formfaces.com/. It is available with bsd license.

Anandi|anandi 00:58, 27 May 2007 (PDT)


0 Attachments
9523 Views
Average (1 Vote)
The average rating is 5.0 stars out of 5.
Comments
Threaded Replies Author Date
Have you seen http://www.springsurf.org/ and... Paul Hussein November 12, 2012 5:43 AM

Have you seen http://www.springsurf.org/ and its integration with Alfresco.

Alfresco use a similar mechanism where you use the CMS to drop some javascript onto a page. That javascript is then callable, or can generate a UI.
Posted on 11/12/12 5:43 AM.