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