portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: Extending profile locator in Jetspeed 1
Date Wed, 19 Nov 2003 18:59:46 GMT

On Wednesday, November 19, 2003, at 06:16  AM, Sami Leino wrote:

> Hi.
> Our Intranet package (which is built on top of Jetspeed 1.4-b5) has a
> support for multiple organizations (and departments) at the portlet 
> level.
> However, the package doesn't offer full support for multiple 
> organizations
> at the aggregation level, so we are currently unable to add some 
> features
> that we'd like to have. One of them is organization-based PSML fallback
> mechanism.
> So I would like to ask you if there is an easy way to achieve it? The
> fallback order I would like to have is something like this:
> 1) Try to locate user's personal profile
> 2) Try to locate profile based on user's organization AND role
> 3) Try to locate profile based on user's role
> 4) Get the default profile
> I would like to point out that we don't have personal profiles for any
> user; every user has a profile based on his/her role. I will describe 
> the
> reasons for this later on.
> As you see, phase 2 is an addition to Jetspeed profile locator 
> mechanism.
> So we could use the organization information found from our customized
> user object to find the profile, but the problem is that the user is 
> not
> anymore present in the ProfileLocator object during this phase.
> Another alternative I considered is to override 
> CastorPSMLManagerService
> and make the following kind of "hack" to the subclass:
>     protected PSMLDocument getDocument(ProfileLocator locator, boolean
> getCached)
>     {
>         PSMLDocument doc = getDocumentPrivate(locator, getCached, 
> false);
>         if (doc == null && locator.getUser() != null)
>         {
>             doc = getDocumentPrivate(locator, getCached, true);
>         }
>         return doc;
>     }
>     private PSMLDocument getDocumentPrivate(ProfileLocator locator,
> boolean getCached, boolean useOrganization)
>     {
>        ...
>     }
> The hack works when reading the profile in, but saving profile fails,
> because Jetspeed thinks that the User has a personal profile.

> The correct way would be to extend the ProfileLocator implementation to
> contain information about the organization. However, I don't think that
> the ProfileLocator implementation can be configured, can it? 
> Additionally,
> ProfileLocator instance is manipulated in some many places that 
> modifying
> it would required us to change very many classes indeed? Am I correct?
Yes it can.
The Profiler interface already has createProfileLocator() method.
Just need to make it configurable via the properties file and load your 
I can make this change easily if you. I will do it today

As long as you extend the interface, everything will work as is

> ProfileLocator contains support for Groups. We could use Group to
> represent organization, but since Jetspeed uses Group for it's own
> purposes, this doesn't seem to be a good alternative either.

Jetspeed doesn't actually use Groups for its own purpose, it just 
always defaults the group to "Jetspeed".
I think you could use the Group as the organization.
I know that Santiago does this....

David Sean Taylor
Bluesunrise Software
+01 707 773-4646
+01 707 529 9194
+44 (0)79 8538 6471

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message