cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist ...@wrinkledog.com>
Subject Re: How to embed Cform in larger web site layout
Date Wed, 01 Feb 2006 06:44:31 GMT
Hi Peter,

On Jan 28, 2006, at 2:03 AM, Peter.Neu@gmx.net wrote:

> I modeled a  cocoon form (based on the registration example in the 
> docs)
> which I would like to incoperate into a classic web site layout 
> (header,
> footer etc).

Right... we Do That All The Time™ :-)

> When I have done all the cform transformations the form is already in 
> html.

OK, as someone else has pointed out, your form is HTML in two distinct 
senses, (a) it is expressed in the HTML vocabulary, and (b) an HTML 
serialization has been created by the pipeline you show below:

>
> <map:generate type="jx" src="registration_template.xml"/>
>                 <map:transform type="browser-update"/>
>                 <map:transform type="i18n"/>
> <map:transform src="forms-samples-styling.xsl"/>
> <map:serialize type="html"/>

As for (a), you will realize that the reason you have an XML document 
that uses HTML markup is that this comes from your JXTG template 
("registration_template.xml"), and that if you don't want it to be HTML 
you can always write your template to generate some other kind of 
markup.  I am going to argue that you _do_ in fact want it to be HTML 
(in sense (a)), but the point is that nothing's forcing it to be that 
way.

As for (b), you just need to make sure that you wrap your "chrome" 
around the form before you invoke the serialization to HTML.  You do 
that with an XSLT that stylesheet converts the form template markup 
(HTML or whatever, see above and below!) into the final presentation 
HTML.
There are many ways to do this.  Most obviously, you could add another 
<transform> for that XSLT to the pipeline shown above.  Better yet, you 
could have a common <resource> that you would call at the end of the 
pipeline instead of serializing, and the resource comprises both the 
final transformation and the serialization, something like this (note, 
I write my sitemaps w/ a default namespace so that I don't have to 
write the 'map:' prefix all over the place):

	<resource name="to-html">
		<transform src="xslt/site/page.xslt" />	<!-- sitewide layout/styling 
-->
		<serialize type="html"/>
	</resource>

and then instead of calling the serializer at the end of your forms 
pipeline, you say

	<call resource="to-html"/>

... which you also call from other pipelines that serve your other 
content.

> So it does already contain the <body> and <head> tags. Now I would 
> like to
> include the cform in a larger HTML document. But the problem is the 
> cform is
> already html so would have to write an XSLT Transformation which 
> transforms
> the HTML to another HTML document. This is clearly not a clean 
> solution.

On the contrary, it's a very clean solution (remember we are talking 
about transforming HTML markup to HTML markup, not serialized HTML 
to... whatever).  You could invent your own little document language in 
XML, but why bother?  That's what HTML is for, and you already know 
HTML.  My sites typically have content that is written/generated in 
HTML that looks pretty much just like this:

	<html>
		<head>
			<title>A Fine Page This Is</title>
		</head>
		<body>
			Content, wonderful content.
		</body>
	</html>

and my site/page.xslt template turns that into something like this:

	<html>
		<head>
			{...<link> for stylesheets,  <meta> elements and all that crap, 
maybe some JS crap...}
			<title>FooBarCo, Inc. ::: A Fine Page This Is</title>
		</head>
		<body>
			{all kinds of layout/styling crap, masthead graphics, nav menus & 
whatever other "chrome" there may be}
			<div id="main-content>
				Content, wonderful content.
			</div>
			{more chrome, e.g. a "footer" or whatever}
		</body>
	</html>

So, you just write your form template to emit the same sort of simple, 
cut-down HTML as in the content example above, and then run it through 
the common styling template to get the chrome wrapped around it.

Finally, I recommend not talking and thinking in terms of HTML 
"fragments" :-).  Working with "fragments" is not a fundamental web 
programming task.  It's a specific idiom that is served by certain 
frameworks/languages.  When you are working with XSLT, the key thought 
is not "fragment" or "include", but "template".

HTH,
—ml—

Mime
View raw message