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 toYes it can.
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?
The Profiler interface already has createProfileLocator() method.
Just need to make it configurable via the properties file and load your locator
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 [EMAIL PROTECTED] +01 707 773-4646 +01 707 529 9194 +44 (0)79 8538 6471
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
