At 10:08 AM 5/23/2002 +0200, you wrote: >Todd Kuebler wrote: > >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.
I already like this better. >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] Sounds painful. ;) >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. Ok, I use directories, you use hyphens, same diff (except hyphens don't indicate as clearly a heirarchy). :) templates/vm/layouts/html/lite/en/default.vm >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. My weaker 'browser groups' idea attempted this. Good point. >- 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 Browser groups addressed this. Again, clearly not as good. >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. Sure, but it is obviously a bigger project than I had initially thought. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
