Web 2.0 user interface
Web 2.0 portal theme with support for client side aggregation:
The portal can use client side aggregation (CSA) instead of server side aggregation (SSA). This has the following advantages:
- Faster rendering and performance
- Desktop like user experience
- Existing portlets that were written to the server side programming model can be tied in by using AJAX. For example, such portlets can be refreshed individually rather than rerender the whole page.
- The use of the portal Web 2.0 theme for portlets in the portal is optional. Server side aggregation is provided as a fallback option. For example, if the browser does not support JavaScript, the "old" portal rendering procedure is still available.
Client side portlet programming model:
Use the client side programming model for your portlets. You can do everything with the client side programming model that you can do with the server side portlet programming model. Additionally, the client side programming model has the following advantages:
- Improved user experience by faster responses and performance, as many interactions are processed on the client side rather than on the server.
- User customization of user profile, preferences, and changes to the portlet state are done locally, and therefore with a faster response time. A fragment that contains the customization is later sent to the server and saved.
- The user experience is consistent between both client side aggregation and server side aggregation. The user cannot tell the difference between CSA and SSA, except that CSA performs better.
Live text
Live text provides elements embedded in portal pages that become active in the browser and are enhanced with additional functionality by JavaScript libraries. For example, if you include portal user IDs in your portlet output and mark them as live text, users can click on these IDs in the browser and see a person info card or a context menu that allows them to send a mail to the person. Live text has the following advantages:
- Live text allows easier click to action.
- You can adopt new portal content within your company more easily, as it is now easier to handle portal tags. For example, you can write tags and make them available centrally, and UI developers can reuse these tags for in their portlets for various purposes.
- Content editors can add meaningful live text elements to portlets without requiring portlet development knowledge.
- You can embed content from other sources, for example, from a HTTP or .NET server.
REST services
Portal now offers the following Rest services:
- Layout model
- Portlet model
- Content model
- Navigation model
- Wire model
- User profile.
By the use of REST services you can write your own advanced Web application and build it on top of new REST (Representational State Transfer) services that provide the XML request information.
- REST services allow you to access portal models remotely for both read and write access. The Navigation model allows read access only; it is updated by changes made to the content model.
Controller SPI:
The Controller SPI is a new public portal interface. It is not directly related to the new type of Web user experience, but it allows you to perform certain administrative tasks more easily.
Terminology
These are terms that are used in the documentation for the new features:
- CSA
- Client Side Aggregation
Aggregation based on JavaScript and XSLT transformations that are executed on the client. This is the new aggregation model that provides an improved user experience by faster response and performance.
- SSA
- Server Side Aggregation
This means aggregation based on JSPs that are executed on the Server. This is the "old" portal aggregation model; this still works as before.
- Pure Server Side Portlet
- This is a normal server side portlet that uses Java and JSPs; it usually uses no JavaScript. Portlets that are written to the client side model use no or few JSPs.
- AJAX Portlet
- This is a normal server side portlet that uses lots of JavaScript and AJAX technologies and less Java & JSPs.
- DPR
- Differential Page Rendering
This denotes the server side rendering model that is used by the Web 2.0 theme. The concept of DPR is to render only those parts of a portal page that were affected by the a user interaction.
For example, if a user interacts with a single self-contained portlet that runs in the Web 2.0 theme, the portal refreshes only this portlet rather than the entire portal page.
- REST
- Representational State Transfer.
Parent topic
Designing a portal site