You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2005/11/02 17:56:51 UTC

IncludingHTMLSerializer

The portal requires that the IncludingHTMLSerializer be used to generate 
the content of any JSR-168 portlets.  This works fine for portlets which 
generate HTML. However, our sites are required to generate only XHTML.  
So I have a few questions.

1. HTMLSerializer sets the output format to HTML. I'm assuming that this 
is where the problem lies.  Would providing a way for 
IncludingHTMLSerializer to set the output format to XML be enough to 
solve the issue? 
2. Should I instead create an IncludingXMLTransformer?  It seems like it 
would share a lot of code with the IncludingHTMLSerializer.
3. Both of the above assume that the JSR-168 portlet is generating 
XHTML. If it generates HTML but the output must be XHTML what then?

Ralph

Re: IncludingHTMLSerializer

Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> The portal requires that the IncludingHTMLSerializer be used to generate 
> the content of any JSR-168 portlets.  This works fine for portlets which 
> generate HTML. However, our sites are required to generate only XHTML.  
> So I have a few questions.
> 
> 1. HTMLSerializer sets the output format to HTML. I'm assuming that this 
> is where the problem lies.  Would providing a way for 
> IncludingHTMLSerializer to set the output format to XML be enough to 
> solve the issue?
Hmm, might be - you can configure the includehtmlserializer like the
html serializer, and therefore set the format to xhtml I think.

> 2. Should I instead create an IncludingXMLTransformer?  It seems like it 
> would share a lot of code with the IncludingHTMLSerializer.
A transformer only works for xhtml (or xml). Now, a portlet can generate
any html including not well-formed.
> 3. Both of the above assume that the JSR-168 portlet is generating 
> XHTML. If it generates HTML but the output must be XHTML what then?
This is the reason for this IncludingHTMLSerializer. The content of the
portlet is not parsed, it is not converted into xhtml (or any other
format). The character stream comming from the portlet is included in
the output stream. So this works for all well-formed and not well-formed
 content.

After rereading your mail I think I get what you mean...ok, you can
convert the content of the portlet (if it's html) to XHTML using the
neko html parser. You could do this in a transformer, but the good think
about it is that the portlet adapter of 2.1.8 can do this already for
you. Set the "use-pipeline" configuration for the portlet adapter in the
configuration for the coplet base data to true:
   <configuration>
     	<name>use-pipeline</name>
 	<value xsi:type="java:java.lang.Boolean">true</value>
   </configuration>
And then the content of the portlet is parsed, convertet to xhtml and
streamed through the pipeline. You don't need the includehtmlserializer
anymore.

HTH
Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/