xsltforms-support Mailing List for XSLTForms (Page 98)
Brought to you by:
alain-couthures
Menu
▾
▴
xsltforms-support — XSLTForms support list
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(9) |
Jul
(16) |
Aug
(5) |
Sep
(43) |
Oct
(36) |
Nov
(58) |
Dec
(43) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(79) |
Feb
(81) |
Mar
(107) |
Apr
(93) |
May
(85) |
Jun
(54) |
Jul
(64) |
Aug
(54) |
Sep
(45) |
Oct
(53) |
Nov
(34) |
Dec
(77) |
| 2011 |
Jan
(56) |
Feb
(53) |
Mar
(52) |
Apr
(66) |
May
(44) |
Jun
(16) |
Jul
(28) |
Aug
(5) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(46) |
| 2012 |
Jan
(16) |
Feb
(38) |
Mar
(47) |
Apr
(45) |
May
(41) |
Jun
(41) |
Jul
(72) |
Aug
(17) |
Sep
(10) |
Oct
(16) |
Nov
(29) |
Dec
(30) |
| 2013 |
Jan
(25) |
Feb
(13) |
Mar
(20) |
Apr
(25) |
May
(34) |
Jun
(8) |
Jul
(12) |
Aug
(9) |
Sep
(21) |
Oct
(19) |
Nov
(6) |
Dec
(2) |
| 2014 |
Jan
(14) |
Feb
(8) |
Mar
(7) |
Apr
(13) |
May
(33) |
Jun
(13) |
Jul
(6) |
Aug
(5) |
Sep
(5) |
Oct
(34) |
Nov
(7) |
Dec
|
| 2015 |
Jan
(1) |
Feb
(6) |
Mar
(17) |
Apr
(12) |
May
(10) |
Jun
(18) |
Jul
(31) |
Aug
(9) |
Sep
(3) |
Oct
(6) |
Nov
(19) |
Dec
(1) |
| 2016 |
Jan
(18) |
Feb
(4) |
Mar
(13) |
Apr
(19) |
May
|
Jun
(17) |
Jul
(7) |
Aug
|
Sep
(3) |
Oct
(6) |
Nov
(3) |
Dec
|
| 2017 |
Jan
(5) |
Feb
(17) |
Mar
(4) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(6) |
Dec
(4) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(13) |
Feb
(17) |
Mar
(8) |
Apr
(11) |
May
(15) |
Jun
(11) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2021 |
Jan
(9) |
Feb
(26) |
Mar
(17) |
Apr
|
May
(7) |
Jun
(18) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2023 |
Jan
(10) |
Feb
|
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(11) |
Nov
(8) |
Dec
(5) |
| 2024 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thorsten R. <ju...@sc...> - 2010-01-29 22:06:26
|
Hi > The required instructions to interpret an XSLT > processing-instruction (such as the one for applying xsltforms.xsl > !) in the return of the submission are not yet implemented. You seem to prefer the other solution - which I don't fully understand, so I'm a bad judge for that. However, doing a manual transform is rather trivial (I've tried, it really is). See http://www.w3schools.com/xsl/xsl_client.asp . This example is synchronous but I guess you have code for async XHR in place so adapting that would be simple. That only leaves the task of finding the processing instruction nodes. They are usually at the beginning of the document, so that should also be no problem. If it is though, a tiny dedicated XSLT could be used to extract such nodes. Regards Thorsten |
|
From: Klotz, L. <Lei...@xe...> - 2010-01-29 17:40:15
|
I don't mean to cause confusion; I meant with instance data to submit, serialized as application/x-www-form-urlencoded.
For example:
<html>
<head>
<model>
<instance>
<data xmlns="">
<q />
<hl>en</hl>
</data>
</instance>
<submission id="do-search" method="get" resource="http://www.example.com/search" replace="all" />
</model>
</head>
<body>
<input ref="q">
<label>Search: </label>
<send submission="do-search" ev:event="DOMActivate" />
</input>
<select1 ref="hl">
<label>Language</label>
<item><label>English</label><value>en</value></item>
<item><label>French</label><value>fr</value></item>
</select1>
</body>
</html>
-----Original Message-----
From: COUTHURES Alain [mailto:ala...@ag...]
Sent: Friday, January 29, 2010 9:34 AM
To: Klotz, Leigh
Cc: Thorsten Roggendorf; xsl...@li...
Subject: Re: [Xsltforms-support] Problem with replace all
Leigh,
> I still believe the <submssion method="get" replace="all"> could
> easily use the same technique as the XSTLForms feature <submssion
> method="xml-urlencoded-post"> and use the underlying HTML4 form
> implementation for the GET instead of using XHR.
>
> This seems like a small amount of work, and would fix the main use case immediately.
>
Don't you think that <submission method="get" replace="all">, with no instance data to submit, has no meaning itself and that <load> should be used instead ?
-Alain
|
|
From: COUTHURES A. <ala...@ag...> - 2010-01-29 17:33:46
|
Leigh, > I still believe the <submssion method="get" replace="all"> could easily use > the same technique as the XSTLForms feature <submssion > method="xml-urlencoded-post"> and use the underlying HTML4 form > implementation for the GET instead of using XHR. > > This seems like a small amount of work, and would fix the main use case immediately. > Don't you think that <submission method="get" replace="all">, with no instance data to submit, has no meaning itself and that <load> should be used instead ? -Alain |
|
From: Klotz, L. <Lei...@xe...> - 2010-01-29 17:27:41
|
Alain,
-----Original Message-----
From: COUTHURES Alain [mailto:ala...@ag...]
Sent: Friday, January 29, 2010 9:16 AM
To: Klotz, Leigh
Cc: Thorsten Roggendorf; xsl...@li...
Subject: Re: [Xsltforms-support] Problem with replace all
Hello,
>
> I think this is an XSLTForms limitation of submission
> replace='all', but of course Alain would have to answer that.
>
The required instructions to interpret an XSLT
processing-instruction (such as the one for applying xsltforms.xsl
!) in the return of the submission are not yet implemented.
I still believe the <submssion method="get" replace="all"> could easily use
the same technique as the XSTLForms feature <submssion
method="xml-urlencoded-post"> and use the underlying HTML4 form
implementation for the GET instead of using XHR.
This seems like a small amount of work, and would fix the main use case immediately.
> I believe the problem is because replace='all' uses XHR, even when method='get'.
XmlHttpRequest is the only way to manage errors, if any, from the
initial XForms document.
I believe that having the success case of replace='all' work according to
spec is more important than having the failure case work.
Also, XForms 1.1 Test 11.4.9.b was recently changed to use replace='none' instead of
replace='all' because it seems likely that xforms-submit-error
handling is not possible in the replace='all' case in many processors, not just
Ubiquity and XSLTForms.
See http://lists.w3.org/Archives/Public/public-forms/2009Dec/0074.html
for discussion.
> You can use an XSLTForms-only hack for POST, by doing
> method="xml-urlencoded-post". In this case, XSLTForms creates
> an HTML4 form and serializes the XML into a single HTML4 field
> named "postdata." The disadvantge is that you must alter
> server-side code to look for a URL Encoded POST containing a
> parameter "postdata" and then extract that and parsing it as
> XML.
This hack was easy to implement. It guarantees that the browser
knows it is a completely new page so memory leak should be under
control. But there is no error management...
By the way, at server-side, it is not necessary to check if the
parameter is named "postdata" or anything else...
> Personally, I think that XSLTForms could similarly implement submission method='get'
> when replace='all' by creating an HTML form element, and there would be no compensation
> needed and your example below would work.
I consider that xf:load is better for that usage.
> Perhaps Alain has already explored this and found it unworkable for
> some reason, or perhaps it is just work that needs doing (and maybe
> you could help?)
>
There is still plenty of work that needs doing in XSLTForms !
Thanks!
-Alain
Leigh.
|
|
From: COUTHURES A. <ala...@ag...> - 2010-01-29 17:15:35
|
Hello, > I think this is an XSLTForms limitation of submission replace='all', but of course Alain would have to answer that. > The required instructions to interpret an XSLT processing-instruction (such as the one for applying xsltforms.xsl !) in the return of the submission are not yet implemented. > I believe the problem is because replace='all' uses XHR, even when method='get'. > XmlHttpRequest is the only way to manage errors, if any, from the initial XForms document. > You can use an XSLTForms-only hack for POST, by doing method="xml-urlencoded-post". In this case, XSLTForms creates an HTML4 form and serializes the XML into a single HTML4 field named "postdata." The disadvantge is that you must alter server-side code to look for a URL Encoded POST containing a parameter "postdata" and then extract that and parsing it as XML. This hack was easy to implement. It guarantees that the browser knows it is a completely new page so memory leak should be under control. But there is no error management... By the way, at server-side, it is not necessary to check if the parameter is named "postdata" or anything else... > > > Personally, I think that XSLTForms could similarly implement submission method='get' when replace='all' by creating an HTML form element, and there would be no compensation needed and your example below would work. I consider that xf:load is better for that usage. > Perhaps Alain has already explored this and found it unworkable for some reason, or perhaps it is just work that needs doing (and maybe you could help?) > There is still plenty of work that needs doing in XSLTForms ! Thanks! -Alain |
|
From: Klotz, L. <Lei...@xe...> - 2010-01-29 17:15:09
|
select1 with appearance="minimal" and selection="open" could be nicely implemented with a type-in box and drop-down suggestions done in JS. ________________________________ From: COUTHURES Alain [mailto:ala...@ag...] Sent: Friday, January 29, 2010 9:04 AM To: Javier Díaz Cc: XSLTForms support Subject: Re: [Xsltforms-support] ¿Is Open selection available in xsltforms? Hello Javier, I was reading xforms 1.1 specification and I saw that select and select1 can support "open selections" that is, apart from the list of choices you put, user can fill his own option: selection Author-optional attribute determining whether free entry is allowed in the list. Default is "closed". I tried to use it in xsltforms, but I didn't manage to create it. Is available this option in xsltforms? Sorry this option is not yet implemented. XSLTForms current version is based on HTML controls only and this option has no HTML equivalent. Adding this will mean to have an identical rendering for select controls because they will have to be composed by more than one HTML control. Do you need it for one of your projects ? Thanks! -Alain |
|
From: COUTHURES A. <ala...@ag...> - 2010-01-29 17:03:46
|
Hello Javier, > I was reading xforms 1.1 specification and I saw that select and > select1 can support "open selections" that is, apart from the list of > choices you put, user can fill his own option: > > selection > > Author-optional attribute determining whether free entry is > allowed in the list. Default is "closed". > > > I tried to use it in xsltforms, but I didn't manage to create it. Is > available this option in xsltforms? Sorry this option is not yet implemented. XSLTForms current version is based on HTML controls only and this option has no HTML equivalent. Adding this will mean to have an identical rendering for select controls because they will have to be composed by more than one HTML control. Do you need it for one of your projects ? Thanks! -Alain |
|
From: Thorsten R. <ju...@sc...> - 2010-01-28 19:45:22
|
Hi Leigh
Thanks for the response. I'm new to xForms so I was not sure whether it
was my fault. Note that I originally observed the problem in a post
request/response. I made it a get so that it is more easily
reproducible.
Also thanks for the workaround suggestion. However, I'll first try to
split up the page and store the required data in a user session between
calls. If it works, the solution will be generic (instead of
xsltforms-specific). And finally my apologies, but I have no time to
help with fixing that (and I hardly know XSLT). I could only give up my
own project in order to help you.
Regards
Thorsten
Am Donnerstag, den 28.01.2010, 09:27 -0800 schrieb Klotz, Leigh:
> I think this is an XSLTForms limitation of submission replace='all',
> but of course Alain would have to answer that. I believe the problem
> is because replace='all' uses XHR, even when method='get'.
>
> You can use an XSLTForms-only hack for POST, by doing
> method="xml-urlencoded-post". In this case, XSLTForms creates an
> HTML4 form and serializes the XML into a single HTML4 field named
> "postdata." The disadvantge is that you must alter server-side code
> to look for a URL Encoded POST containing a parameter "postdata" and
> then extract that and parsing it as XML.
>
> Personally, I think that XSLTForms could similarly implement submission
> method='get' when replace='all' by creating an HTML form element, and
> there would be no compensation needed and your example below would
> work. Perhaps Alain has already explored this and found it unworkable
> for some reason, or perhaps it is just work that needs doing (and
> maybe you could help?)
>
> Leigh.
>
> -----Original Message-----
> From: Thorsten Roggendorf [mailto:t...@sc...]
> Sent: Wednesday, January 27, 2010 2:58 PM
> To: xsl...@li...
> Subject: [Xsltforms-support] Problem with replace all
>
> Hi
>
> I'm trying to write my first XRX app and cannot get a form to work
> where I replace one xform with another. While the whole thing is
> starting to get complicated with modules and all, I think I have
> isolated the problem in a simple example. I wrote two straightforward
> xhtml files step1.xhtml and step2.xhtml. If they are loaded separately
> (and explicitly) both work. But if step2 is loaded by submitting step1
> it does not work.
>
> I observed the problem in firefox 3.5.7. Pages are served by eXist
> 1.4.0rc-rev10028-20090908 on the localhost (ubuntu karmic koala).
>
> I'll attach the xhtml fies and past it as well in case attachments are filtered out:
>
> step1: <?xml-stylesheet href="xsltforms/xsltforms.xsl"
> type="text/xsl"?> <?xsltforms-options debug="yes"?> <html
> xmlns="http://www.w3.org/1999/xhtml"
> xmlns:ev="http://www.w3.org/2001/xml-events"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:xf="http://www.w3.org/2002/xforms"> <head> <title>Edit
> Person</title> <xf:model> <xf:instance>
> <person> <FAMILY/>
> </person> </xf:instance>
> <xf:submission id="submit" method="get" action="step2.xhtml"
> replace="all" /> </xf:model> </head> <body> <xf:input
> ref="FAMILY"> <xf:label>Family:</xf:label> </xf:input>
> <xf:submit submission="submit">
> <xf:label>Next</xf:label> </xf:submit> </body> </html>
>
> step2: <?xml-stylesheet href="xsltforms/xsltforms.xsl"
> type="text/xsl"?> <?xsltforms-options debug="yes"?> <html
> xmlns="http://www.w3.org/1999/xhtml"
> xmlns:ev="http://www.w3.org/2001/xml-events"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:xf="http://www.w3.org/2002/xforms">
> <head> <title>Edit
> Person</title> <xf:model> <xf:instance>
> <person> <FAMILY/>
> </person> </xf:instance> </xf:model>
> </head> <body> <xf:input ref="FAMILY">
> <xf:label>Family:</xf:label> </xf:input> </body> </html>
>
> Regards
> Thorsten
|
|
From: Klotz, L. <Lei...@xe...> - 2010-01-28 17:32:03
|
It might be worth investigating an alternate approach to this kind of performance enhancenement. For example, Google has an automated tool called Closure (bad name in my opinion): http://code.google.com/closure/ Using this tool means making some declarations about what names are global, though, and I think it would take some familiarity with XSLTForms to do that. By the way, XSLTForms doesn't "play nice" with some other JavaScript libraries because of its use of generic terms for globals ("Calendar", "Event", etc.) Maybe developing the config for Closure would help clarify that issue at the same time. Leigh. ________________________________ From: Tambet Matiisen [mailto:tam...@gm...] Sent: Wednesday, January 27, 2010 11:55 PM To: Klotz, Leigh Cc: xsl...@li... Subject: Re: [Xsltforms-support] xsltforms Performance I just did a few tests with my case. function selectAll(form, regexp, checked) { var elements = form.elements; var elements_length = elements.length; for(var i = 0; i < elements_length; i++) { var element = elements[i]; if (element.type == 'checkbox' && element.name.search(regexp) != -1) { element.checked = checked; } } } I had a form with 200 checkboxes. for(var i = 0; i < elements_length; i++) - took ~1s to check all for(var i = 0; i < elements.length; i++) - took ~2s to check all for(var i = 0; i < form.elements.length; i++) - took ~3s to check all It seems that accessing properties (maybe only form.elements?) is slow in IE(8). All cases worked almost instantaneously in FF(3.5). Tambet Klotz, Leigh wrote: I tried this just now; it was tedious but doable. I didn't bother for strings. Some loops affect the list length and need to be left alone. I didn't get it 100% right and get the occasional JS error; care must be taken! I tried a sample application and didn't see a measureable clock-time performance improvement in IE8. There are some areas where performance is poor compared to other FF3.6 (four seconds vs instantaneous) but this didn't fix it I'm willing to believe that this fixes problems I just didn't happen encounter, but it doesn't fix one I did encounter. Leigh. ________________________________ From: Tambet Matiisen [mailto:tam...@gm...] Sent: Wednesday, January 27, 2010 12:30 AM To: xsl...@li... Subject: Re: [Xsltforms-support] xsltforms Performance Christopher Dedels wrote: 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. I've noticed, that IE calculates .length property of arrays by counting all array elements. This makes such cycles especially slow: for (var i = 0; i < frm.elements.length; i++) This can be easily fixed by assigning length to a variable: var elements_length = frm.elements.length; for (var i = 0; i < elements_length; i++) You could search XSLTForms javascript code for ".length" and try if this fix makes it better. Tambet |
|
From: Klotz, L. <Lei...@xe...> - 2010-01-28 17:28:23
|
I think this is an XSLTForms limitation of submission replace='all', but of course Alain would have to answer that. I believe the problem is because replace='all' uses XHR, even when method='get'. You can use an XSLTForms-only hack for POST, by doing method="xml-urlencoded-post". In this case, XSLTForms creates an HTML4 form and serializes the XML into a single HTML4 field named "postdata." The disadvantge is that you must alter server-side code to look for a URL Encoded POST containing a parameter "postdata" and then extract that and parsing it as XML. Personally, I think that XSLTForms could similarly implement submission method='get' when replace='all' by creating an HTML form element, and there would be no compensation needed and your example below would work. Perhaps Alain has already explored this and found it unworkable for some reason, or perhaps it is just work that needs doing (and maybe you could help?) Leigh. -----Original Message----- From: Thorsten Roggendorf [mailto:t...@sc...] Sent: Wednesday, January 27, 2010 2:58 PM To: xsl...@li... Subject: [Xsltforms-support] Problem with replace all Hi I'm trying to write my first XRX app and cannot get a form to work where I replace one xform with another. While the whole thing is starting to get complicated with modules and all, I think I have isolated the problem in a simple example. I wrote two straightforward xhtml files step1.xhtml and step2.xhtml. If they are loaded separately (and explicitly) both work. But if step2 is loaded by submitting step1 it does not work. I observed the problem in firefox 3.5.7. Pages are served by eXist 1.4.0rc-rev10028-20090908 on the localhost (ubuntu karmic koala). I'll attach the xhtml fies and past it as well in case attachments are filtered out: step1: <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?> <?xsltforms-options debug="yes"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xf="http://www.w3.org/2002/xforms"> <head> <title>Edit Person</title> <xf:model> <xf:instance> <person> <FAMILY/> </person> </xf:instance> <xf:submission id="submit" method="get" action="step2.xhtml" replace="all" /> </xf:model> </head> <body> <xf:input ref="FAMILY"> <xf:label>Family:</xf:label> </xf:input> <xf:submit submission="submit"> <xf:label>Next</xf:label> </xf:submit> </body> </html> step2: <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?> <?xsltforms-options debug="yes"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xf="http://www.w3.org/2002/xforms"> <head> <title>Edit Person</title> <xf:model> <xf:instance> <person> <FAMILY/> </person> </xf:instance> </xf:model> </head> <body> <xf:input ref="FAMILY"> <xf:label>Family:</xf:label> </xf:input> </body> </html> Regards Thorsten |
|
From: Tambet M. <tam...@gm...> - 2010-01-28 07:55:10
|
I just did a few tests with my case.
function selectAll(form, regexp, checked)
{
var elements = form.elements;
var elements_length = elements.length;
for(var i = 0; i < elements_length; i++)
{
var element = elements[i];
if (element.type == 'checkbox' && element.name.search(regexp) != -1)
{
element.checked = checked;
}
}
}
I had a form with 200 checkboxes.
for(var i = 0; i < elements_length; i++) - took ~1s to check all
for(var i = 0; i < elements.length; i++) - took ~2s to check all
for(var i = 0; i < form.elements.length; i++) - took ~3s to check all
It seems that accessing properties (maybe only form.elements?) is slow
in IE(8). All cases worked almost instantaneously in FF(3.5).
Tambet
Klotz, Leigh wrote:
> I tried this just now; it was tedious but doable. I didn't bother for
> strings. Some loops affect the list length and need to be left alone.
> I didn't get it 100% right and get the occasional JS error; care must
> be taken!
>
> I tried a sample application and didn't see a measureable clock-time
> performance improvement in IE8.
> There are some areas where performance is poor compared to other FF3.6
> (four seconds vs instantaneous) but this didn't fix it
>
> I'm willing to believe that this fixes problems I just didn't happen
> encounter, but it doesn't fix one I did encounter.
>
> Leigh.
>
> ------------------------------------------------------------------------
> *From:* Tambet Matiisen [mailto:tam...@gm...]
> *Sent:* Wednesday, January 27, 2010 12:30 AM
> *To:* xsl...@li...
> *Subject:* Re: [Xsltforms-support] xsltforms Performance
>
> Christopher Dedels wrote:
>>
>> 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.
>>
>
> I've noticed, that IE calculates .length property of arrays by
> counting all array elements. This makes such cycles especially slow:
>
> for (var i = 0; i < frm.elements.length; i++)
>
> This can be easily fixed by assigning length to a variable:
>
> var elements_length = frm.elements.length;
> for (var i = 0; i < elements_length; i++)
>
> You could search XSLTForms javascript code for ".length" and try if
> this fix makes it better.
>
> Tambet
|
|
From: Thorsten R. <t...@sc...> - 2010-01-27 23:31:52
|
Hi I'm trying to write my first XRX app and cannot get a form to work where I replace one xform with another. While the whole thing is starting to get complicated with modules and all, I think I have isolated the problem in a simple example. I wrote two straightforward xhtml files step1.xhtml and step2.xhtml. If they are loaded separately (and explicitly) both work. But if step2 is loaded by submitting step1 it does not work. I observed the problem in firefox 3.5.7. Pages are served by eXist 1.4.0rc-rev10028-20090908 on the localhost (ubuntu karmic koala). I'll attach the xhtml fies and past it as well in case attachments are filtered out: step1: <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?> <?xsltforms-options debug="yes"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xf="http://www.w3.org/2002/xforms"> <head> <title>Edit Person</title> <xf:model> <xf:instance> <person> <FAMILY/> </person> </xf:instance> <xf:submission id="submit" method="get" action="step2.xhtml" replace="all" /> </xf:model> </head> <body> <xf:input ref="FAMILY"> <xf:label>Family:</xf:label> </xf:input> <xf:submit submission="submit"> <xf:label>Next</xf:label> </xf:submit> </body> </html> step2: <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?> <?xsltforms-options debug="yes"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xf="http://www.w3.org/2002/xforms"> <head> <title>Edit Person</title> <xf:model> <xf:instance> <person> <FAMILY/> </person> </xf:instance> </xf:model> </head> <body> <xf:input ref="FAMILY"> <xf:label>Family:</xf:label> </xf:input> </body> </html> Regards Thorsten |
|
From: Klotz, L. <Lei...@xe...> - 2010-01-27 22:38:54
|
I tried this just now; it was tedious but doable. I didn't bother for strings. Some loops affect the list length and need to be left alone. I didn't get it 100% right and get the occasional JS error; care must be taken! I tried a sample application and didn't see a measureable clock-time performance improvement in IE8. There are some areas where performance is poor compared to other FF3.6 (four seconds vs instantaneous) but this didn't fix it I'm willing to believe that this fixes problems I just didn't happen encounter, but it doesn't fix one I did encounter. Leigh. ________________________________ From: Tambet Matiisen [mailto:tam...@gm...] Sent: Wednesday, January 27, 2010 12:30 AM To: xsl...@li... Subject: Re: [Xsltforms-support] xsltforms Performance Christopher Dedels wrote: 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. I've noticed, that IE calculates .length property of arrays by counting all array elements. This makes such cycles especially slow: for (var i = 0; i < frm.elements.length; i++) This can be easily fixed by assigning length to a variable: var elements_length = frm.elements.length; for (var i = 0; i < elements_length; i++) You could search XSLTForms javascript code for ".length" and try if this fix makes it better. Tambet |
|
From: Tambet M. <tam...@gm...> - 2010-01-27 08:30:28
|
Christopher Dedels wrote: > > 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. > > > I've noticed, that IE calculates .length property of arrays by counting all array elements. This makes such cycles especially slow: for (var i = 0; i < frm.elements.length; i++) This can be easily fixed by assigning length to a variable: var elements_length = frm.elements.length; for (var i = 0; i < elements_length; i++) You could search XSLTForms javascript code for ".length" and try if this fix makes it better. Tambet |
|
From: Christopher D. <cd...@vi...> - 2010-01-26 16:13:08
|
I have found a partial workaround for the time being. I was able to significantly improve the performance in IE6/8 by reducing the number of elements and attributes in the instance data. The net effect was that my documents now load in about 4 seconds. This is not an ideal situation as the number of data elements in my repeat structures grow, I will be back where I started. Alain, were you able to get anything from the documents I sent you? Thanks From: COUTHURES Alain [mailto:ala...@ag...] Sent: Saturday, January 23, 2010 11:16 AM To: Christopher Dedels Cc: xsl...@li... Subject: Re: [Xsltforms-support] xsltforms Performance 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 |
|
From: COUTHURES A. <ala...@ag...> - 2010-01-25 20:19:07
|
Hi Leigh, > If I do this: > > <repeat nodeset="*"> > <output ref="local-name(.)" /> > </repeat> > > With an instance that looks like this: > <data> > <foo /> > <foo /> > <foo /> > ... > </data> > > I get this type of output: > > foo > #text > foo > #text > foo > #text > foo > #text > > However, XPath 1.0 says http://www.w3.org/TR/xpath/#path-abbrev > > * selects all element children of the context node > This was a bug in the XSLT part. The fix has been committed. Thanks! -Alain |
|
From: Klotz, L. <Lei...@xe...> - 2010-01-25 17:11:01
|
If I do this:
<repeat nodeset="*">
<output ref="local-name(.)" />
</repeat>
With an instance that looks like this:
<data>
<foo />
<foo />
<foo />
...
</data>
I get this type of output:
foo
#text
foo
#text
foo
#text
foo
#text
However, XPath 1.0 says http://www.w3.org/TR/xpath/#path-abbrev
* selects all element children of the context node
Leigh.
|
|
From: Klotz, L. <Lei...@xe...> - 2010-01-25 16:45:42
|
I think you want xf:select/itemset/copy instead of xf:select1/itemset/value. I'm not sure that XSLTForms implements it, though. Check your copy of Micah Dubinko's XForms book p. 101 (or search Google Books copy for "xforms select copy"). You might also be able to coook something up by imitating select with a switch and using insert and delete. For how to use insert and delete (XForms 1.1 version) see http://www.w3.org/TR/xforms11/#data-mutation-patterns XForms 1.1 defines select/itemset/copy in terms of insert and delete, and XForms 1.2 is proposed to add a merged version of select and switch, so it wouldn't be that far off. Leigh. -----Original Message----- From: Stephen Cameron [mailto:Ste...@ut...] Sent: Sunday, January 24, 2010 3:42 AM To: xsl...@li... Subject: [Xsltforms-support] select1 behaviour 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 ------------------------------------------------------------------------------ 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 |
|
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: > <D8849DD31EB6CB4A8F2AA3F2F1B004960618359126@MAIL01.Virtify.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 > ************************************************ > |
|
From: Tambet M. <tam...@gm...> - 2010-01-25 08:48:06
|
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 |
|
From: Stephen C. <Ste...@ut...> - 2010-01-24 11:42:19
|
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 |
|
From: COUTHURES A. <ala...@ag...> - 2010-01-23 16:16:03
|
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 |
|
From: Christopher D. <cd...@vi...> - 2010-01-23 15:09:26
|
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 |
|
From: Micah D. <Mic...@ma...> - 2010-01-23 02:09:37
|
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 |
|
From: Sandra B. <sb...@lo...> - 2010-01-22 16:13:16
|
Alain,
I'm using the version of XSLTforms that comes with eXist in their 1.4 download. I don't have an external link because I was trying to put together a desktop form but I'll try to email it to you directly. I've also added Firebug. Thank you for the tips.
Sandy
>>> COUTHURES Alain <ala...@ag...> 1/21/2010 4:22:42 PM >>>
Sandy,
xf:resource is well supported in SVN build version (bugs have been fixed
about relative path support): is it the version you're using ?
Activating the debug mode (by <options><debug/></options> in config.xsl
in latest versions) can help you to see the effective uri for submission.
I usually use a browser debugger (such as FireBug) to locate in
Javascript instructions where the problem is (in XFSubmission class). Do
you have an external link to allow me to diagnose it ?
Thanks!
-Alain
> I'm trying to save my instance data into an XML file in Exist using the identifier field as filled out in the form. It works if I hard code the file name but if I try to use xf:resource to generate the file name, the form just gets stuck after I submit. I'd appreciate any suggestions. I'm new to this and not really a programmer so apologies if this is obvious.
>
> Thanks,
> Sandy
>
> hard coded:
> <!-- Saves the data to a file-->
> <xf:submission id="save-to-file" method="put" action="../webdav/db/nlu_test/test2.xml" replace="instance">
> <xf:toggle case="case-busy" ev:event="xforms-submit"/>
> <xf:toggle case="case-submit-done" ev:event="xforms-submit-done"/>
> <xf:toggle case="case-submit-error" ev:event="xforms-submit-error"/>
> </xf:submission>
>
> not hard coded:
> <!-- Saves the data to a file-->
> <xf:submission id="save-to-file" method="put" replace="instance">
> <xf:resource value="concat('http://localhost:8080/exist/webdav/db/nlu_test/', instance('mods-data')/identifier,'.xml')"/>
> <xf:toggle case="case-busy" ev:event="xforms-submit"/>
> <xf:toggle case="case-submit-done" ev:event="xforms-submit-done"/>
> <xf:toggle case="case-submit-error" ev:event="xforms-submit-error"/>
> </xf:submission>
>
> control in body:
> <!--Save to a File-->
> <xf:submit class="store" submission="save-to-file">
> <xf:label>Save</xf:label>
> <xf:action ev:event="DOMActivate">
> <xf:setvalue ref="instance('mods-data')/recordInfo/recordChangeDate" value="now()"/>
> </xf:action>
> </xf:submit>
>
> Sandy Bostian
> Content Manager, World Digital Library
> Library of Congress
> 101 Independence Ave., SE
> Washington, DC 20540
> 202.707.2342
> sb...@lo...
>
|
97 messages has been excluded from this view by a project administrator.