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.
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.
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).
- 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:
- Implementation of Lifelet Creator and Lifelet Runner and the Gadget engine
- Implementation of the Exhibit engine
- Implementation of the Stored Preferences engine.
- Global sharing
- Export as a WAR/XML
- Add an API to portlets with relevant data (Calendar, MB, Journal, ...) to access it in a JSON format
Optional future developments:
- 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
- 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:
- Exhibit engine:
- 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)
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
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)
Anandi|anandi 00:58, 27 May 2007 (PDT)