This is a little status update of what I'va done recently and I have pending for
commit.
Since some of these changes have wide impacts, I thought it was better to give a
little advance notice.
1- Factory clean up
-------------------
* I've cleaned up the org.apache.jetspeed.portlet.factory package and especially
the PortletFactory.
There are now 2 different public factories:
PortletFactory: creates a single portlet object from various data sets
PortletSetFactory: creates PortletSets from PSMl descriptions
And a few additional utility factories:
PortletConfigFactory
SkinFactory
LayoutFactory
MetaDataFactory
* I've fixed the naming convetions used in all the factories ( including
PortletControlFactory and PortletControllerFactory ):
XFactory always has a getX method for creating the X object type
XFactory may have a getInstance method if it's a singleton.
Thus the old
PortletFactory.getInstance().getPortlets()
is now
PortletSetFactory.getInstance().getPortletSet()
and the old
PortletControlFactory.getInstance()
is now
PortletControlFactory.getPortletControl()
I've already modified all the references to these methods in all the CVS code.
2- Profiler package
------------------
I introduced a new package org.apache.jetspeed.profiler and a new interface Profiler
for handling the user to resource URL mapping.
The DefaultProfiler just emulates the current mapping operation, ie
if you're autheticated as User <foo>, you get the PSML file
<psml base>/<foo>.psml
if you're not authenticated, you get as above, with <foo>=<default-user>
I also introducted a UserProfiler which acts as above except that it can use
a "user" request parameter for selecting the PSML file, ie
if you type http://localhost/servlet/jetspeed/user/foobar/
you get <psml base>/<foobar>.psml, whatever you're current authenticated user is.
The profiler to use by jetspeed is specified in the JetspeedResources.properties
you use, so you can write your own profiler to suite your mapping requirements.
I hope Neeme will like that... ;)
3- Controllers/Controls clean-up
--------------------------------
I've cleaned some controllers/controls implementations :
CardPortletController
XMLPortletController
PanedPortletControl
The PanedPortletControl can now display its tabs in different positions:
"north", ie same as currently
"south", under the content
"west" or "east", respectively left or right of the content
XMLPortletController now correctly queries portlet information, gets its
stylesheet for a "stylesheet" parameter in the PSML and use the following schema:
<psml:portletset width="" xmlns:psml="http://java.apache.org/xsd/PSML">
<psml:title>...</psml:title>
<psml:description>...</psml:description>
<psml:skin>
<psml:property name="">mypropvalue</psml:property>
</psml:skin>
<psml:portlet name="">
<psml:title>...</psml:title>
<psml:description>...</psml:description>
<psml:skin>
<psml:property name="">mypropvalue</psml:property>
</psml:skin>
<psml:layout position="">
<psml:property name="">mypropvalue</psml:property>
</psml:layout>
<psml:content>
<!-- generated portlet content -->
</psml:content>
</psml:portlet>
</psml:portletset>
I still include the portlet contents as is, so it needs to be XML compliant
(I've have a modified ECS jar available for outputting XHTML code).
4- Portlet state support
------------------------
I wanted to implement portlet state support but came to the conclusion that
it's not currently possible until we hav an ID available for referencing portlets.
The issue is:
If I put a minimize/maximize button in the portlet controlbar, I need to create
an URL that will change the state of *this* portlet so I must pass on the URL
an action parameter (Minimize, Maximize, etc...) and a portlet reference.
Currently the portlet reference passed is the protlet name but this not good
since the portlet name doesn't give enough information to retrieve the portlet
with its associated context (skin, etc...) as it's readily apparent from
the current maximize screen.
So we need quickly to implement an ID for portlets that can be used to quickly
reference and instanciate any portlet described in a user-PSML file.
This reference must be:
- simple to compute
- persistent across server reboot and registry changes and PSML file changes
- usable for locating uniquely a portlet description in a PSML file
Any ideas about such scheme implementation would be greatly appreciated.
5 - Currently working on
------------------------
Adding basic multi-access capability, see my response to kevin WAP proposal.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
