|
Elements of a Portal Page
Every portlet page is made up of one or more than one portlet windows. Every portlet window is made up of two parts: one is the decoration, which will decide how the title bar, controls, and borders of portlet windows will appear. The second part is the portlet fragment, which is the part contributed by the portlet application.
Your portal server decides the overall look and feel of the portal page, such as the logo, the colors of the title bars, the images for the controls, etc. By changing a few standard JSPs and .css files, you can change the complete look and feel of your portal.
Most portal servers are basically web applications deployed in an application server, using a servlet for handling requests to the portal server. If you take a look inside of your Pluto installation, you will find out that Pluto is a normal web application, deployed in your Tomcat server. Take a look at C:\PlutoInstallation\pluto-1.0.1-rc1\webapps\pluto\WEB-INF\web.xml and you will find that org.apache.pluto.portalImpl.Servlet is mapped to get all requests pointed at the Pluto server.
Earlier, in "Elements of a Portal Page," we said that a portal page is made up of two types of content. One is content generated by various portlets on the page, and other is content generated by portal server.
In Pluto, whenever the user makes a request, control will go to the servlet. Depending on what page is requested by user, it will determine a list of portlets that need to be displayed. Once it has this list, it will pass control to these portlets in different threads and will collect content generated by them.
As for content contributed by the portal server (things like look and feel of the portal site and the decoration and controls for each portlet), the portal server depends on JSPs in the C:\PlutoInstallation\pluto-1.0.1-rc1\webapps\pluto\WEB-INF\aggregation folder. RootFragment.jsp is the main JSP, which decides the overall look and feel, and alignment. It includes Heads to decide what should be included in the <HEAD> tag of the generated page. Then it uses Banner.jsp to choose what should be displayed in the banner--by default, it will include pluto.png for displaying the banner. TabNavigation.jsp is used to decide the navigation scheme of the portal site. What this means is that you just need to change a few JSPs in this folder to change the whole look and feel of your portal site.
Depending on settings in pageregistry.xml, Pluto will decide how many rows a page should have, and use RowFragment.jsp to render it. It will use ColumnFragment.jsp to render each column. Then PortletFragmentHeader.jsp is used to render the header of every portlet; i.e., the title bar and the controls for minimize and maximize. footer.jsp is used to render the footer of the JSP. If you look at the HTML generated by portal page, you will find out that every portlet window is nothing but content inside a <TD> tag.
Conclusion
For any new technology to be successful, it should have few qualities: first, it should leverage existing technology; second, it should solve common problems of existing technology; and third, it should provide you one more layer of abstraction. (As they say, every layer of abstraction solves half of the problems.)
The Portlet API has a very good chance of succeeding servlet technology, because it is capable of using the existing application server infrastructure. You can call an EJB from your portlet, or you can start and participate in a global transaction controlled by the application server. In other words, your portlet can do pretty much every thing that a servlet can do, in a much more business-logic-centric way.
Portlets provide you with a layer of abstraction because now you no longer have to worry about what HTTP method is used by the client, or create your own infrastructure to capture client events like button clicks. Last but not least, portlets solve most of the common problems of servlets by providing services for things like single-sign-on, personalization, etc.
|
Login
Register
FAQ
Search
