> -----Original Message-----
> From: Rapha�l Luta [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 14, 2000 11:11 AM
>
> 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
> -------------------
<snip what="a lot of +1 clean-up"/>
> 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... ;)
I sure do! ;-)
Also, I was thinking along the other meaning of the word "profile": we
need some sort of profiles with a set of pre-configured portlets. On one
hand, we need them for users, to the user can get some set of default
portlets (or he can choose a possible profile: student, business, etc.
that have most common use-cases covered) when he signs up. Also, we
would need portlet profiles for services (see my other post about the
services), so the user gets some preconfigured set of portlets and pages
when signing up for some service.
Actually, these user profiles could have two levels: one level defines
the default set of services that are activated for him when signing up
(kind of use-case for the whole portal: what does the user want to do on
the portal). And the other level is service specific: the service can
offer more than one preconfigured set of portlets, depending on service
level user profile selected (kind of use-case for the specific service:
how / for what does the user want to use this service).
> 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).
excellent! is it in the CVS already? Should check it out ASAP.
> 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.
yep. I see what you mean...
> 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.
Maybe adding auto-incrementing IDs to all portlets in a file?
> 5 - Currently working on
> ------------------------
>
> Adding basic multi-access capability, see my response to
> kevin WAP proposal.
Looks really nice, should checkout from CVS as soon as possible...
Neeme
--
--------------------------------------------------------------
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]
