xsltforms-support

[Xsltforms-support] quicker rendering

[Stephen C. <ste...@gm...>]

Hello All,

I have a large xform and its going to get bigger, the time to transform the
xform and render it is now quite significant and getting to the point where
it is an issue, given that people don't see anything happening throughout
the process.

One option is to pre-transform the xml 'form' into an html 'page', which I
used to do successfully but now cannot using Saxon, it complains.

But my questions actually relate to browser transformation:

1. If I give all of the xform controls an explicit ID, rather than the
xsltforms.xsl stylesheet having to calculate them, does this speed up the
transformation significantly?

2. Is it possible perhaps to change the way that the transform occurs such
that the html markup is generated first and then the Xform related
javascript second. In theory the browser should start rendering the page
before the parsing of the Javascript section is completed. I'm imagining
this as a two-pass process in the xsltforms stylesheet.

I have to say that once the rendering is completed the performance of the
form itself is excellent, despite its growing complexity. I assume this is
due to the presence of a true dependency graph in the newer versions of
XSLTForms. :)

Thanks for your insights.

Steve Cameron

Re: [Xsltforms-support] quicker rendering

[Dan M. <dan...@gm...>]

Hi Stephen,

One alternative I might suggest is to use a "multi-tab" form and use a
technique called "incremental model loading" if your model is large.

Here is a demo of incremental model loading:

http://en.wikibooks.org/wiki/XForms/Incremental_Model_Loading

here is some sample UI for the tabs:

http://en.wikibooks.org/wiki/XForms/Horizontal_File_Tab_Menu

The tricky part comes if you have bind rules that span tabs.

- Dan

On Thu, Feb 9, 2012 at 3:19 AM, Stephen Cameron
<ste...@gm...>wrote:

> Hello All,
>
> I have a large xform and its going to get bigger, the time to transform
> the xform and render it is now quite significant and getting to the point
> where it is an issue, given that people don't see anything happening
> throughout the process.
>
> One option is to pre-transform the xml 'form' into an html 'page', which I
> used to do successfully but now cannot using Saxon, it complains.
>
> But my questions actually relate to browser transformation:
>
> 1. If I give all of the xform controls an explicit ID, rather than the
> xsltforms.xsl stylesheet having to calculate them, does this speed up the
> transformation significantly?
>
> 2. Is it possible perhaps to change the way that the transform occurs such
> that the html markup is generated first and then the Xform related
> javascript second. In theory the browser should start rendering the page
> before the parsing of the Javascript section is completed. I'm imagining
> this as a two-pass process in the xsltforms stylesheet.
>
> I have to say that once the rendering is completed the performance of the
> form itself is excellent, despite its growing complexity. I assume this is
> due to the presence of a true dependency graph in the newer versions of
> XSLTForms. :)
>
> Thanks for your insights.
>
> Steve Cameron
>
>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>


-- 
Dan McCreary
Semantic Solutions Architect
office: (952) 931-9198
cell: (612) 986-1552

Re: [Xsltforms-support] quicker rendering

[Stephen C. <ste...@gm...>]

Hi Dan,

Its not the model that is the issue in this case but the form itself.

Doesn't the current versions of XSLTForms make use of a browser DOM object
for each model instance? Whereas originally it built a Javascript tree
which was slower.


On Fri, Feb 10, 2012 at 1:11 AM, Dan McCreary <dan...@gm...>wrote:

> Hi Stephen,
>
> One alternative I might suggest is to use a "multi-tab" form and use a
> technique called "incremental model loading" if your model is large.
>
> Here is a demo of incremental model loading:
>
> http://en.wikibooks.org/wiki/XForms/Incremental_Model_Loading
>
> here is some sample UI for the tabs:
>
> http://en.wikibooks.org/wiki/XForms/Horizontal_File_Tab_Menu
>
> The tricky part comes if you have bind rules that span tabs.
>
> - Dan
>
> On Thu, Feb 9, 2012 at 3:19 AM, Stephen Cameron <
> ste...@gm...> wrote:
>
>> Hello All,
>>
>> I have a large xform and its going to get bigger, the time to transform
>> the xform and render it is now quite significant and getting to the point
>> where it is an issue, given that people don't see anything happening
>> throughout the process.
>>
>> One option is to pre-transform the xml 'form' into an html 'page', which
>> I used to do successfully but now cannot using Saxon, it complains.
>>
>> But my questions actually relate to browser transformation:
>>
>> 1. If I give all of the xform controls an explicit ID, rather than the
>> xsltforms.xsl stylesheet having to calculate them, does this speed up the
>> transformation significantly?
>>
>> 2. Is it possible perhaps to change the way that the transform occurs
>> such that the html markup is generated first and then the Xform related
>> javascript second. In theory the browser should start rendering the page
>> before the parsing of the Javascript section is completed. I'm imagining
>> this as a two-pass process in the xsltforms stylesheet.
>>
>> I have to say that once the rendering is completed the performance of the
>> form itself is excellent, despite its growing complexity. I assume this is
>> due to the presence of a true dependency graph in the newer versions of
>> XSLTForms. :)
>>
>> Thanks for your insights.
>>
>> Steve Cameron
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>>
>
>
> --
> Dan McCreary
> Semantic Solutions Architect
> office: (952) 931-9198
> cell: (612) 986-1552
>

Re: [Xsltforms-support] quicker rendering

[Alain C. <ala...@ag...>]

Hello Steve,

Which version of Saxon are you using? The node-set() function calls are 
always to be customized for each XSLT engine and Saxon changed its own 
approach last year, as far as I remember...

I would be happy to get effective time measures for the transformation step.

On Windows, I'm using Powershell which is based on .Net 2.0 by default. 
I could send you a script file for testing if you wish.

At browser side, it's difficult to measure something. Maybe native 
profilers might give an indication for XSLT step, especially if the 
generated page is not automatically inserting and calling Javascript 
instructions. With XSLTForms Profiler, you will get measures for the 
HTML and the Javascript part loadings. XSLTForms is adding a lot of HTML 
elements, "just in case" a group could become irrelevant for example.

Yes, the way ids are added is clearly not optimized, I think that using 
xsl:number could be interesting for that purpose, but I'm still not 
convinced that it is costing a lot. Adding yourself every possible ids 
might be a workaround.

Changing the place where the generated script elements are is also easy 
to modify in the XSLT stylesheet.

Could you please send me one of your huge forms?

Thanks!

-Alain

Le 09/02/2012 10:19, Stephen Cameron a écrit :
> Hello All,
>
> I have a large xform and its going to get bigger, the time to 
> transform the xform and render it is now quite significant and getting 
> to the point where it is an issue, given that people don't see 
> anything happening throughout the process.
>
> One option is to pre-transform the xml 'form' into an html 'page', 
> which I used to do successfully but now cannot using Saxon, it complains.
>
> But my questions actually relate to browser transformation:
>
> 1. If I give all of the xform controls an explicit ID, rather than the 
> xsltforms.xsl stylesheet having to calculate them, does this speed up 
> the transformation significantly?
>
> 2. Is it possible perhaps to change the way that the transform occurs 
> such that the html markup is generated first and then the Xform 
> related javascript second. In theory the browser should start 
> rendering the page before the parsing of the Javascript section is 
> completed. I'm imagining this as a two-pass process in the xsltforms 
> stylesheet.
>
> I have to say that once the rendering is completed the performance of 
> the form itself is excellent, despite its growing complexity. I assume 
> this is due to the presence of a true dependency graph in the newer 
> versions of XSLTForms. :)
>
> Thanks for your insights.
>
> Steve Cameron
>
>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] quicker rendering

[Leigh L K. Jr <lei...@xe...>]

Stephen,
You might also consider using the subform support:

http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_load_Element
http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_unload_Element 
<http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_load_Element>

Alain has implemented load/@show='embed' support in the SVN versions of 
XSLTForms.

The event sequence model isn't yet written up but you should expect 
model-construct-done and refresh and so on to work.
The loaded subform should be an XHTML+XForms document with a minimal 
model (if you want to use the outer form's model) or a full model with 
an ID (if you want the page to use the new model).  Start the html/body 
with a single xf:group with the desired @model attribute.  In the outer 
page, use an empty xf:group to contain the loaded subform.  The xf:group 
will get an xforms-subform-loaded CSS class added to it when then load 
is done, and it will be removed when the unload is done.

Leigh.


On 02/09/2012 01:59 PM, Stephen Cameron wrote:
> Hi Dan,
>
> Its not the model that is the issue in this case but the form itself.
>
> Doesn't the current versions of XSLTForms make use of a browser DOM 
> object for each model instance? Whereas originally it built a 
> Javascript tree which was slower.
>
>
> On Fri, Feb 10, 2012 at 1:11 AM, Dan McCreary <dan...@gm... 
> <mailto:dan...@gm...>> wrote:
>
>     Hi Stephen,
>
>     One alternative I might suggest is to use a "multi-tab" form and
>     use a technique called "incremental model loading" if your model
>     is large.
>
>     Here is a demo of incremental model loading:
>
>     http://en.wikibooks.org/wiki/XForms/Incremental_Model_Loading
>
>     here is some sample UI for the tabs:
>
>     http://en.wikibooks.org/wiki/XForms/Horizontal_File_Tab_Menu
>
>     The tricky part comes if you have bind rules that span tabs.
>
>     - Dan
>
>     On Thu, Feb 9, 2012 at 3:19 AM, Stephen Cameron
>     <ste...@gm... <mailto:ste...@gm...>>
>     wrote:
>
>         Hello All,
>
>         I have a large xform and its going to get bigger, the time to
>         transform the xform and render it is now quite significant and
>         getting to the point where it is an issue, given that people
>         don't see anything happening throughout the process.
>
>         One option is to pre-transform the xml 'form' into an html
>         'page', which I used to do successfully but now cannot using
>         Saxon, it complains.
>
>         But my questions actually relate to browser transformation:
>
>         1. If I give all of the xform controls an explicit ID, rather
>         than the xsltforms.xsl stylesheet having to calculate them,
>         does this speed up the transformation significantly?
>
>         2. Is it possible perhaps to change the way that the transform
>         occurs such that the html markup is generated first and then
>         the Xform related javascript second. In theory the browser
>         should start rendering the page before the parsing of the
>         Javascript section is completed. I'm imagining this as a
>         two-pass process in the xsltforms stylesheet.
>
>         I have to say that once the rendering is completed the
>         performance of the form itself is excellent, despite its
>         growing complexity. I assume this is due to the presence of a
>         true dependency graph in the newer versions of XSLTForms. :)
>
>         Thanks for your insights.
>
>         Steve Cameron
>
>
>
>
>         ------------------------------------------------------------------------------
>         Virtualization & Cloud Management Using Capacity Planning
>         Cloud computing makes use of virtualization - but cloud computing
>         also focuses on allowing computing to be delivered as a service.
>         http://www.accelacomm.com/jaw/sfnl/114/51521223/
>         _______________________________________________
>         Xsltforms-support mailing list
>         Xsl...@li...
>         <mailto:Xsl...@li...>
>         https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>
>
>
>     -- 
>     Dan McCreary
>     Semantic Solutions Architect
>     office: (952) 931-9198 <tel:%28952%29%20931-9198>
>     cell: (612) 986-1552 <tel:%28612%29%20986-1552>
>
>

Re: [Xsltforms-support] quicker rendering

[Stephen C. <ste...@gm...>]

Thanks Leigh,

Interesting suggestion but in this case I'd first like to look at the
actual process of generating the page markup via XSLT transformation of the
XForm. The theory of HTML is that a browser can start rendering before it
has received (or parsed) all of a page. So, I feel its possible to display
the page/form layout very early on, before it is filled with data.
Presently there is no feedback to the user, other than via the browser
icons, to tell the user that something is happening and I think this is due
mainly to the html markup being generated at the end of the XSLT
transformation after all the Javascript.

I'd also be interested to know if you could display a updating progress bar
over the page whilst the loading/processing of the model instances is going
on.

Mind you, I just tried my big form in IE9.0 and it opened very quickly
compared to Firefox 10, so maybe this is a very low priority.

But I can see the usefulness of subforms for another part of my project
though!

Steve C

On Wed, Feb 15, 2012 at 8:15 AM, Leigh L Klotz Jr <lei...@xe...>wrote:

>  Stephen,
> You might also consider using the subform support:
>
> http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_load_Element
> http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_unload_Element<http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_load_Element>
>
> Alain has implemented load/@show='embed' support in the SVN versions of
> XSLTForms.
>
> The event sequence model isn't yet written up but you should expect
> model-construct-done and refresh and so on to work.
> The loaded subform should be an XHTML+XForms document with a minimal model
> (if you want to use the outer form's model) or a full model with an ID (if
> you want the page to use the new model).  Start the html/body with a single
> xf:group with the desired @model attribute.  In the outer page, use an
> empty xf:group to contain the loaded subform.  The xf:group will get an
> xforms-subform-loaded CSS class added to it when then load is done, and it
> will be removed when the unload is done.
>
> Leigh.
>
>
>
> On 02/09/2012 01:59 PM, Stephen Cameron wrote:
>
> Hi Dan,
>
> Its not the model that is the issue in this case but the form itself.
>
> Doesn't the current versions of XSLTForms make use of a browser DOM object
> for each model instance? Whereas originally it built a Javascript tree
> which was slower.
>
>
> On Fri, Feb 10, 2012 at 1:11 AM, Dan McCreary <dan...@gm...>wrote:
>
>> Hi Stephen,
>>
>> One alternative I might suggest is to use a "multi-tab" form and use a
>> technique called "incremental model loading" if your model is large.
>>
>> Here is a demo of incremental model loading:
>>
>> http://en.wikibooks.org/wiki/XForms/Incremental_Model_Loading
>>
>> here is some sample UI for the tabs:
>>
>> http://en.wikibooks.org/wiki/XForms/Horizontal_File_Tab_Menu
>>
>> The tricky part comes if you have bind rules that span tabs.
>>
>> - Dan
>>
>>  On Thu, Feb 9, 2012 at 3:19 AM, Stephen Cameron <
>> ste...@gm...> wrote:
>>
>>>  Hello All,
>>>
>>> I have a large xform and its going to get bigger, the time to transform
>>> the xform and render it is now quite significant and getting to the point
>>> where it is an issue, given that people don't see anything happening
>>> throughout the process.
>>>
>>> One option is to pre-transform the xml 'form' into an html 'page', which
>>> I used to do successfully but now cannot using Saxon, it complains.
>>>
>>> But my questions actually relate to browser transformation:
>>>
>>> 1. If I give all of the xform controls an explicit ID, rather than the
>>> xsltforms.xsl stylesheet having to calculate them, does this speed up the
>>> transformation significantly?
>>>
>>> 2. Is it possible perhaps to change the way that the transform occurs
>>> such that the html markup is generated first and then the Xform related
>>> javascript second. In theory the browser should start rendering the page
>>> before the parsing of the Javascript section is completed. I'm imagining
>>> this as a two-pass process in the xsltforms stylesheet.
>>>
>>> I have to say that once the rendering is completed the performance of
>>> the form itself is excellent, despite its growing complexity. I assume this
>>> is due to the presence of a true dependency graph in the newer versions of
>>> XSLTForms. :)
>>>
>>> Thanks for your insights.
>>>
>>> Steve Cameron
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> Xsltforms-support mailing list
>>> Xsl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>
>>>
>>
>>
>> --
>> Dan McCreary
>> Semantic Solutions Architect
>> office: (952) 931-9198
>> cell: (612) 986-1552
>>
>
>
>