Re: [Xsltforms-support] Xsltforms-support Digest, Vol 8, Issue 11
Brought to you by:
alain-couthures
Menu
▾
▴
Re: [Xsltforms-support] Xsltforms-support Digest, Vol 8, Issue 11
|
From: Dominique R. <dr...@gm...> - 2010-01-25 09:30:11
|
About XSLTForms performance I made some performance tests during may, 2009 See About testing - Results<http://www.web21th.com/samples/performances.htm> <http://www.web21th.com/samples/performances.htm>Others Testing end samples<http://www.web21th.com/samples/index.html> I have just added a probe in order to measure js.init time <http://www.web21th.com/samples/index.html>Dominique Rabeuf 2010/1/25 <xsl...@li...> > Send Xsltforms-support mailing list submissions to > xsl...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > or, via email, send a message with subject or body 'help' to > xsl...@li... > > You can reach the person managing the list at > xsl...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Xsltforms-support digest..." > > > Today's Topics: > > 1. Minimal triggers scrolling the page (Micah Dubinko) > 2. xsltforms Performance (Christopher Dedels) > 3. Re: xsltforms Performance (COUTHURES Alain) > 4. select1 behaviour (Stephen Cameron) > 5. Re: select1 behaviour (Tambet Matiisen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 22 Jan 2010 17:40:24 -0800 > From: Micah Dubinko <Mic...@ma...> > Subject: [Xsltforms-support] Minimal triggers scrolling the page > To: "xsl...@li..." > <xsl...@li...> > Message-ID: <71D...@ma...> > Content-Type: text/plain; charset="us-ascii" > > Hey Alain, > > Right now, triggers with appearance="minimal" use an <a href="#"> element, > which has the undesirable effect of scrolling the page to the top. > > The responsible code looks like this: > > <xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > match="xforms:trigger|xforms:submit"> > <xsl:variable name="innerbody"> > <xsl:apply-templates select="xforms:label"> > <xsl:with-param name="appearance" select="'span'"/> > </xsl:apply-templates> > </xsl:variable> > <xsl:call-template name="field"> > <xsl:with-param name="appearance">none</xsl:with-param> > <xsl:with-param name="body"> > <xsl:choose> > <xsl:when test="@appearance = 'minimal'"> > <a href="#"> > <xsl:copy-of > select="$innerbody"/> > </a> > </xsl:when> > ... > > Would it be possible to change the minimal trigger (or add a new appearance > choice with some name other than 'minimal') to use an href of > "javascript:void(0);" or something else that doesn't trigger the scroll > effect? > > For example, adding a new choice like > > <xsl:choose> > <xsl:when test="@appearance = 'minimal'"> > <a href="javascript:void(0);"> > <xsl:copy-of > select="$innerbody"/> > </a> > </xsl:when> > ... > > What do you think? > > -m > > > ------------------------------ > > Message: 2 > Date: Sat, 23 Jan 2010 09:56:36 -0500 > From: Christopher Dedels <cd...@vi...> > Subject: [Xsltforms-support] xsltforms Performance > To: "xsl...@li..." > <xsl...@li...> > Message-ID: > <D88...@MA...rtify.local> > Content-Type: text/plain; charset="us-ascii" > > I have been using xsltforms to create some complicated interfaces. > xsltforms performance appears to degrade significantly as the size of the > instance data increases. It does not seem to be impacted as significantly > by the number of input controls on the page. This means that paging the > items in my repeat element has almost no performance impact. > > Profiling tools report at least 13 seconds in IE 8 (2.5 seconds in > FF/Chrome) to "tab" from one field to the next, regardless of whether the > data in the field was changed. As you can expect, this is not acceptable > for my users. > > What are the scalability limits of xsltforms? Do you have any suggestions > on how to improve performance in my xforms document? > > Thanks > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 3 > Date: Sat, 23 Jan 2010 17:16:27 +0100 > From: COUTHURES Alain <ala...@ag...> > Subject: Re: [Xsltforms-support] xsltforms Performance > To: Christopher Dedels <cd...@vi...> > Cc: "xsl...@li..." > <xsl...@li...> > Message-ID: <4B5...@ag...> > Content-Type: text/plain; charset="iso-8859-1" > > Christopher, > > > > I have been using xsltforms to create some complicated interfaces. > > xsltforms performance appears to degrade significantly as the size of > > the instance data increases. It does not seem to be impacted as > > significantly by the number of input controls on the page. This means > > that paging the items in my repeat element has almost no performance > > impact. > > > Can you send me a link or the XForms document itself with its data ? > > > > > > > > Profiling tools report at least 13 seconds in IE 8 (2.5 seconds in > > FF/Chrome) > > > Yes, IE is still very slower... > > > > to "tab" from one field to the next, regardless of whether the data in > > the field was changed. > > > It's a good situation to check with a javascript debugger (focus is > lost,...). > > > > As you can expect, this is not acceptable for my users. > > > There are different possibilities of optimization in XSLTForms: less > generated HTML elements, less Javascript instructions executed,... > > Because this has not been done yet, I hope that a minimal effort could > improve it significantly. > > > > > > > > What are the scalability limits of xsltforms? > > > This is not yet determined but there are many parameters involved: > complexity, instance size, number of bindings, ... > > > > Do you have any suggestions on how to improve performance in my > > xforms document? > > > Use of // in XPath expressions is surely to avoid. > > -Alain > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 4 > Date: Sun, 24 Jan 2010 22:42:07 +1100 > From: Stephen Cameron <Ste...@ut...> > Subject: [Xsltforms-support] select1 behaviour > To: xsl...@li... > Message-ID: <4B5...@ut...> > Content-Type: text/plain; CHARSET=US-ASCII; format=flowed > > Hello, > > I have a couple of questions regarding the behaviour of select1 xforms > controls. I'd appreciate it if someone could fill me in on what they > should and should not be able to do. > > The following is a test case: > > <?xml version="1.0" encoding="UTF-8"?> > <?xml-stylesheet href="forms/xsltforms/xsltforms.xsl" type="text/xsl"?> > <html xmlns="http://www.w3.org/1999/xhtml" > xmlns:xf="http://www.w3.org/2002/xforms" > xmlns:ev="http://www.w3.org/2001/xml-events" > xmlns:aatams="http://www.imos.org.au/aatams" > xmlns:wfs="http://www.opengis.net/wfs" > xmlns:ogc="http://www.opengis.net/ogc" > xmlns:ows="http://www.opengis.net/ows" > xmlns:gml="http://www.opengis.net/gml" > > <head> > <xf:model id="m1"> > <xf:instance id="template"> > <wfs:Insert> > <wfs:FeatureCollection> > <gml:featureMember> > <aatams:device> > <aatams:name/> > <aatams:device_type_ref> > <aatams:device_type > gml:id="aatams.device_type.2"> > > <aatams:name>TRANSMITTER</aatams:name> > </aatams:device_type> > </aatams:device_type_ref> > </aatams:device> > </gml:featureMember> > </wfs:FeatureCollection> > </wfs:Insert> > </xf:instance> > <xf:instance id="types" > > <wfs:FeatureCollection> > <gml:featureMember> > <aatams:device_type gml:id="aatams.device_type.1"> > <aatams:name>RECEIVER</aatams:name> > </aatams:device_type> > </gml:featureMember> > <gml:featureMember> > <aatams:device_type gml:id="aatams.device_type.2"> > <aatams:name>TRANSMITTER</aatams:name> > </aatams:device_type> > </gml:featureMember> > </wfs:FeatureCollection> > </xf:instance> > </xf:model> > </head> > <body> > <xf:group ref="instance('template')//aatams:device"> > <xf:input ref="aatams:name" > > <xf:label>Device Name:</xf:label> > </xf:input> > <br/> > <xf:select1 ref="aatams:device_type_ref/aatams:device_type"> > <xf:label>Device Type: </xf:label> > <xf:itemset > nodeset="instance('types')/gml:featureMember/aatams:device_type"> > <xf:value ref="." /> > <xf:label ref="aatams:name" /> > </xf:itemset> > </xf:select1> > </xf:group> > <br/> > <xf:output > > ref="instance('template')//aatams:device/aatams:device_type_ref/aatams:device_type/aatams:name" > > > <xf:label>Device Type Name:</xf:label> > </xf:output> > <div id="console" style="display:block;top:100px;" /> > </body> > </html> > > My aim is to replace the aatams:device_type node in the 'template' > instance with another aatams:device_type (node and children ) selected > by the user in the xf:select1 control. However this test case doesn't > work, the xf:output does not change its value. The xf:select1 control by > the Xforms standard has a "single-node-binding", it seems that by this > the standard actually means a single text node or an attribute if the > above test does not work. > > This is an important question as being not being able to replace a > complex node in an instance complicates matter considerably. At the > moment I am forced to build an instance at the time of submission using > the ids of all the complex elements that the user has selected and > which have been saved into another instance via bindings. This is not > the correct way to be doing this I'm sure as it now prevents me from > doing other things, like using templates, saving partly completed forms > and retrieving them later, and creating new complex sub-elements. > > Particularly when you consider another issue as follows: > > If the nodes in nodeset that is used in the xf:select1 are more complex > than the above example (which is nearly all the time for me) then it > would be very desirable to be able to include a more complex 'compound' > value in the xf:label of the xf:itemset. Here is an example. > > I have a list of receiver deployments. I want the user to be able to > select a deployment from a list. The only way the user can tell which > deployment is the correct one is to know 'where', 'what' and 'when', so > the label needs to be a concatenation of three elements from each > itemset node; where the deployment occurred (a 'station' name), what was > deployed ( a receiver 'code-name') and the date of deployment. To get > these three values strung together I currently have to have a view in my > database that does the concatenation and use this extra 'feature' > published as xml by my webservice to build my nodeset and then based on > the xf:value value of the node selected by the user in the select1 > itemlist, find the correct aatams:receiver_deployment 'single-node' and > stick it into the template. > > So to clarify my ideal nodeset would be something like > > <xf:itemset > > nodeset="instance('deployments')/gml:featureMember/aatams:receiver_deployment"> > <xf:value ref="." /> > <xf:label > > ref="concatenate(aatams:installation/aatams:station/aatams:name,'-',aatams:receiver/aatams:code_name,'-',aatams:deployment_date > )"> > </xf:itemset> > > It would also be good to be able to sort the nodeset as well, in the > same manner as XSLT perhaps. > > So hopefully from these two examples I have shown that what should be > very simple has become quite complicated and definitely not what Xforms > is supposed to be about! > > Thanks for your interest. > > > -- > Regards > > Stephen Cameron > > Data Programmer > Integrated Marine Observing System (IMOS) > eMarine Information Infrastructure Project > University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia > > Tel: +61 3 6226 8507 > Fax: +61 3 6226 2997 > Email: ste...@ut... > URL: http://www.imos.org.au/eM .html > > > > > ------------------------------ > > Message: 5 > Date: Mon, 25 Jan 2010 10:48:05 +0200 > From: Tambet Matiisen <tam...@gm...> > Subject: Re: [Xsltforms-support] select1 behaviour > To: xsl...@li... > Message-ID: <4B5...@gm...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Stephen Cameron wrote: > > My aim is to replace the aatams:device_type node in the 'template' > > instance with another aatams:device_type (node and children ) selected > > by the user in the xf:select1 control. However this test case doesn't > > work, the xf:output does not change its value. The xf:select1 control by > > the Xforms standard has a "single-node-binding", it seems that by this > > the standard actually means a single text node or an attribute if the > > above test does not work. > > > > Isn't the <xforms:copy> element meant for this case? See > http://www.w3.org/TR/2003/REC-xforms-20031014/index-all.html#ui-adv-copy > > I don't know if XSLTForms supports the <xforms:copy> element. > > > So to clarify my ideal nodeset would be something like > > > > <xf:itemset > > > nodeset="instance('deployments')/gml:featureMember/aatams:receiver_deployment"> > > <xf:value ref="." /> > > <xf:label > > > ref="concatenate(aatams:installation/aatams:station/aatams:name,'-',aatams:receiver/aatams:code_name,'-',aatams:deployment_date > > )"> > > </xf:itemset> > > > > I'm not sure if this works (or even should work) for <xf:itemset> > labels, but it surely works for <xf:output> labels, at least in Chiba. > > <xf:label><xf:output > value="concat(aatams:installation/aatams:station/aatams:name,'-',aatams:receiver/aatams:code_name,'-',aatams:deployment_date > )"/></xf:label> > > > Tambet > > > > ------------------------------ > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > > ------------------------------ > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > > End of Xsltforms-support Digest, Vol 8, Issue 11 > ************************************************ > |
