You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mark Lundquist <ml...@wrinkledog.com> on 2004/02/05 08:18:53 UTC

WoodyTemplateTransformer vs. WoodyGenerator

OK, I am just learning Woody for the first time.  The wiki docs are 
most helpful.

Going through http://wiki.cocoondev.org/Wiki.jsp?page=WoodySample, I 
encountered the subject of Woody form templates.  The first thing I 
thought was that this approach seems kind of pull-y and not very 
Cocoon-like.  I have to enumerate each of the widgets individually in 
this template.  I thought "hmm, why isn't there XML for the form, for 
me to push through a stylesheet?"

Then I read in the WoodySample document: "As an alternative to the 
template approach, you could also use the WoodyGenerator, which will 
generate an XML representation of the whole form, and style that with a 
custom-written XLST."

Ah — just what I was looking for.

But then I read, "Using the Woody template transformer is much easier 
though."

Hmm, why would it be much easier?  It doesn't seem like it should be 
that much easier...

Then I ran across the WoodyIntro version 7 
(http://wiki.cocoondev.org/Wiki.jsp?page=WoodyIntro&version=7), which 
explains "The WoodyGenerator generates a complete XML representation of 
the form, which will then have to be styled by an XSLT. This XSLT will 
be specific for that form, but could import a library-XSLT that has 
templates for formatting individual widgets."

Well — doesn't the output of the template transformer need the same 
kind of styling, to translate elements in the 'wi' namespace to HTML?  
And would that not be done using woody-samples-styling.xsl?  And is 
that not the very "library-XLST etc." whereof it was spoken in the 
WoodyIntro v.7 doc?  In reference to the styling needed by the output 
of the template transformer, the WoodySample doc says: "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?

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.

Thanks for any illumination,
~ml


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: Problem with date format for a woody widget in xsp

Posted by Alex Kovacs <al...@fast.fujitsu.com.au>.
Hi Tony,

Thanks for the help, I will try it and let you know how it worked.

Rgds,
Alex

----- Original Message ----- 
From: "Tony Edwards" <te...@civica.com.au>
To: <us...@cocoon.apache.org>
Sent: Wednesday, February 11, 2004 9:42 AM
Subject: Re: Problem with date format for a woody widget in xsp


> Hi Alex,
> I had a similar problem saving data back to a MySql database. The 
> database only recognises dates in yyyy-MM-dd format and the flowscript 
> was outputting dates like so:
> EEE, d MMM yyyy HH:mm:ss Z (the same as your issue).
> I fiddled with the <wd:convertor> settings but it didn't change the 
> resulting format being sent to the database.
> To solve the problem I downloaded a date formatting javascript library 
> from Matt Kruse (WWW: http://www.mattkruse.com/) called date.js (funny 
> that).
> It was then just a simple call to a formatting method and the record was 
> written without complaint.
> Another more xsp-centric solution is to include the following code in 
> your xsp page:
> <xsp:page> 
>  <xsp:structure>
>         <xsp:include>java.util.Date</xsp:include>
>         <xsp:include>java.util.Calendar</xsp:include>
>         <xsp:include>java.lang.Integer</xsp:include>
>         <xsp:include>java.util.GregorianCalendar</xsp:include>
>         <xsp:include>java.text.SimpleDateFormat</xsp:include>
>         <xsp:include>java.lang.String</xsp:include>
>     </xsp:structure>
> 
>     <xsp:logic>
>         <![CDATA[
>             public static String formatDate(Date value, String format) {
>                 SimpleDateFormat formatter;
>                 format = format.trim();
>                 if (format != null && !"".equals(format)) {
>                     formatter = new SimpleDateFormat(format);
>                 }
>                 else {
>                     formatter = new SimpleDateFormat();
>                 }
>                
>                 return formatter.format(value);
>             }
>     </xsp:logic>
> <content>             
>                 <para>Select 'Add' or 'View' from the options then 
> select the month and year for the notice:</para>
>                 <para>Today's date is <xsp:expr>formatDate(new Date(), 
> "dd-MMM-yyyy")</xsp:expr></para><br/>
>  </content> 
> </xsp:page>          
> Hope this helps,
> Regards,
> Tony
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: Problem with date format for a woody widget in xsp

Posted by Tony Edwards <te...@civica.com.au>.
Hi Alex,
I had a similar problem saving data back to a MySql database. The 
database only recognises dates in yyyy-MM-dd format and the flowscript 
was outputting dates like so:
EEE, d MMM yyyy HH:mm:ss Z (the same as your issue).
I fiddled with the <wd:convertor> settings but it didn't change the 
resulting format being sent to the database.
To solve the problem I downloaded a date formatting javascript library 
from Matt Kruse (WWW: http://www.mattkruse.com/) called date.js (funny 
that).
It was then just a simple call to a formatting method and the record was 
written without complaint.
Another more xsp-centric solution is to include the following code in 
your xsp page:
<xsp:page> 
 <xsp:structure>
        <xsp:include>java.util.Date</xsp:include>
        <xsp:include>java.util.Calendar</xsp:include>
        <xsp:include>java.lang.Integer</xsp:include>
        <xsp:include>java.util.GregorianCalendar</xsp:include>
        <xsp:include>java.text.SimpleDateFormat</xsp:include>
        <xsp:include>java.lang.String</xsp:include>
    </xsp:structure>

    <xsp:logic>
        <![CDATA[
            public static String formatDate(Date value, String format) {
                SimpleDateFormat formatter;
                format = format.trim();
                if (format != null && !"".equals(format)) {
                    formatter = new SimpleDateFormat(format);
                }
                else {
                    formatter = new SimpleDateFormat();
                }
               
                return formatter.format(value);
            }
    </xsp:logic>
<content>             
                <para>Select 'Add' or 'View' from the options then 
select the month and year for the notice:</para>
                <para>Today's date is <xsp:expr>formatDate(new Date(), 
"dd-MMM-yyyy")</xsp:expr></para><br/>
 </content> 
</xsp:page>          
Hope this helps,
Regards,
Tony

Alex Kovacs wrote:

>Hi,
>
>I am using cocoon-2.1.3 with Woody. I have a situation where I am using
>xsp
>to display some data from a Woody form. The problem is when trying to
>display the value of a date widget and the date format is the default
>one
>instead of the one set in the widget definition. I have the following
>configuration (using xml binding):
>
>Widget definition:
>        ...
>        <wd:field id="start_date">
>            <wd:datatype base="date">
>                <wd:convertor type="formatting">
>                    <wd:patterns>
>                        <wd:pattern>dd/MM/yyyy</wd:pattern>
>                    </wd:patterns>
>                </wd:convertor>
>            </wd:datatype>
>            <wd:label>Start Date</wd:label>
>        </wd:field>
>        ...
>
>
>The confirm.xsp file:
>            ...
>            <xsp:logic>
>                //Fetching the form from the request attribute
>                Form form = (Form)request.getAttribute("theform");
>                Field start_date = (Field)form.getWidget("start_date");
>            </xsp:logic>
>            ...
>            <item>
>                   <xsp:expr>start_date.getValue()</xsp:expr>
>             </item>
>            ...
>
>And the output is in the form of: "Tue Feb 10 00:00:00 EST 2004",
>instead of
>"10/02/2004".
>
>Can anyone help?
>Rgds
>Alex
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: Problem with date format for a woody widget in xsp

Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-02-10 at 09:03, Alex Kovacs wrote:
> Hi,
> 
> I am using cocoon-2.1.3 with Woody. I have a situation where I am using xsp
> to display some data from a Woody form. The problem is when trying to
> display the value of a date widget and the date format is the default one
> instead of the one set in the widget definition. I have the following
> configuration (using xml binding):
> 
> Widget definition:
>         ...
>         <wd:field id="start_date">
>             <wd:datatype base="date">
>                 <wd:convertor type="formatting">
>                     <wd:patterns>
>                         <wd:pattern>dd/MM/yyyy</wd:pattern>
>                     </wd:patterns>
>                 </wd:convertor>
>             </wd:datatype>
>             <wd:label>Start Date</wd:label>
>         </wd:field>
>         ...
> 
> 
> The confirm.xsp file:
>             ...
>             <xsp:logic>
>                 //Fetching the form from the request attribute
>                 Form form = (Form)request.getAttribute("theform");
>                 Field start_date = (Field)form.getWidget("start_date");
>             </xsp:logic>
>             ...
>             <item>
>                    <xsp:expr>start_date.getValue()</xsp:expr>
>              </item>
>             ...
> 
> And the output is in the form of: "Tue Feb 10 00:00:00 EST 2004", instead of
> "10/02/2004".
> 
> Can anyone help?

The start_date.getValue() call returns a Date object, so the date you're
seeing it the default Date.toString() behaviour of Java.

Unfortunately, AFAIK, there's currently no method on the Field widget to
retrieve its converted string value (it's only part of the generated
XML). Seems useful to me though, and would only be 3 lines of code.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Problem with date format for a woody widget in xsp

Posted by Alex Kovacs <al...@fast.fujitsu.com.au>.
Hi,

I am using cocoon-2.1.3 with Woody. I have a situation where I am using xsp
to display some data from a Woody form. The problem is when trying to
display the value of a date widget and the date format is the default one
instead of the one set in the widget definition. I have the following
configuration (using xml binding):

Widget definition:
        ...
        <wd:field id="start_date">
            <wd:datatype base="date">
                <wd:convertor type="formatting">
                    <wd:patterns>
                        <wd:pattern>dd/MM/yyyy</wd:pattern>
                    </wd:patterns>
                </wd:convertor>
            </wd:datatype>
            <wd:label>Start Date</wd:label>
        </wd:field>
        ...


The confirm.xsp file:
            ...
            <xsp:logic>
                //Fetching the form from the request attribute
                Form form = (Form)request.getAttribute("theform");
                Field start_date = (Field)form.getWidget("start_date");
            </xsp:logic>
            ...
            <item>
                   <xsp:expr>start_date.getValue()</xsp:expr>
             </item>
            ...

And the output is in the form of: "Tue Feb 10 00:00:00 EST 2004", instead of
"10/02/2004".

Can anyone help?
Rgds
Alex



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Alan <al...@engrm.com>.
* Mark Lundquist <ml...@wrinkledog.com> [2004-02-10 04:22]:

> On Feb 9, 2004, at 6:39 PM, Alan wrote: 

> >     Does the WoodyGenerator go from Woody template to Woody 
> >     interface directly? 

> No, with the WoodyGenerator there is no Woody template. 

Okay, can someone point me to a pipeline or flowscript that invokes
    the WoodyGenerator?

    Google gave me this:

    http://www.apache.org/~jefft/forrest/samples/wikirenderer-site/wiki/WoodySample.html

    Is that it?

> > In XSLT it is much easier to transform structure than it is to 
> >     express structure. 

> No it's not easier!  It's all markup!  No difference at all. 

By this I mean that it is simpiler to start with a document that
    expresses the structure and content of the end product. I don't
    like to put verbiage in XSLT, for example. Once could place
    the labels for a form in XSLT, that would be markup, but to my
    mind it would be better placed in an XML file that stores the
    labels as a repository of labels, but still as markup.



> > > Nothing really to be prefered over the other I guess. 

> > Perhaps it is a matter of habit or taste. 

> I think it depends on the application.  If the form constitutes the 
> fundamental "content" of a page (or part of a page, such that it would 
> be natural to bring it in through aggregation),
                                    ^^^
                                    Oh!

I can see how a generator would be used in this case.



> But if you had a page with a lot of (static or dynamic) content,
> where it doesn't feel seem like that content is just "styling" for
> the form, then I would say the template approach probably feels
> right.

This is where I'm at. I find myself authoring forms that are in the
    context of their documentation. I'm not building applications
    that have a separate help system, applications where forms exist
    as the main attraction. (Not a preference or practice, just not
    what I'm up to this week.)



> But if all the content  is shared with other pages, then you're
> probably doing all that in an XSLT template anyway.

I just sorta steer clear of putting content in XSLT.

-- 
Alan / alan@engrm.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Feb 9, 2004, at 6:39 PM, Alan wrote:

>
>     Does the WoodyGenerator go from Woody template to Woody
>     interface directly?

No — with the WoodyGenerator, there is no Woody template.

>  It expands the template to include error
>     messages and the like.

No, see above :-)

>  Then you have to write a XSLT transform
>     to turn that very basic information into something suitable for
>     serialization.
>
>     This does sound much more complex that starting the pipeline
>     with an expression of the structure of the final document.

I don't think you have the idea yet of how the WoodyGenerator works!

> In
>     XSLT it is much easier to transform structure than it is to
>     express structure.

No it's not easier!  It's all markup!  No difference at all.

>
>> Nothing really to be prefered over the other I guess.
>
> Perhaps it is a matter of habit or taste.

I think it depends on the application.  If the form constitutes the 
fundamental "content" of a page (or part of a page, such that it would 
be natural to bring it in through aggregation), then the template 
approach is kind of a wash; it just means you have to mess with this 
template thing that doesn't do anything for you.  But if you had a page 
with a lot of (static or dynamic)  content, where it doesn't feel seem 
like that content is just "styling" for the form, then I would say the 
template approach probably feels right.  I'm sure you're at least 
partly right as far as it being a matter of taste... but I would 
suggest that one way to tell is to look at the other content on the 
page besides the form elements.  If that content is page-specific, then 
I'd say put it in the form template.  But if all the content  is shared 
with other pages, then you're probably doing all that in an XSLT 
template anyway.  If the form template devolves to just the <wt:...> 
elements themselves, then it's doing nothing for you and it would 
really be nicer to use the WoodyGenerator (if it worked with flow!...)

>
> Woody is a very impressive piece of work. Thank you for putting all
>     this effort into it.

Hear, hear! :-)

~ml


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Alan <al...@engrm.com>.
* Joerg Heinicke <jo...@gmx.de> [2004-02-10 02:14]:
> On 09.02.2004 18:49, Alan wrote:

> >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.

Well, I suppose I'll have to make an effort to reuse the existing
    Woody widges XSLT templates so I can offer suggestions. 


> >>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.

Page structure is provided by the form template. As a common example
    one might mix xhtml and Woody template elements to describe the
    layout of the widgets on a page. The WoodyTransformer injects
    the Woody interface elements that are then styled using an XSLT
    tranform into xhtml controls.

    Polly want a cracker.


> 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.

You must bring structure to it: via an XSLT transformation? Is that
    what is meant by "specific template"?
    
    Does the WoodyGenerator go from Woody template to Woody
    interface directly? It expands the template to include error
    messages and the like. Then you have to write a XSLT transform
    to turn that very basic information into something suitable for
    serialization.

    This does sound much more complex that starting the pipeline
    with an expression of the structure of the final document. In
    XSLT it is much easier to transform structure than it is to
    express structure.


> Nothing really to be prefered over the other I guess.

Perhaps it is a matter of habit or taste.
    
    I like the WoodyTransformer because I can start the pipeline by
    aggregating my frame layout and document content using schemas
    that describe site structure and document structure
    respectively. This is how most of my pipelines function
    (borrowing from the Cocoon documentation).

    In the documents I add Woody widgets, so it it aggregate
    document and frame, run the WoodyTransformer, then run through
    an XSLT transform that generates xhtml, then serialize.

Woody is a very impressive piece of work. Thank you for putting all
    this effort into it.

Sharing my experiences.

-- 
Alan / alan@engrm.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Feb 9, 2004, at 8:00 PM, Mark Lundquist wrote:

> ...so, being extrinsic, for structure is certainly "separated" from 
> the elaboration of widget instances which is the only intrinsic 
> aspect.
                                          ^^^
				that's supposed to be, "form structure"

ack :-)
~ml


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.02.2004 05:00, Mark Lundquist wrote:

>> When using the WoodyGenerator you don't have this separation.  You 
>> only have a form representation at the beginning of the pipeline,
> 
> 
> See, that's just what I don't get!  It sounds like you are saying, "With 
> one way, you the separation of these two aspects, and that is a Good 
> Thing... whereas, the other way it only gives you one of the two 
> things!"  Both of those statements are true, but it seems absurd to 
> connect them like that.  The generator approach has no intrinsic 
> representation of form structure — so, being extrinsic, for structure is 
> certainly "separated" from the elaboration of widget instances which is 
> the only intrinsic aspect.

Yes, I said that (at least I wanted to express this):

The generator puts the form representation without any structure into 
the pipeline, with a stylesheet you have to layout this form.

The transformer starts with a template (the structure) and adds the form 
representation into it (i.e. the woody widget instances).

> Just as it should be when using the transformer, 
> although it is notably not that way with the woody-field-styling.xsl in 
> the 2.1.3 release, which conflates form-independent HTML controls 
> generation with styling.
> 
> So, I don't see that the separation of, uh... things that ought to be 
> separated... :-)  is inherently any better or cleaner with the 
> transformer approach than with the generator approach.

This has been already much improved in the CVS and will be available in 
2.1.4. There you will also find the *5* stylesheets mentioned on the 
Wiki - which I had already updated.

> With the transformer, you need:
>     a) a form template, and
>     b) some stylesheets;
> 
> With the generator, you need:
>     a) the same stylesheets as with the transformer, and
>     b) either another stylesheet to express the structure that would be 
> expressed in the form template with the other approach, or you just fold 
> that into one of your existing stylesheets in (a) (obviously, not the 
> one that generates the HTML control elements, e.g. <input>, <select>, 
> <textarea>...).
> 
> To say it yet another way: one of the stylesheets you need with the 
> transformer approach is very likely project-specific or page-specific 
> enough to build the form structure into; then you don't need the wt 
> template.

Yes.

> In my application, there's nothing else for me to put into the wt 
> template other than just the wt elements themselves, so it doesn't do 
> anything for me.

To repeat me again: "Nothing really to be prefered over the other I 
guess." So it's just a "it depends" when choosing the transformer or 
generator approach. I guess most of the people are using the transformer 
as the samples are built on it and you have somewhat static. The 
creation process of a HTML form might be more obvious at the end with 
the transformer.

Joerg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Feb 9, 2004, at 6:14 PM, Joerg Heinicke wrote:

> 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.

That's what the docs say, but...

>
> When using the WoodyGenerator you don't have this separation.  You 
> only have a form representation at the beginning of the pipeline,

See, that's just what I don't get!  It sounds like you are saying, 
"With one way, you the separation of these two aspects, and that is a 
Good Thing... whereas, the other way it only gives you one of the two 
things!"  Both of those statements are true, but it seems absurd to 
connect them like that.  The generator approach has no intrinsic 
representation of form structure — so, being extrinsic, for structure 
is certainly "separated" from the elaboration of widget instances which 
is the only intrinsic aspect.

>  but you must bring structure into it,

I would say rather that you must bring that form representation into a 
structure...

> i.e. you need a form specific template that transforms the pure form 
> description into form description + layout.

Exactly... just as you do with the transformer.  With the transformer, 
the form-specific template is a document containing <wt:...> elements 
to be replaced.  With the generator, on the other hand, the 
form-specific template is an XSLT stylesheet.  The generation of HTML 
controls is of course not form-specific, and so it should be done in a 
separate stylesheet (although that could be imported/included by the 
form-specific stylesheet, or it could be a separate transformation 
stage in the pipeline).  Just as it should be when using the 
transformer, although it is notably not that way with the 
woody-field-styling.xsl in the 2.1.3 release, which conflates 
form-independent HTML controls generation with styling.

So, I don't see that the separation of, uh... things that ought to be 
separated... :-)  is inherently any better or cleaner with the 
transformer approach than with the generator approach.

With the transformer, you need:
	a) a form template, and
	b) some stylesheets;

With the generator, you need:
	a) the same stylesheets as with the transformer, and
	b) either another stylesheet to express the structure that would be 
expressed in the form template with the other approach, or you just 
fold that into one of your existing stylesheets in (a) (obviously, not 
the one that generates the HTML control elements, e.g. <input>, 
<select>, <textarea>...).

To say it yet another way: one of the stylesheets you need with the 
transformer approach is very likely project-specific or page-specific 
enough to build the form structure into; then you don't need the wt 
template.

In my application, there's nothing else for me to put into the wt 
template other than just the wt elements themselves, so it doesn't do 
anything for me.

Best regards,
Mark


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Joerg Heinicke <jo...@gmx.de>.
On 09.02.2004 18:49, Alan wrote:

>>"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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Feb 11, 2004, at 1:13 AM, Bruno Dumon wrote:

> On Tue, 2004-02-10 at 03:17, Mark Lundquist wrote:
>>
>> This is where I got stuck — I could create and display a form
>> usingflow and display it using the generator (and my stylesheet), but
>> thenfor flow you have to encode that continuation ID into the
>> <formaction="..."> somehow, and there's no way to do it!
>
> I don't have time to read this whole thread, but my eyes jus fell on
> this.
>
> You can provide the continuation ID to your XSL using a parameter in 
> the
> sitemap. There's an inputmodule with which you can get it (though it's
> only in CVS and still in scratchpad).

ah right... FlowContinuationModule... good.

>
> I don't think it's the role of the WoodyGenerator to supply you with 
> the
> continuation ID.

I agree.

> There have been updates to the WoodyGenerator, with latest CVS the
> lookup of the form works similary as with the template transformer
> (IIUC).

Very nice!

>  (won't help you for the case with the multiple forms on one page
> though).

Sure... understood.

>
> As far as the whole template vs generator debate is concerned, just use
> what fits your case best. If your forms are pretty generic and always
> follow the same layout, you're probably better of with the generator.

Yes, that's how it should be.

Thanks for the info!
~ml


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-02-10 at 03:17, Mark Lundquist wrote:
<snip/>
> 
> Then flow came along, and the WoodyTemplateTransformer was
> madeflow-friendly: first and foremost, it knows about the continuation
> ID! But the WoodyGenerator fell behind the curve, probably because it
> wasa second-class citizen already.  It is not flow-happy!  (Compare
> thesource for the generator and transformer to see).
> 
> This is where I got stuck — I could create and display a form
> usingflow and display it using the generator (and my stylesheet), but
> thenfor flow you have to encode that continuation ID into the
> <formaction="..."> somehow, and there's no way to do it!

I don't have time to read this whole thread, but my eyes jus fell on
this.

You can provide the continuation ID to your XSL using a parameter in the
sitemap. There's an inputmodule with which you can get it (though it's
only in CVS and still in scratchpad).

I don't think it's the role of the WoodyGenerator to supply you with the
continuation ID.

<snip/>
> With WoodyGenerator, you're kinda roughing it a little bit because
> itonly supports the (c) way, and it's undocumented how to do it
> fromflow (and arguably, that's OK for now, since WoodyGenerator can't
> makea form that you can handle with flow!).

There have been updates to the WoodyGenerator, with latest CVS the
lookup of the form works similary as with the template transformer
(IIUC). (won't help you for the case with the multiple forms on one page
though)

As far as the whole template vs generator debate is concerned, just use
what fits your case best. If your forms are pretty generic and always
follow the same layout, you're probably better of with the generator. 

The idea behind the templatetransformer is that in most cases this isn't
the case (i.e. you want to have full control over how you position
things), and that maintaining an XSLT is more work and requires more
expertise than the simple template file.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Mark Lundquist <ml...@wrinkledog.com>.
I was reading over this thread again, and...

On Feb 9, 2004, at 6:17 PM, I wrote:

> <..snip...> But to get an idea what it would be like if this worked, 
> try this:
>
> 1)
> 	<map:match pattern="hello-world-display-pipeline">
> 	  <map:generate type="woody" src="forms/view/hello-world.xml">
> 	    <map:parameter name="attribute-name" value="hello-form"
> 	  <map:serialize type="xml"/>
> 	</map:match>

My Bad!

Leave out the src="forms/view/hello-world.xml" from that 
<map:generate>.  There should be no src attribute.

> 2)  Then, add the super-secret ingredient in your flowscript, right 
> before the call to showForm():
>
> 	cocoon.request.setAttribute ('hello-form', form.form);
>
> Invoke your controller pipeline, and you'll get the XML from your view 
> pipeline.
>
> All the best,
> ~ml


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Alan <al...@engrm.com>.
* Mark Lundquist <ml...@wrinkledog.com> [2004-02-10 02:18]:
> Hi Alan, 
> 
> On Feb 9, 2004, at 9:49 AM, Alan wrote: 
> 
> 
> > * Mark Lundquist <ml...@wrinkledog.com> [2004-02-05 07:19]: 

> > I am going through the same experience. I am recording my 
> > impressions and discoveries in my web log: 

> > http://engrm.com/ 


> Thanks! 

> > We should chatter about our experiences on list. Our back and forth 
> >     might produce some documentation. 

> Good idea. 

Study partners.

> >  
> > My pipelines look like this: 
> > 
> > <map:match pattern="hello-world-display-pipeline"> 
> >   <map:generate src="forms/view/hello-world.xml"/> 
> >   <map:transform type="woody"/> 
> >   <map:transform type="xslt" 
> > src="stylesheets/application/web.xslt"> 
> >     <map:parameter name="base-link" value="."/> 
> >   </map:transform> 
> >   <map:serialize type="html"/> 
> > </map:match> 
> > 
> > I know nothing of a WoodyGenerator. 
> > 
> > 
> > > "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. 
> > 
>  
> Right... but by that time, you've already had to "declare" your widgets 
> twice, right?  It takes two pipelines to make a Woody form happen: a 
> "Controller pipeline", and a "View pipeline".  Your excerpt above shows 
> the "View pipeline".  But you also have another pipeline that invokes a 
> flowscript to (a) create the form instance, and (b) display it by 
> calling its showForm() method (with your "view pipeline" as a 
> parameter).  So then ??the Form constructor named a definition file, 
> full of elements from the "wd" namespace.  Compare that with your 
> "forms/view/hello-world.xml" ??that's the "form template", full of 
> stuff from the "wt" namespace. 

> In your case, maybe you have a form template that actually brings
> something to the table, but if you looked at my form definition
> file and my form template file side-by-side, you'd probably say,
> "wow man, that's... kinda redundant." 

Okay, I'm getting in gear with the lingo:

    * Form definition
    * Form template
    * Form interface

> It should be OK to use Woody forms without a template.  I can easily 
> envision applications where being able to plug into a template is a 
> nice convenience.  In my project, the template approach gets in the 
> way. 

> The woody stylesheets seem to be a little bit in limbo right now. 
> Wiki pages talk about them as though they already were what they want 
> to be: first-class, reusable generic templates for generating HTML 
> controls from Woody widgets.  It seems like maybe the Wiki is ahead of 
> the game here ? see http://wiki.cocoondev.org/Wiki.jsp?page=WoodyXSLT, 

You are pretty good with that Wiki...

> I think you have the right idea, making your own widget stylesheet.  
> The sample woody-field-styling.xsl IMHO doesn't provide for very good 
> separation of concerns...

I'm probably going to adopt what ever is going on in the source tree
    for Woody XSLT hack on it. I've been mucking around with web
    development for eight years now. I know Javascript and HTML
    forms well. This is a place where I might be of some assistance.

    It is difficult to get reuse out of composite controls since
    there are so many ways to implement things like tabs, repeaters,
    combo boxes, and none of them make for self-contained components.
    Most attempts I've seen to wrap up cross-browers fancy pants
    controls fall flat. I usually find myself rolling my own.

    Woody, however, has been such a peach so far I woundn't be
    surprised if I was surprised.

> > 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. 

> I have played with moded templates a little bit, but it's not obvious 
> to me how you're using them for form styling, so I'd be really 
> interested if to see some more details about what you're doing that 
> way!   

Okay. I'll add views to my sitemap so you can look at the raw XSLT
    and XML. End-of-week at the latest.

> (I use modes to control multiple phases of processing within a single 
> stylesheet, with the node-set() XSLT extension function). 

I used them to get different things out of a document. If I have an
    person element such:

    <person>
      <first-name>John</first-name>
      <last-name>Doe</last-name>
    </person>
    
    I will create a template like:

    <xsl:template match="person" mode="full-name">
      <xsl:value-of select="first-name"/>
      <xsl:text> </xsl:text>
      <xsl:value-of select="last-name"/>
    </xsl:template>

    <xsl:template match="person" mode="last-name-first">
      <xsl:value-of select="last-name"/>
      <xsl:text>, </xsl:text>
      <xsl:value-of select="first-name"/>
    </xsl:template>

In my current application (my site) I have a template called
    frame.xslt with a template such:

    <xsl:template match="lyt:content">
      <div class="content">
        <xsl:apply-templates select="node()" mode="content"/>
      </div>
    </xsl:template>

    I can then include frame.xslt in other XSLT transforms that will
    kick in when the frame.xslt templates call the content mode. 

    <xsl:template match="doc:document" mode="content">
      <xsl:apply-templates select="doc:body"/>
    </xsl:template>

    There is a clear point for the hand off.

    I'm taking to assigning modes to my templates as a statement of
    intent, looking at unmoded templates with the some distain.

> > > 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. 
> > > 
> >  
> > Nor do I. Documentation for WoodyGenerator is thin. 
> > 
>  
> Right.  It's kind of like it's a secret or something. 
> 
> Here's what it looks like happened... 
> 
> I'm guessing that the WoodyGenerator came first...

> ... the template generator approach seemed so wonderful and obviously 
> better, that it seemed to someone like it really pretty much superseded 
> the generator approach, and they figured (I'm just guessing here), that 
> occasions to use the generator approach would be few and far-between, 
> or maybe a matter of quirky individual taste, so this bias got written 
> in to the documentation. 

That's the way it goes all right.

    Of course, the bias was almost certianly dictated by the limited
    time and resources of the hard working Cocooners. It might not
    be that the generator was superceed so much as the transformer
    was newer so it was being build with the latest ideas. The
    documentation simply reflects the latest ideas and where they
    can be found. (In short, I'm sure neither of us is complaining, per se.)

> Then flow came along, and the WoodyTemplateTransformer was made 
> flow-friendly: first and foremost, it knows about the continuation ID!  

> Then I Googled up this post from Marc Portier at Outerthought, one of 
> the Woody developers... check it out: 

> http://archives.real-time.com/pipermail/cocoon-devel/2003-December/025453.html 
Looks like a project for you Mark! ;^)

> >sigh<

Did you think about creating an XSLT transform that generates your Woody
    template from your Woody definition?

> >  It looks to me like a WoodyGenerator is a way to stream an
> >     object of type org.apache.cocoon.woody.formmodel.Form. How
> >     you get your hands on one of those in your pipeline is a
> >     mystery to me. 
>  
> Well, you have to do the same thing when you use the transformer, so I 
> guess it's so mysterious that you don't even realize it's there! :-)  
> Check it out, so you have this flowscript, right, and it says something 
> like this for your example: 

I've a much better idea of what the WoodyGenerator is now. I can see
    how you want to use it in your application, an application where
    a form is a core concept. In application a page is a core
    concept, and woody template entires are just more neat stuff to
    put in a page.

I'm wondering how you are handling the display for forms once
    compelete.
    
    This is where I would like to have the form content as part of
    an aggregate document. Perhaps I can use WoodyGenerator.  Then
    Woody template declarations become redundant for me as well.

    I'm wondering if JXTemplates are first class citizens in the
    Republic of Cocoon?

-- 
Alan / alan@engrm.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Mark Lundquist <ml...@wrinkledog.com>.
Hi Alan,

On Feb 9, 2004, at 9:49 AM, Alan wrote:

> * Mark Lundquist <ml...@wrinkledog.com> [2004-02-05 07:19]:
>
>> OK, I am just learning Woody for the first time.  The wiki docs are
>> most helpful.
>
> I am going through the same experience. I am recording my
> impressions and discoveries in my web log:
>
> http://engrm.com/

Thanks!

>
> We should chatter about our experiences on list. Our back and forth
>     might produce some documentation.

Good idea.

>
> My pipelines look like this:
>
> <map:match pattern="hello-world-display-pipeline">
>   <map:generate src="forms/view/hello-world.xml"/>
>   <map:transform type="woody"/>
>   <map:transform type="xslt" src="stylesheets/application/web.xslt">
>     <map:parameter name="base-link" value="."/>
>   </map:transform>
>   <map:serialize type="html"/>
> </map:match>
>
> I know nothing of a WoodyGenerator.
>
>> "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.

Right... but by that time, you've already had to "declare" your widgets  
twice, right?  It takes two pipelines to make a Woody form happen: a  
"Controller pipeline", and a "View pipeline".  Your excerpt above shows  
the "View pipeline".  But you also have another pipeline that invokes a  
flowscript to (a) create the form instance, and (b) display it by  
calling its showForm() method (with your "view pipeline" as a  
parameter).  So then — the Form constructor named a definition file,  
full of elements from the "wd" namespace.  Compare that with your  
"forms/view/hello-world.xml" — that's the "form template", full of  
stuff from the "wt" namespace.  In your case, maybe you have a form  
template that actually brings something to the table, but if you looked  
at my form definition file and my form template file side-by-side,  
you'd probably say, "wow man, that's... kinda redundant."

It should be OK to use Woody forms without a template.  I can easily  
envision applications where being able to plug into a template is a  
nice convenience.  In my project, the template approach gets in the  
way.

The woody stylesheets seem to be a little bit in limbo right now.  The  
Wiki pages talk about them as though they already were what they want  
to be: first-class, reusable generic templates for generating HTML  
controls from Woody widgets.  It seems like maybe the Wiki is ahead of  
the game here — see http://wiki.cocoondev.org/Wiki.jsp?page=WoodyXSLT,  
where what is described is similar to what's in the 2.1.3 distro, but  
not quite (I just see the first three of the five stylesheets  
mentioned, with the calendar stuff included in  
woody-field-styling.xsl).  Arguably, if these are to be "standard"  
parts of Cocoon Forms, they don't belong in the "samples" directory.  I  
guess we'll see when 2.1.4 comes out.

I think you have the right idea, making your own widget stylesheet.   
The sample woody-field-styling.xsl IMHO doesn't provide for very good  
separation of concerns, because it tries to lay out the whole form and  
style the labels and everything.  I took woody-field-styling.xsl, and  
ripped out all that stuff, so that I ended up with templates that just  
generate the HTML controls — that's it.  So this stylesheet is 100%  
reusable.  The parts that are specific to the look-and-feel of my  
project — the form layout, label styling, dealing with validation  
messages — are done with separate stylesheets.

> 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.

I have played with moded templates a little bit, but it's not obvious  
to me how you're using them for form styling, so I'd be really  
interested if to see some more details about what you're doing that  
way!

(I use modes to control multiple phases of processing within a single  
stylesheet, with the node-set() XSLT extension function).

>
>> 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.
>
> Nor do I. Documentation for WoodyGenerator is thin.

Right.  It's kind of like it's a secret or something.

Here's what it looks like happened...

I'm guessing that the WoodyGenerator came first.  At that time, the  
controller aspects of woody were implemented using actions (and you can  
still see how that's done in some of the Woody samples).  Somebody  
developed the WoodyTemplateTransformer because this "pull-model"  
template approach was going to make their life easier.  I think maybe  
it's more natural when you have plenty of static content.  Then it  
would make sense to think of that as the "bottommost" layer of content,  
and it might feel wrong to start with the form and then write the  
static content into the XSLT stylesheets to build it up around the  
form... because if that's really the "content", then you want to think  
of it as the "source document", not the "styling"!  So you want to  
start with the fixed content, and then interpolate or "plug in" the  
form elements to that, which is what the template transformer approach  
is all about.  But in my application its more natural to think of the  
form itself as the most primitive content on the page, and everything  
else really is built up around that in the stylesheets.  But anyway,  
the template generator approach seemed so wonderful and obviously  
better, that it seemed to someone like it really pretty much superseded  
the generator approach, and they figured (I'm just guessing here), that  
occasions to use the generator approach would be few and far-between,  
or maybe a matter of quirky individual taste, so this bias got written  
in to the documentation.

Then flow came along, and the WoodyTemplateTransformer was made  
flow-friendly: first and foremost, it knows about the continuation ID!   
But the WoodyGenerator fell behind the curve, probably because it was a  
second-class citizen already.  It is not flow-happy!  (Compare the  
source for the generator and transformer to see).

This is where I got stuck — I could create and display a form using  
flow and display it using the generator (and my stylesheet), but then  
for flow you have to encode that continuation ID into the <form  
action="..."> somehow, and there's no way to do it!

Then I Googled up this post from Marc Portier at Outerthought, one of  
the Woody developers... check it out:  
http://archives.real-time.com/pipermail/cocoon-devel/2003-December/ 
025453.html

So anyway... I'm back to using the WoodyTemplateTransformer for now.   
 >sigh<.

>  It looks to me
>     like a WoodyGenerator is a way to stream an object of type
>     org.apache.cocoon.woody.formmodel.Form. How you get your hands
>     on one of those in your pipeline is a mystery to me.

Well, you have to do the same thing when you use the transformer, so I  
guess it's so mysterious that you don't even realize it's there! :-)   
Check it out, so you have this flowscript, right, and it says something  
like this for your example:

	form = new Form ("hello-world.wd");		// whatever
	form.showForm ("hello-world-display-pipeline");

Then the hello-world-display-pipeline takes that form, and... hey, wait  
a minute, how did you get that form "into your pipeline"?  The source  
stream for this pipeline is not the form, it's the form template  
(forms/view/hello-world.xml).  You transform that with the  
WoodyTemplateTransformer like this:

	<map:transform type="woody"/>

and that transformer "plugs in" the widgets into your template... but  
where does it get the widgets to plug in?  It''s magic!  The  
transformer gets the form instance from the request attribute context,  
either (a) by default from the key "woody-form", attached to the  
bizdata object passed in to showForm() in the flow; (b) as given by a  
JXPath expression in the <wt:form-template location="..."> attribute,  
or (c) from a request attribute named in:
	<map:transform type="woody" attribute-name="...">
...and if it's (c), then you have to do something in your flow (see  
below) to set it up first...

With WoodyGenerator, you're kinda roughing it a little bit because it  
only supports the (c) way, and it's undocumented how to do it from flow  
(and arguably, that's OK for now, since WoodyGenerator can't make a  
form that you can handle with flow!).  But to get an idea what it would  
be like if this worked, try this:

1)
	<map:match pattern="hello-world-display-pipeline">
	  <map:generate type="woody" src="forms/view/hello-world.xml">
	    <map:parameter name="attribute-name" value="hello-form"
	  <map:serialize type="xml"/>
	</map:match>

2)  Then, add the super-secret ingredient in your flowscript, right  
before the call to showForm():

	cocoon.request.setAttribute ('hello-form', form.form);

Invoke your controller pipeline, and you'll get the XML from your view  
pipeline.

All the best,
~ml

Re: WoodyTemplateTransformer vs. WoodyGenerator

Posted by Alan <al...@engrm.com>.
* Mark Lundquist <ml...@wrinkledog.com> [2004-02-05 07:19]:

> OK, I am just learning Woody for the first time.  The wiki docs are 
> most helpful.

I am going through the same experience. I am recording my
impressions and discoveries in my web log:

http://engrm.com/

We should chatter about our experiences on list. Our back and forth
    might produce some documentation.

    There is plenty of documentation on Cocoon, but I'm finding that
    there are a lot of dead ends as well. In fact, my most recent
    entry discusses this.
    
> "As an alternative to the template approach, you could also use
> the WoodyGenerator, which will generate an XML representation of
> the whole form, and style that with a custom-written XLST."

> Ah just what I was looking for.
> 
> But then I read, "Using the Woody template transformer is much easier 
> though."

> Hmm, why would it be much easier?  It doesn't seem like it should be 
> that much easier...

My pipelines look like this:

<map:match pattern="hello-world-display-pipeline">
  <map:generate src="forms/view/hello-world.xml"/>
  <map:transform type="woody"/>
  <map:transform type="xslt" src="stylesheets/application/web.xslt">
    <map:parameter name="base-link" value="."/>
  </map:transform>
  <map:serialize type="html"/>
</map:match>

I know nothing of a WoodyGenerator.

> "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.

> 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.

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. How you get your hands
    on one of those in your pipeline is a mystery to me.

    The above pipeline works very well for me.

-- 
Alan / alan@engrm.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org