In the previous part we saw the advantages of aggregation and WSRP for splitting responsibilities, we will now 'finish' this little literature with some other advantages of using a Portal framework.
Personalization
Personalizing the content displayed to a user is the other main area where portals shine and bring value. Not only the users have a transparent single sign-on among all the web applications that are part of a portal, but they can set their own preferences and customize their experience. Preferences can be about the content (get the weather forecast info for my place) about the language, (get the weather forecast in french), about the way to render (display only the weather, i don't need the temperature) and so on (number of posts per page to show on a forum ...). Those preferences can be persistent and stored by the portal framework without having to care on how this is done. See previous blog entry about personalization.
A step further in personalization out of the scope of the Portlet specification (since i am now talking about portal) is the ability to have a personal dashboard to create portal pages and place portlet windows on them a bit like iGoogle or NetVibes do.
What to expect from a portal
One cannot expect a portal framework to satisfy all his needs and support all kind of use cases. While vendors try to provide out-of-the-box features for most common use cases, many other use-cases are left behind. The only option here is to look at the extension points of the portal and see if you can customize the portal to your needs.
When not to use a portal
Since a portal is mostly about aggregation of applications, a unique simple application like a web-blog wouldn't really benefit from a portal infrastructure. That said once you want to make it coexist with another application you may want to “portletize it”, choose your web-framework in consequence so you won't have to rewrite it from scratch. That could be a key factor to choose your web framework and could be the subject of a future blog entry.
The navigation in a portal is somehow different than a traditional website, the end-user navigates among several web applications on a single page and that's not a traditional scenario.
A portal is not made to split one application into windows. The goal of the portlets is not to have in one window the categories of your blog, in another the blog entry and in a third one the comments for this blog entry. The portlets should be distinct applications (one blog portlet), remember than in the first version of the spec, communication between portlets are not even possible in a standard away (except from the web application session, but this is mostly a hack. It will be possible in the second version of the spec.).
If a portlet state depends too much on the state of another portlets, it probably means that those two shouldn't be separated but you can still use a templating system inside your portlets.
That said, it doesn't mean that one application shouldn't be composed of several portlets. For example, a CMS portlet could have a portlet to view the content and another to edit it. The concerns are distinct, one portlet doesn't act on the other and the only link between them is the underlying database.
I did not mean to list all the benefits of using a portal here, but to give you a first approach of the main reasons why using a portal will not only bring value to the users but also to the developers by separating the concerns of the different parts of your web application.
As a conclusion, ask yourself if your application may benefit from coexisting seamlessly with other applications and if the portal framework and available components can reduce your development time by providing some of the features you require.
No comments:
Post a Comment