portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaƫl Luta <raphael.l...@networks.groupvu.com>
Subject Re: Proposal: Template Locator search path includes browser type
Date Thu, 30 May 2002 16:22:28 GMT
Todd Kuebler wrote:
> Ok, finally had a chance to dig around in the Capability Map stuff in 
> both jetspeed and the portal API areas.
> I definately agree that the capability map direction is the one to go to 
> add the features contained in my proposal.
> I have a few questions:
> 1) If I read the code right, no changes to either the Template or 
> Profile Locators would be necessary if the directory structure continues 
> to include media-type with no additional directories added to the 
> heirarchy for browser.  Am I missing anything?  It looks like if the 
> media-type is defined correctly based on user-agent -> media-type 
> mapping it would just work.

I think for the convenience of portal developers and site maintainers you'll
need to implement a more sophisticated media-type matching capability that the
current "only match if strictly equal" policy.
Why ? Because if you want to differentiate between very close media-types to adjust
for some client bugs (ie the Netscape table implementation bug), you'll probably
want to use a single PSML resource but different template resources.

You can achieve that if your media matching algorithm returns an ordered list of
suitable media-types so that you can have fallbacks in your PSML resource search or
your template resource search...

> 2) Shouldn't the capability map be in the registry as a separate entity 
> instead of a properties file or hardcoded?  Or should those capability 
> definitions be hardcoded/properties as Ralpael's previous message and 
> the Portal API imply?  I can imagine needing to define additional 
> capabilities, so that would point to the former.

Correct, there's already an updated implementation available, see below.

> 3) It looks like the current media-type registry is simply tied to 
> content-type.  This might imply that there needs to be a content-type 
> registry, a capability registry, and the media-type registry would just 
> tie these together.

I'm not sure we really need a content-type & capability registry as
independant entities but media-type definitely needs to be expanded to
include content & capability.
Why would you introduce a content-type registry or a capability registry ?

> 4) What if a particular user wants to set her add or reduce her 
> capability to something other than what her user agent maps to?  Should 
> this ability be included in the proposal?

She would use an explicit 'media-type' parameter in the jetspeed URL.
This explicit parameter should take preference on the computed default
media-type for the user-agent.

> So the basic approach to implementation seems to be (contingent on the 
> answers to the questions above):
> 1) Move the Capability Map into registry.

This has already been implemented by Stephan Hesmer in the 'portlet_api'
branch. I've retrieved this code and ported it to the current CVS head for
your convenience :)
I expect to commit it over the week-end or on Monday.

> 2) Add a content-type registry

I think this is really optional

> 3) Change the media-type entries to define a collection if 
> content-type(1)/user-agent(*)/capability(*) instead.

Yes this needs to be done. I may help here.

> 4) Get the media-type set correctly in the rundata on login based on the 
> user agent.


> 5) Test to verify that this maps correctly in psml,  jslink and template 
> realms.


> I would be more than happy to do this work and submit the patches for 
> your approval, just want to make sure I'm going down the right path.   
> I'll submit a more detailed, modified proposal once I have some of these 
> questions more solidified.

Raphael Luta - raphael.luta@networks.groupvu.com
Professional Services Manager
Vivendi Universal Networks - Paris

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

View raw message