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
>
Sorry to jump late on this, but I'm -1 for this as this is Jetspeed is
already architected to be able to handle this (although the implementation
is incomplete right now).
Defintions:
* client: a client is a software used to access the portal content. A client
is identified by a user-agent string and supports one or several content type
as well as one or several capabilities.
* content type: a content type defines how to parse/decode a content as indicated
in the HTTP Content-type MIME header. (ex: text/html for HTML, etc...)
These content types are normalized by the IANA.
* capability: a capability is an optional feature that may or may not be implemented
by a client capabale of handling a specific content-type (ex: HTML Tables,
javascript, CSS, etc...). Capabilities are not normalized and may be freely
defined by developpers/users.
Based on these definitions, a client is identified by Jetspeed by its user-agent
and is tied to the content-type and capabilities it supports.
These definitions are currently more or less hard-coded in the
org.apache.jetspeed.capability package but there a more flexible implementation
in the portlet_api branch that can probably be re-integrated pretty easily into
the main CVS.
Additionnally, Jetspeed has a Registry for media types.
A media type is defined by a content type associated with a set of capabilities
[Implementation note, currently the media-type implementation does not define
these capabilities]
Example of media types:
html = text/html HTML4,CSS,Javascript
html-lite = text/html HTML3.2,no nested table
chtml = text/html, HTML2
...
In the Portlet registry, each portlet is declared to support one or several
media types.
In the template path:
templates/vm/layouts/html/en/default.vm
"html" is actually a media type name and *not* a content-type abbreviation, thus
you could have using the above example:
templates/vm/layouts/html/en/default.vm
templates/vm/layouts/html-lite/en/default.vm
templates/vm/layouts/chtml/en/default.vm
to differentiate between different capability sets for a given content type.
When handling a client request, the engine looks up the client user-agent
and determines the best media type to serve to this client based on its
supported mime-type and capabilities.
It then uses the computed media-type to locate the appropriate template.
There are several advantages of this architecture over your proposal:
- the client capability handling is encapsulated and can be actually reused
in many projects (ie it's a good candidate for jakarta-commons)
- you decorrelate your templates from actual client names, thus you can scale
independantly your number of supported client and the number of supported
features.
- your directory structure is stable:
imagine that in your example above you used CSS1/nested table in your "default"
html template but that next year to support new mainstream HTML browsers you
want to use CSS2 features in your default template that are not supported by IE5.
What are you going to do ?
- change the default HTML to use CSS2 and create new "ie5" sub-directories
through-out your directory structure to keep to CSS1 only version for ie5
- or keep your default default as is in CSS1 and create an "ie7" sub-directories
through-out your template structure to cater for the new browsers
both cases may break your current production site because of a change of
semantic in your implied "default" HTML template.
In the media type scenario, you just need to define a new media type with
additionnal capabilities requirements and deploy your new templates without
at all impacting your current prod environment...
If you're willing to help complete the current implementation to actually make
the media type scenario work, I can give you additional pointers on what is
required to complete the implementation.
--
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]>
