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"
enctype="multipart/form-data">
...
<ft:widget id="maintab_state">
<fi:styling type="hidden"/>
</ft:widget>
...
<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',
position())"/>
<ft:widget id="{$row}roomarea">
<fi:styling size="2"/>
</ft:widget>
</xsl>
</xsl:variable>
---
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"
select="/fi:form-generated/fi:form[1]/fi:widgets//[EMAIL PROTECTED]"/>
<!-- -->
<xsl:template match="/">
<xsl:apply-templates select="$template/page"/>
</xsl:template>
<!-- -->
<xsl:function name="ft:repeater-rows" as="node()*">
<xsl:param name="id"/>
<xsl:sequence select="ft:widget($id)/fi:repeater-row"/>
</xsl:function>
<!-- -->
<xsl:template match="ft:widget">
<xsl:variable name="widget" select="ft:widget(@id)"/>
<xsl:element name="{name($widget)}">
<xsl:sequence select="$widget/@* | $widget/*"/>
<xsl:apply-templates/>
</xsl:element>
</xsl:template>
---
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
<ft:..>
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.
>
yes
>>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
>
yep.
Regards.
