Thanks for all the feedback, I figured you guys might have some better ideas.
Using the capability map seems to be the consensus. Let me introduce
myself to the idea of extending the capability map portion of the code and
chew on this for a day or so before I agree it's best (sure it is, just
want to understand that myself).
I tend to be more oriented towards thinking
media-type\client\language
than [media-type | client]\language
I'm still parsing Raphael's message, so forgive me it this was
addressed. I think he is saying [media-type & client]/language and that
makes sense, but how do you implement in directory structure?. I'm
guessing the directory structure ends up the same as my proposal but the
decision point is implemented in the capability map.
%regards -tk
At 08:56 AM 5/23/2002 -0400, Paul Spencer wrote:
>Todd,
>
>In many ways this should be handled by the capability map.
>
>***
>*** Default behavior of the capability map:
>***
>The capability map's need the ability to handle is a "default media type"
>for a media type. Using the directory structure below. A request from a
>Netscape 4.7 borrower, or a wap phone, for custom.psml would return
>..\custom.psml. I would contend the desired behavior would be a "default
>media type". In this example html would be searched if the file as not
>found in netscape4.7.
>
>..\html\default.psml
>..\html\custom.psml
>..\netscape4.7\default.psml
>..\opra\default.psml
>..\opra\custom.psml
>..\custom.psml
>
>Your proposal address this, by nature of the directory structure. I would
>prefer the capability may be enhanced.
>
>***
>*** Impact of changing the directory structure.
>***
>The current directory structure for PSML files is ingrained in the Profile
>Locator, and by extension JetspeedLink and the PSML database.
>I am sure their are other parts of Jetspeed that would be affected, these
>are the ones that come to mind.
>
>
>Although I agree with your intent and like the proposal, enhancing the
>existing capability map IMO is a better solution
>
>Paul Spencer
>
>
>Todd Kuebler wrote:
>
>>I propose we change the search path of the jetspeed template locator
>>service to include browser directories. The changes will be made to the
>>current JetspeedTemplateLocatorService.
>>The search path algorithm would be the same as now, with the addition of
>>the browser directory if there is at least one defined browser group (see
>>below) and the getRequest().getHeader("USER-AGENT") matches one of the
>>browser group strings (ie starts with).
>>The most important question is were do the browser specific directories
>>go in the heirarchy. The problem we are trying to solve is that
>>browsers display content differently and might need custom templates.
>>We also want to avoid duplication and keep the search speedy. This would
>>imply that the browser specific directory should be at the highest level
>>possible (earlier/nearer top of the tree) and that if there are no
>>browser groups defined that the search for browser directory will not be
>>included.
>>Here are some examples of what I propose:
>>case 1: All older browsers have a particular behavior, like no
>>javascript. The site is english but has localization enabled.
>>In JR.p:
>>services.TemplateLocator.browsergroup.sansjavascript="Netscape 4"
>>"Netscape 3" "Internet Exploder 1"
>>in WEB-INF/:
>>templates/vm/layouts/html/en/default.vm
>>templates/vm/layouts/html/sansjavascript/en/default.vm
>>
>>case 2: All netscape browsers have a particular bug. The site is
>>english and spanish.
>>In JR.p:
>>services.TemplateLocator.browsergroup.netscape47="Netscape/ 4.7"
>>"<spanish equiv if different>"
>>in WEB-INF:
>>templates/vm/layouts/html/en/default.vm
>>templates/vm/layouts/html/es/default.vm
>>templates/vm/layouts/html/netscape47/en/default.vm
>>templates/vm/layouts/html/netscape47/es/default.vm
>>
>>
>>-- To unsubscribe, e-mail:
>><mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail:
>><mailto:[EMAIL PROTECTED]>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
