cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan <alan-coc...@engrm.com>
Subject Re: WoodyTemplateTransformer vs. WoodyGenerator
Date Tue, 10 Feb 2004 08:20:56 GMT
* 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


Mime
View raw message