El mar, 27-09-2005 a las 15:31 +0100, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mar, 27-09-2005 a las 11:39 +0100, Ross Gardler escribió:
>
> ...
>
> > Hmm, I do not see the complexity. ;-)
> > in voice.fv:
> > <forrest:contract name="voice-markup">
> > <forrest:properties contract="voice-markup">
> > <forrest:property name="voice-markup" nugget="get.body">
> > <url>#{$cocoon/parameters/getRequest}.mxml</url>
> > </forrest:property>
> > </forrest:properties>
> > </forrest:contract>
>
> No, this is not correct a request for *.mxml gives a complete HTML page,
> not just the section needed for head. Although it would be possible to
> change the stylesheets accordingly I do not think this is the right
> approach since it splits control of the content generation between the
> view and the plugin.
Hmm, I know what you mean:
<xsl:template match="document">
<html>
<head>
<xsl:apply-templates select="//header"/>
<xsl:apply-templates select="//body"/>
</head>
<body ev:event="load" ev:handler="#main">
</body>
</html>
</xsl:template>
...but changing
>
> > in voice-markup.ft
> > <xsl:template name="voice-markup-head">
> > <xsl:param name="voice-markup"/>
> > <xsl:copy-of select="$voice-markup"/>
> > </xsl:template>
> >
to:
<xsl:copy-of select="$voice-markup/html/head/*"/>
Would solve this problem very nicely without touching the voice plugins
xsl. The other problem which is actually bigger, is to pass the
@attributes of the body tag.
When I started the first implementation I decided to kindly ignore it
for the moment till I have a proof of concept. Now it is time to think
about it again. ;-) We need a trigger.
Not only here we need a trigger. We need to change the body="false"
head="true" on the <forrest:template/> as well to make it more flexible.
Ideas?
> > OR:
> > See the attached patch. It is basically the same only that the contract
> > is now doing exactly what the xsl before does.
>
> Yes, this is the approach we are after since we now only have one place
> (the contract) controlling the generation of the voiceML files. Thanks
> for finding the time to put this together Thorsten.
No problem, I would check it in but like I said it is not working yet,
it is based on jx and I did not want to open another construction site.
Seeing the patch solution I have to admit that the above contract seems
to be way cleaner because the voice plugin is the data model producer
and the contract is transforming it.
> > Either way the *real* problem that you have is that the last pipe in
> > views is stripping the namespaces which prevent that the content of the
> > voice markup is rendered correctly. I did not had time (and will not in
> > the near future) to fix the strip_namespaces.xsl to let the voice ns
> > through. Sorry. For your development comment it out and build views
> > again.
>
> Why do we strip namespaces? Is it safe to let the voiceML one through?
I cannot remember anymore exactly *why* but it had something to do with
validation of the xhtml output.
Could it be because of xhtml strict/traditional?
http://www.w3.org/TR/xhtml1/#well-formed
"The XHTML namespace may be used with other XML namespaces as per
[XMLNS], although such documents are not strictly conforming XHTML 1.0
documents as defined above."
There is an example for other markup within xhmtl but I guess that
adding namespaces in general make the validation test failing.
"XHTML plus Math 1.1 DTD", "A.2 MathML as a DTD Module", Mathematical
Markup Language (MathML) Version 2.0. Available at:
http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd
> If we need to strip some namespaces and not others we need a way of
> configuring the strip-namespaces.xsl from a plugin otherwise plugin
> developers will have to edit this XSL in core. Any sugestions how HANAX
> (or someone) can patch this namespace stripping in a more manageable way?
We could change it and explicitly strip internal namespaces like xi: or
forrest: and allow all other, but see above.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
