Performance issue due to large amount of xforms components

> Hi All,
>
> Thanks for those who contribute to this mailing list, and many thanks for
> orbeon developers (this is a cool product!)
>
> My configuration:
> I'm running Orbeon 3.8.0.201005141856 CE. This version is already on
> production, so we cannot upgrade very easily. This is a separate deployment.
>
> Now, my problem(s):
>
> - I faced a performance problem when I tried to display a simple xbl in one
> of my forms, this xbl component does almost nothing: it displays only one
> group coded inside the xbl component, based on a value, passed as a
> parameter (dynamic, thanks to xpath). This is done to display a form which
> controls layout are chosen accordingly to an xml conf file (serialized into
> an instance). Hereafter the main code:
>
>                   <xforms:group ref=".[$type = 'text']">
>                            <xforms:group ref=".[$mode = 'editable']">
>                                <xforms:input ref="$value">
>                                    <xforms:label
> ref="$display"></xforms:label>
>                                </xforms:input>
>                            </xforms:group>
>                            <xforms:group ref=".[$mode = 'readonly']">
>                                <xforms:output ref="$value">
>                                    <xforms:label
> ref="$display"></xforms:label>
>                                </xforms:output>
>                            </xforms:group>
>                        </xforms:group>
>
>                        <xforms:group ref=".[$type = 'date']">
>                            <xforms:group ref=".[$mode = 'editable']">
>                                <xforms:input ref="$node">
>                                    <xforms:label
> ref="$display"></xforms:label>
>                                    <xforms:alert>this value is
> invalid</xforms:alert>
>                                </xforms:input>
>                            </xforms:group>
>                            <xforms:group ref=".[$mode = 'readonly']">
>                                <xforms:output ref="$value">
>                                    <xforms:label
> ref="$display"></xforms:label>
>                                </xforms:output>
>                            </xforms:group>
>                        </xforms:group>
>                        ...
>                       <xforms:group ref=".[$type = 'dn']"
> appearance="xxforms:internal">
>                         <xforms:group ref=".[$mode = 'editable']">
>                                *<fr:searchControlDialog result-nodeset="."
> selectMode="." conf-instance=".">
>                                     <xforms:label
> ref="$display"></xforms:label>
>                                 </fr:searchControlDialog>*
>                          </xforms:group>
>                       </xforms:group>
>
> The bolded component is in fact a wrapper, which is also an xbl, providing a
> control which combines xxforms:dialog, fr:datatable, and custom submissions
> in order to perform search in a directory.
>
> So far that's not a big deal, and it worked pretty well until I tried to
> place it in a repeat and iterate a certain number of times (~20 times). It
> takes now almost 8s (accordingly to the log), and most of what is evaluated
> is not necessary, because I do want what is not relevant to *never* be
> displayed (so in my case, non relevant groups inner content evaluations are
> useless)
>
> I noticed that if I remove the searchControl xbl, it takes 8 times less
> (around 1s) to display the page, which is an acceptable range for the
> generation timing.
>
> - The second problem, I can't find a satisfying solution:
>
> 1. first try:
> After noticing that, I tried to force orbeon forms engine not to process my
> non relevant groups: first by setting a wrapper around it
>
>  <xhtml:div class="{if ($type != 'dn') then 'xforms-disabled' else ''}">
> /      /
>  </xhtml:div>
>
> this was something you gave as an advice in another performance issue post
> of the mailing list... But that didn't reduce my evaluation time. I tried
> also with a *switch/case*, but that's not better.
>
> 2. second try:
> I saw an option on xforms:groups that seemed to be exactly what I wanted
> :*appearance:"xxforms:internal"* , which from what I understood, allow to
> not perform code generation on the client (and I hoped that it didn't
> perform the evaluation on child nodes as well) but it did nothing either...
>
> 3. third (and last for now) try:
> I was picturing how to prevent evaluation, and I decided to use xslt to
> generate only one group corresponding exactly to what I need, but here
> again, this was a fail too!
> In fact I couldn't find a way to give parameters to the xslt transformation!
>
>
>
>                                <xforms:group xxbl:scope="inner">
>                                    <xsl:choose>
>                                        <xsl:when test="@type = 'text'">
>                                             <xsl:choose>
>                                                 <xsl:when test="@mode =
> 'editable'">
>                                                     <xforms:input
> ref="$value">
>                                                         <xforms:label
> ref="$display"></xforms:label>
>                                                     </xforms:input>
>                                                 </xsl:when>
>                                                 <xsl:otherwise>
>                                                     <xforms:output
> ref="$value">
>                                                         <xforms:label
> ref="$display"></xforms:label>
>                                                     </xforms:output>
>                                                 </xsl:otherwise>
>                                             </xsl:choose>
>                                        </xsl:when>
>                                    </xsl:choose>
>                                </xforms:group>
>
> The control is invoked like that:
>
>            <fr:adaptativeInput          mode="$currModelEntry/@editMode"
>                                                ref="$currAttribute"
>
> type="$currentModelEntry/@type"
>
> display="$currModelEntry/@label"
>                                                selectMode =
> "$currentModelEntry/@multi" >
>            </fr:adaptativeInput>
>
> As you can see, these parameters are passed thanks to xpath, and that make
> them unable to be properly read by the xbl -xslt made- component (And i
> found no way to do so...)
>
> So, maybe I'm totally wrong in my conception, and I shouldn't have to do
> things like that (in this case, any refactoring proposition would be much
> appreciated :-))
> But in the other case, would you have a solution for me? I will surely
> encounter the same problem soon with other components, when it involves
> group relevance with big amount of controls under, so the solution of this
> problem is very important for me.
>
> Many thanks for those who read me!
>
> Best regards,
>
> Thomas Broussard
>
>
>
> --
> View this message in context: http://orbeon-forms-ops-users.24843.n4.nabble.com/Performance-issue-due-to-large-amount-of-xforms-components-tp4655252.html
> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>