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. +1 > 5) Test to verify that this maps correctly in psml, jslink and template > realms. > +1 > > 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 - [EMAIL PROTECTED] Professional Services Manager Vivendi Universal Networks - Paris -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
