portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From raphael.l...@networks.groupvu.com
Subject Re: Proposal: Template Locator search path includes browser type
Date Thu, 23 May 2002 08:08:55 GMT
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).

* 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:


"html" is actually a media type name and *not* a content-type abbreviation, thus
you could have using the above example:


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
- 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 - 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