"This XSLT only has to handle individual widgets, and not the page as a whole, and is thus not specific for one form but can be reused across forms." Well yes, but then the template was form-specific in the first place, and arguably it was more laborious to have to call out each widget than it would be to match them in using <xsl:apply-templates>, isn't it?
I am building my own widget stylesheet. I include it in my page stylesheets. The templates match using apply-templates. You do not need to call them explicitly.
I make a lot of use of the mode attribute to template and apply-tempaltes. Have you started playing around with this? Using include and the mode attribute I'm getting some pretty impressive resuse and modularization in my stylesheets.
After the refactoring this is also the way now the Woody widget and page styling stylesheets in Cocoon go. You can easily extend them. If you have still more suggestions on this issue, I will be happy to here from you.
http://wiki.cocoondev.org/Wiki.jsp?page=WoodyTemplateTransformer has this to say: "If you prefer to do everything with XSLT, you have also the option of using the WoodyGenerator. In general we recommend to use the woody transformer though." Why is the transformer approach recommended over the generator approach? I don't get it.
When using the WoodyTransformer you separate the widget and page styling from the page structure. The latter one is the form template and provides the structure of the form.
When using the WoodyGenerator you don't have this separation. You only have a form representation at the beginning of the pipeline, but you must bring structure into it, i.e. you need a form specific template that transforms the pure form description into form description + layout. Now you can use the woody styling stylesheets again.
So on the hand you have WoodyGenerator (form description) + a transormer (structure), on the other hand a form template (structure) + WoodyTransformer (form description). Nothing really to be prefered over the other I guess. The second approach might be more flexible as the form template can be either static (file generator) or dynamic (jx template) or what ever.
Nor do I. Documentation for WoodyGenerator is thin. It looks to me
like a WoodyGenerator is a way to stream an object of type
org.apache.cocoon.woody.formmodel.Form.
Yes, though I never tried it.
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
