cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <>
Subject Re: AJAX + FormsGenerator
Date Thu, 15 Sep 2005 14:30:20 GMT
Sylvain Wallez wrote:

>>Since i'm using xsl2 for all my forms, i'm looking for a way to enable
>>ajax in FormsGenerator.
> Interesting. Can you explain how you use XSLT 2 and the FormGenerator?

Of course. For now it's not exactly compatible with the template language.
The main difference concern repeaters. I declare my templates enclosed in a
variable 'template' like this:

<xsl:include href="stylesheets/forms/forms.xsl"/>

<xsl:variable name="template">
  <ft:form-template action="{$continuation}.continue" method="post"
    <ft:widget id="maintab_state">
      <fi:styling type="hidden"/>
    <ft:repeater-size id="myrepeater"/>

    <!--<ft:repeater-widget id="myrepeater">-->
    <xsl:for-each select="ft:repeater-rows('myrepeater')">
      <xsl:variable name="row" select="ft:row-prefix('myrepeater',
      <ft:widget id="{$row}roomarea">
        <fi:styling size="2"/>

As you see it's not as clean as jx syntax, but writing a metastylesheet to
transform <ft:repeater> in an xsl loop and prefix all widgets id seems
quite simple (still efficient with cache and precompilation).

widgets are indexed on their id attribute to speedup lookups. forms.xsl is
pretty simple :

    <xsl:param name="continuation"/>
    <xsl:key name="widgets" match="fi:*" use="string(@id)"/>
    <xsl:variable name="widgets"
    <!-- -->
    <xsl:template match="/">
        <xsl:apply-templates select="$template/page"/>
    <!-- -->
    <xsl:function name="ft:repeater-rows" as="node()*">
        <xsl:param name="id"/>
        <xsl:sequence select="ft:widget($id)/fi:repeater-row"/>
    <!-- -->
    <xsl:template match="ft:widget">
        <xsl:variable name="widget" select="ft:widget(@id)"/>
        <xsl:element name="{name($widget)}">
            <xsl:sequence select="$widget/@* | $widget/*"/>

Things look suboptimal (use of variables, 2x evaluation of $template), but
for my case (lot of xpath processing in big templates) it's still faster
than jx (with saxon8). However this is temporary stuff. I found a way to
remove the

<xsl:apply-templates select="$template/page"/> 

and replace the

<xsl:variable name="template">

by a

<xsl:template match="/">

and make lookups of widgets directly on input (get rid of this 'widgets'
variable), but it means to replace all


with something like

<xsl:sequence select="ft:..()"/>

which is less readable (style will be handled via attribute-sets given as
parameters to ft functions in that case). Just need some time to implement.

What was important from now was speed and stability. Readability will come
with meta-stylesheet and i think that the syntax will finally be very close
from jx macros.

> I guess you're referring to the FIXME in
> AbstractWidget.generateSaxFragment.


>>Will the generator generate the bu tags, or will it generate the tags for
>>updated widgets only (without bu) ?
> If Widget.generateSaxFragment() was producing the bu:replace elements,
> then that would mostly translate to piping the result of the
> FormsGenerator through the BUTransformer.
> Unfortunately, this is not what happens and it should not happen as the
> <bu:replace> tag is really a view concern.

I'm agree.

> A way to achieve this is for widgets to produce an additional
> updated="true" attribute when they were updates. The FormsGenerator can
> then easily wrap such widget elements with a <bu:replace> that can then
> be consumed by the BUTransformer and whatever comes next.

It's clear. I will try to implement it. Our forms are so fat (this is a
feature :-) that ajax for me is not an option :-)

> Hope this helped :-)
> Sylvain



View raw message