P@ Sunglasses

« XTech 2005 conferenc... | Main | This snake skin... »

e enjte janar 06, 2005

Java Enterprise Portal best practices for creating a new Portal for a customer

Today I got the following question from Rick Evans, our course developer. I'll answer in my weblog in order to start sharing this kind of information with the community, and hoping to trigger interesting comments. It has been a while I wanted to talk more about JES Portal in this weblog and this will be a good start.

I am curious what "the professionals" consider the best practice when creating a new portal in the field.

Or more importantly, what best practices do you want your customers to be taught?

-------
The following alternatives occur to me:

1. Customize/modify the Sample Portal itself.
2. Do not install the sample portal during Java ES installation, and create a new portal from scratch.
3. Create a new portal and install it as a new additional top-level portal.
4. Continue to use a suborganization for the new portal - hey, it works!
5. Other alternatives?

I appreciate any and all comments on what you recommend and the advantages/disadvantages of each approach.

Best regards,

Rick Evans
Portal Server Course Developer
"Good training makes everyone's job easier."

I'm a Portal architect and developer, so usually I either work on the guts of JES Portal, or develop new Portlets to be included in the release, or used by Professional Services or internally. So I'm not best qualify to answer this one, but I'll give my perspective. Professional Services folks such as Ulf Feger, Marc Perret or Jeremie Van Renterghem will probably have much better answers.

In order to develop a new Portlet I usually use the sample Portal as is, and create a test role. I then create a small display Profile fragment to add that portlet to the role, and create a channel using this portlet in one of the containers of the sample Portal. I then use dpadmin to upload the fragment to a running vanilla Portal for my role.

Thta is the easiest way to develop a Portlet, or Provider, with JES. It also has the advantage that when people who use your Portlet get your code, they have a small easy to understand display profile fragment to work with in order to test it in their staging Portal before real deployment.

On one project I also developed a container, ie something that lays out portlets on a page. For this I used the same methodology.

But I never developed a full Portal for a customer, but my take on this kind of project is to follow the good old XP (Extreme Programming) practice of working in small iterations getting at any time something that works. This rules out trying to develop a new Portal from scratch (which means creating a brand new display profile). Instead, reuse as much as you can of the sample Portal.

But which kind of reuse? Inheritance, using a suborg and specializing the display profile for it, or code level reuse, modifying the sample display profile. I'd say it depends on the scale of what you're doing: if you develop something really different from the sample (using custom containers for example) I'd say code level is best, else inheritance is best.

Anyway what I'd recommend is a bit different from the options you list. I'd leave the sample Portal as is, as a baseline and test that your system works fine. I would create a new Portal copying the sample one. Then start modifying the display profile, or create suborgs depending on the needs. But once more I may not be best qualify to answer this question: comments from field practitioners are welcome: Ulf, marc, Jeremie, when do you start your weblog?

( Jan 06 2005, 02:21:01 PD PST ) Permalink Chat about it