Tuesday Sep 20, 2005

Creator 2 EA and Apache's Pluto Portlet Container

For those of you using the new portlet development feature of Creator, you've probably noticed that the "Pluto":http://portals.apache.org/pluto/ portlet container is deployed each time the portlet application is deployed.

!http://blogs.sun.com/roller/resources/david/plutodeployment.png!

Let me explain why I made this design choice.

The "Pluto":http://portals.apache.org/pluto/ driver, the code that wraps the "Pluto":http://portals.apache.org/pluto/ portlet container, doesn't support “hot” deployment of portlets. This means if you change the Pluto driver configuration on the fly, "Pluto":http://portals.apache.org/pluto/ won't pick it up. There has been code contributed to the "Pluto":http://portals.apache.org/pluto/ project that will allow you to force this with a HTTP get command.

In Creator EA2, the Pluto driver configurations are set each time a deploy is done. Then "Pluto":http://portals.apache.org/pluto/ is deployed with the possibly-changed configuration each time. So why don't we check to see if anything is changed before we bother to deploy again? I thought about doing this but since the actual deployment only takes a few seconds, I thought the extra processing wasn't worth it.

Much of this design assumes that the developer is OK with one portlet per project and one portlet deployed at a time in Pluto. If you can document some interesting and real use cases to prove this assumption is wrong, please email me directly or comment on this entry. Keep in mind that most developers will be developing for a \*different\* portal than "Pluto":http://portals.apache.org/pluto/ . Hence, showing multiple portlets in "Pluto":http://portals.apache.org/pluto/ won't really give an accurate representation of the end product.

Let me also explain the “Initializing Portlet Container. Please wait...” entry. The very first time you deploy a portlet, the Pluto container is initialized to your user environment, specifically your user directory. Pluto will be in the directory “portletcontainer” under your user directory after the first deploy. If you ever erase your user directory and deploy a portlet, you'll see the above message again.

Friday Sep 16, 2005

Creator 2 EA Does Portlets!

For those of you who don't know, Creator 2 EA supports JSR-168 portlet development. The feature allows you to build JSF-based "JSR-168":http://jcp.org/en/jsr/detail?id=168 portlets. You can read more information about Early Access (EA) 1 support "here":http://developer.sun.com/prodtech/javatools/jscreator/ea/jsc2/reference/fi/portlets.html .

Some of you may ask why we've limited the feature to only produce JSF-based portlets. There are two main reasons for this choice. First, Creator's intent from the beginning was to be a visual, drag-and-drop development environment. Creator tries to isolate the developer from the mundane, commodity coding such as laying out components and hooking up user interface with actions. JSF is the perfect solution for this. Secondly, we've gone to great pains to make the development experience in Creator consistent. When you are developing portlets, the experience is intentionally meant to be as close as possible to developing a normal web application.

I'd like to share an important portlet-specific difference between EA 1 and EA 2. For EA 1, the feature only supported portlet \*VIEW\* mode. EA 2, however, supports portlet \*EDIT\* and \*HELP\* modes as well. The initial limitation was in the reference implementation JSF-Portlet adapter. That adapter has gone through lots of upgrades and fixes lately including EDIT/HELP mode support.

Creator bundles Pluto's portlet driver/container as a test environment for the portlets you create. We're currently using the RC2 version of Pluto. I'll blog more on some of the Pluto/Creator interactions later.

About

David Botterill

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today