[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: how to support cHTML with WSRP and JSR168?
Hi all, as you might know unfortunatly the W3C cHTML specification has missed to register its own mime type and instead uses text/html as the mime type for cHTML. Efforts to try to register a specific mime type for cHTML failed for backwards compatibility reasons. The W3C recommendation is to use the userAgent string to distinguish which html to generate: plain HTML or cHTML. However, this brings us some problems for portlets: 1. How can portlets indicate that they support HTML and cHTML? 2. How can the Consumer explicitly request cHTML markup for its end-user? Assume the following use case: A portlet supports HTML with the modes view, help and edit AND cHTML with the modes view, preview, help. The question is what the PortletDescription contains for the text/html mime type for the supported modes. With the current WSRP & JSR168 specification we need to end-up with the superset of both modes arrays, i.e. the portlet description would contain one single text/html mime type with the modes view, help, edit, preview and help. This is quite unsatisfactory as the Consumer portal for example would render decorations which would allow edit mode even for cHTML only capable devices since it can't distinguish the HTML dialects. One possible solution to this problem would be to define an additional mime type parameter like "html-dialect=cHTML". This would mean that the PortletDescription would contain two MarkupType entries for the mime type text/html: "text/html" for plain html and "text/html; html-dialect=cHTML". In the same way the Consumer could explicitly request cHTML content by setting the mime type to "text/html; html-dialect=cHTML". The problem here is that we explicitly say in the WSRP spec that Consumers/Portlets do not need to handle any optional parameters for mime types. It seems to me that this is quite limiting. When we look at xHTML there are already optional parameters used to distinguish between various profiles. It seems natural to me that portlets supporting xhtml might have different sets of modes and window states depending on the profile. Also in future further mime types might come up which use parameters on mime types to distinguish between various subtypes/profiles/versions/dialects. So this comes down to two questions: 1. Should we expand the handling of mime types in such a way that additional parameters DO care? This would mean that "type/subtype; param1=value1" is being considered as a different MarkupType than "type/subtype; param2=value2". 2. Should we add a specific parameter for cHTML? I am aware of the fact that this is a "workaround" for the missing mime type. While cHTML generation based on the userAgent string might work well for plain web apps, this approach seems not to be well suited for the portal use case where the consuming portal could do better if the supported modes/window states for a certain MarkupType were known a priori. Did other portal vendors experience similar problems with cHTML support? And if not, how do you solve it? We could solve our use case by having our own extension for this, however this would require us to replicate the MarkupType structure for cHTML and add it as a PortletDescription extension which is not very convenient. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Standardization Technical Lead Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]