xsltforms-support Mailing List for XSLTForms (Page 19)
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
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alain C. <ala...@ag...> - 2015-11-18 20:58:03
|
Tim, Currently, fn:tokenize() is returning faked text nodes. This is good enough for xf:output and should also work with xf:setvalue. It would still be easy to create standalone text nodes owned by default instance to do the trick more appropriately for complex cases. Could you please send me a test case? Thanks! --Alain Le 18/11/2015 20:02, Tim Thompson a écrit : > Alain, > > Can fn:tokenize be used to update instance data with xf:input, or only > to display data with xf:output? I have XML data with elements that > contain semicolon-delimited strings that I would like to split across > separate input controls, but I guess the data can't be updated once it > is tokenized? > > Best wishes, > Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: Tim T. <tim...@gm...> - 2015-11-18 19:03:12
|
Alain, Can fn:tokenize be used to update instance data with xf:input, or only to display data with xf:output? I have XML data with elements that contain semicolon-delimited strings that I would like to split across separate input controls, but I guess the data can't be updated once it is tokenized? Best wishes, Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library |
|
From: Ioan F. <mi...@gm...> - 2015-11-16 16:33:15
|
Many thanks, Alain! It's perfect, for output works like in XQuery. I usually use mixed configurations, but for Romanian localization of the new properties I can propose the following: <format-number.decimal-separator-sign>,</format-number.decimal-separator-sign> <format-number.exponent-separator-sign>e</format-number.exponent-separator-sign> <format-number.grouping-separator-sign>.</format-number.grouping-separator-sign> <format-number.infinity>Infinit</format-number.infinity> <format-number.minus-sign>-</format-number.minus-sign> <format-number.NaN>Nenumeric</format-number.NaN> <format-number.percent-sign>%</format-number.percent-sign> <format-number.per-mille-sign>‰</format-number.per-mille-sign> I now address (if I see that it can!) an another question, related to calendar, for the fields of type xsd: dateTime. It may be possible to configure the time, for example, to not display seconds, or to shown the minutes only from 10 to 10 or from 15 to 15? All the best! Ioan On 11/15/2015 10:45 PM, Alain Couthures wrote: > Hi Ioan, > > The format-number() function is now supported in XPath expressions. > This has been committed in source repositories. > > It can be used with 2 parameters only and signs to be used in picture > are the ones for English: "." as decimal separator and so on. This > way, pictures don't have to be rewritten for applications with > multi-language support. > > New properties are now supported in config.xsl files to allow specific > separators for a language. For example, for French: > > <format-number.decimal-separator-sign>,</format-number.decimal-separator-sign> > > <format-number.exponent-separator-sign>.10^</format-number.exponent-separator-sign> > > <format-number.grouping-separator-sign> > </format-number.grouping-separator-sign> > <format-number.infinity>Infini</format-number.infinity> > <format-number.minus-sign>-</format-number.minus-sign> > <format-number.NaN>Non numérique</format-number.NaN> > <format-number.percent-sign>%</format-number.percent-sign> > <format-number.per-mille-sign>‰</format-number.per-mille-sign> > > Please send me corresponding values for your country. > > Thank you for your feedback! > > --Alain > |
|
From: Alain C. <ala...@ag...> - 2015-11-15 20:45:24
|
Hi Ioan,
The format-number() function is now supported in XPath expressions. This
has been committed in source repositories.
It can be used with 2 parameters only and signs to be used in picture
are the ones for English: "." as decimal separator and so on. This way,
pictures don't have to be rewritten for applications with multi-language
support.
New properties are now supported in config.xsl files to allow specific
separators for a language. For example, for French:
<format-number.decimal-separator-sign>,</format-number.decimal-separator-sign>
<format-number.exponent-separator-sign>.10^</format-number.exponent-separator-sign>
<format-number.grouping-separator-sign>
</format-number.grouping-separator-sign>
<format-number.infinity>Infini</format-number.infinity>
<format-number.minus-sign>-</format-number.minus-sign>
<format-number.NaN>Non numérique</format-number.NaN>
<format-number.percent-sign>%</format-number.percent-sign>
<format-number.per-mille-sign>‰</format-number.per-mille-sign>
Please send me corresponding values for your country.
Thank you for your feedback!
--Alain
Le 08/11/2015 21:33, Alain Couthures a écrit :
> Hi Ioan,
>
> What do you mean by "displayed"? Could you please send a form as an example?
>
> From my point of view, formatting is to be consider for input controls
> and there should be a way to convert the effective value into the one to
> be edited and the way back. A solution would be a consider a sort of
> shadow DOM where hidden extra nodes are added for processing. Is it what
> you are looking for?
>
> Thanks!
>
> Alain
>
> Le 08/11/2015 20:14, Ioan Fericel a écrit :
>> Hi,
>>
>> A topic that has been discussed a while ago: What solution could be
>> found to show a number like 7.50 to be displayed 0 at the end? Outside
>> of xsltforms or included in it.
>>
>> It may now be more easily integrated into xsltforms?
>>
>> Thanks,
>> Ioan
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
|
|
From: Alain C. <ala...@ag...> - 2015-11-08 20:33:42
|
Hi Ioan, What do you mean by "displayed"? Could you please send a form as an example? From my point of view, formatting is to be consider for input controls and there should be a way to convert the effective value into the one to be edited and the way back. A solution would be a consider a sort of shadow DOM where hidden extra nodes are added for processing. Is it what you are looking for? Thanks! Alain Le 08/11/2015 20:14, Ioan Fericel a écrit : > Hi, > > A topic that has been discussed a while ago: What solution could be > found to show a number like 7.50 to be displayed 0 at the end? Outside > of xsltforms or included in it. > > It may now be more easily integrated into xsltforms? > > Thanks, > Ioan > > ------------------------------------------------------------------------------ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > |
|
From: Ioan F. <mi...@gm...> - 2015-11-08 19:14:58
|
Hi, A topic that has been discussed a while ago: What solution could be found to show a number like 7.50 to be displayed 0 at the end? Outside of xsltforms or included in it. It may now be more easily integrated into xsltforms? Thanks, Ioan |
|
From: Alain C. <ala...@ag...> - 2015-11-08 18:25:05
|
Tim, Thank you very much for pointing at this issue. This is now fixed in the latest commit. Alain Le 28/10/2015 00:45, Tim Thompson a écrit : > The issue seems to relate to the "pending" property in the > xf:submission component. If the value on line 141 > (XFSubmission.js.xml) is changed to false, the dynamic behavior on > JSONP calls is restored[1]. How is the "pending" property being used here? > > All best, > Tim > > [1] > https://github.com/AlainCouthures/xsltforms/blob/master/src/js/coreelts/XFSubmission.js.xml#L141 > > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > On Tue, Oct 27, 2015 at 12:43 PM, Tim Thompson <tim...@gm...> wrote: > > Alain, > > I have been looking at JSONP submissions in XSLTForms (following > the Wikipedia OpenSearch example). In recent versions, the > incremental search functionality appears to be broken. I traced > this back to XSLTForms rev. 613. In all versions since then, the > JSONP search seems to execute only once and does not respond to > "xforms-value-changed" events. > > Best regards, > Tim > > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: Henri M. <hfm...@gm...> - 2015-11-01 23:00:19
|
Dear Alain, I will attend XForms Day and would like to discuss some ideas with you about your XSLTForms project. I've created a webpage about this: http://mansoft.nl/xmlamsterdam/ Can you have a look at it before 5 november? Kind regards, Henri Manson On Sun, Oct 25, 2015 at 2:47 PM, Alain Couthures < ala...@ag...> wrote: > Hello, > > I am very happy to announce the XForms Day, 5th November, in Amsterdam: > http://www.xmlamsterdam.com/2015/pre-conference > > Please join us and have the opportunity to meet specifiers, implementers > and users. > > Specifically about XSLTForms, I would like to discuss with you about > version 2 and your feedbacks for version 1 can also be very useful. > > Thanks! > > Alain > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > |
|
From: Tim T. <tim...@gm...> - 2015-10-27 23:46:01
|
The issue seems to relate to the "pending" property in the xf:submission component. If the value on line 141 (XFSubmission.js.xml) is changed to false, the dynamic behavior on JSONP calls is restored[1]. How is the "pending" property being used here? All best, Tim [1] https://github.com/AlainCouthures/xsltforms/blob/master/src/js/coreelts/XFSubmission.js.xml#L141 -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library On Tue, Oct 27, 2015 at 12:43 PM, Tim Thompson <tim...@gm...> wrote: > Alain, > > I have been looking at JSONP submissions in XSLTForms (following the > Wikipedia OpenSearch example). In recent versions, the incremental search > functionality appears to be broken. I traced this back to XSLTForms rev. > 613. In all versions since then, the JSONP search seems to execute only > once and does not respond to "xforms-value-changed" events. > > Best regards, > Tim > > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > <ta...@pr...> > |
|
From: Tim T. <tim...@gm...> - 2015-10-27 16:44:15
|
Alain, I have been looking at JSONP submissions in XSLTForms (following the Wikipedia OpenSearch example). In recent versions, the incremental search functionality appears to be broken. I traced this back to XSLTForms rev. 613. In all versions since then, the JSONP search seems to execute only once and does not respond to "xforms-value-changed" events. Best regards, Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library <ta...@pr...> |
|
From: Tim T. <tim...@gm...> - 2015-10-27 16:33:53
|
Alain, Thank you for sharing this invitation. It's exciting to hear that version 2 is in the works! For those of us who won't be able to attend XML Amsterdam, it would be interesting to learn more about where XSLTForms is headed and perhaps contribute feedback. Do you know whether the XForms Day sessions will be recorded? Best wishes, Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library <ta...@pr...> On Sun, Oct 25, 2015 at 9:47 AM, Alain Couthures < ala...@ag...> wrote: > Hello, > > I am very happy to announce the XForms Day, 5th November, in Amsterdam: > http://www.xmlamsterdam.com/2015/pre-conference > > Please join us and have the opportunity to meet specifiers, implementers > and users. > > Specifically about XSLTForms, I would like to discuss with you about > version 2 and your feedbacks for version 1 can also be very useful. > > Thanks! > > Alain > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > |
|
From: Alain C. <ala...@ag...> - 2015-10-25 14:00:15
|
Hello, I am very happy to announce the XForms Day, 5th November, in Amsterdam: http://www.xmlamsterdam.com/2015/pre-conference Please join us and have the opportunity to meet specifiers, implementers and users. Specifically about XSLTForms, I would like to discuss with you about version 2 and your feedbacks for version 1 can also be very useful. Thanks! Alain |
|
From: Alain C. <ala...@ag...> - 2015-10-08 17:18:44
|
Hi Tim,
Sorry for the inconvenience. This has been fixed in rev.624.
Best regards,
Alain
Le 08/10/2015 02:47, Tim Thompson a écrit :
> Hi, Alain,
>
> Thank you for the recent XSLTForms updates!
>
> However, the Firefox workaround in rev. 623 seems to break the
> Profiler/Debugger. In Firefox 40 (Ubuntu and Mac), I get the following
> error when trying to open the debugger or view an instance:
>
>
> XSLTForms Exception
> --------------------------
>
> Error evaluating the following XPath expression :
>
> serialize(instance('view'),'yes')
>
> ReferenceError
>
> Fleur is not defined
>
>
> Best regards,
>
> Tim
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
|
|
From: Tim T. <tim...@gm...> - 2015-10-08 00:48:23
|
Hi, Alain,
Thank you for the recent XSLTForms updates!
However, the Firefox workaround in rev. 623 seems to break the
Profiler/Debugger. In Firefox 40 (Ubuntu and Mac), I get the following
error when trying to open the debugger or view an instance:
XSLTForms Exception
--------------------------
Error evaluating the following XPath expression :
serialize(instance('view'),'yes')
ReferenceError
Fleur is not defined
Best regards,
Tim
--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library
|
|
From: Mats E. <mat...@li...> - 2015-09-21 09:09:21
|
Hi Alain, Somewhat related to my previous question how best leverage HTML 5 Web Workers for async processing in XForms/XsltForms, I now have a similar question, this time related to how best to leverage browsers' capability to allow downloading of resources client-side utilizing the HTML 5 @download attribute on the <a/> element combined with the URL.createObjectURL() method of the File API (http://www.w3.org/TR/FileAPI/#dfn-createObjectURL), and am interested to get your opinion on possible options of extending XsltForms. Obviously it is possible already now to leverage these features in XsltForms via the <xf:load resource="javascript:..."/> or <xf:script/> elements, but I'm thinking this functionality should rather be exposed through and encapsulated in a proper XForms extension element. I was first figuring around the following options: <xf:download ref/value=""/> as a control element, "mirroring" the <xf:upload/> control already part of the XForms specification<xf:download ref/value=""/> as an _action_ element, allowing it to be used in event handlers for the <xf:trigger/> element for example, similar to the <xf:load/> action element. (I'm wondering why the <xf:upload/> wasn't made an action element in XForms as well...?!) At the same time, other options also exist: A custom @appearance attribute on the <xf:output/> element (as in Orbeon Forms: http://wiki.orbeon.com/forms/doc/developer-guide/xforms-controls/output-control?pli=1#TOC-Appearance-xxforms:download)Extended behavior of the <xf:submission resource="file://" method="get/put".../> element... ... What are your thoughts here? Which option would make most sense in your view? Regards,Mats |
|
From: Mats E. <mat...@li...> - 2015-09-01 15:18:21
|
Btw, concerning how to pass the compiled xpath object to the web worker, I was considering the option of rebuilding the xpath object from its expression from within the worker, however, XsltForms' xpath parser is available only as an XSLT tranform, so I figured the serialization option was probably the path of less resistance...
/ Mats
On Tue, 1 Sep 2015 15:04:39 +0000, Mats wrote:
Hi Alain,
Sounds like an interesting idea. Probably not trivial though!
For the problem I have (long running calculations) I think it would still be necessary to be able to spawn off a dedicated thread (separate from the main execution thread) for performing the long running calculation (in order that the form is still responsive to other events), and a way to indicate that an action should be executed in a non-blocking manner is required I believe. While migrating all xpath evaluations to a (single) separate web worker might not solve the problem, the implementation of a feature for executing long running calculations in a separate worker thread would probably be simplified if the framework already dealt with web workers in some way or the other...
In any case, I am progressing with the implementation of the @mode=async attribute (working off your v595), which I hope shall work on xf:setvalue, xf:insert and maybe xf:setnode.
The approach I am taking involves serializing the XsltForms_xpath and XsltForms_exprContext objects (including relevant references), passing them to a new Worker thread, deserializing and evaluating the expressions there, then serializing the result, returning it to the caller thread and deserializing the result there to allow completion of the setvalue/insert/setnode action. All these steps happen inside a new method on the XsltForms_xpath object called xpath_evaluate_async() which must be called by the action instead of the normal xpath_evaluate(). The new method returns a Promise. (I am currently using a 3rd party serialization library... there is another library out there called vkThread which could also be interesting to look at). For time being, I am only considering evaluating the xpath expressions in the @value, @origin and @inner/@outer attributes in this manner. Binding expressions etc will be evaluated in the main thread as they are currently.
I realize that most likely my implementation will have some limitations (e.g. some xpath functions not supported since they have dependencies that might not be transferable, not all return types supported etc.) -- some which might be overcome with additional effort -- however I think most important use cases can be supported still with such limitations (e.g. calculating digests etc)...
I am interested to learn what you have in planning for a new XPath engine!? If the ability to evaluate expressions in web worker context is taken into account in the design, that would be great of course!
Welcome your feedback!
Mats
On Mon, 31 Aug 2015 21:18:53 +0200, Alain Couthures wrote:
Hi Mats,
The more I think about using a Web Worker for XSLTForms, the more
it sounds obvious that the right solution should be to dedicate a
Web Worker for storing/manipulating instances (XPath evaluations
and submissions): only node lists and values are to be present in
main thread actually!
First, this means that source code has to be adapted in a lot of
different locations.
Second, my Javascript XML DOM implementation is ready for
integration but my new XPath engine is not yet operational except
for very simple expressions...
What do you think of this different approach?
--Alain
Le 31/08/2015 07:25, Mats Eklund a écrit :Hi Alain,
Thanks for your feedback!
> XSLTForms supports
xf:setnode as an extension. So, with both
xf:setvalue and xf:setnode, at first glance, I
prefer a @mode="synchronous/asynchronous"
implementation (as in xf:submission).
One of the advantages I saw
with the xf:submission + proxied XMLHttpRequest option is
the submission-done notification event, which allows
chaining subsequent actions. I now realize however, that a
similar notification event is triggered by the xf:insert
action (xforms-insert), so if the @asynchronous attribute
could be applied on this action, the extension attribute
approach would probably be the more interesting option.
Furthermore, it looks like both xf:setvalue and xf:setnode
could be replaced by an xf:insert action if the XPath 3.0
functions fn:parse-xml() and fn:parse-xml-fragment() were
available in XLSTForms (for use in the xf:insert/@origin
attribute), in cases where the notification event is
important. This seems doable as well...
> I have not been working with Web Workers yet but I
read that there are limitations like these. XSLTForms
already has its own XPath engine but is currently using
native XML engines (an independent XML engine, fully
written in Javascript, is already in good progress!). Why
do you think that XSLT would also be required or is just
it that XSLT would be nice to have available too?
Concerning XSLTProcessor, large
XSLT transforms can be long running so it would be nice if
such could be run in a background thread. Furthermore, the
transform() xpath function is already part of the XSLTForms
core function library, and I'm thinking this entire library
should ideally be available also in the web worker context. I see there are some javascript
implementations of XSLTProcessors on the web (not sure if
Saxon CE is possible to use -- I'm trying to clarify).
By the way, which XML DOM level is required by XSLTForms'
XPath implementation for navigating on XForms instance
documents, do you know? So far it looks like the browsers'
native XML DOM Parser is not available in web worker
context...
/ Mats
------------------------------------------------------------------------------
_______________________________________________Xsltforms-support mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xsltforms-support
|
|
From: Mats E. <mat...@li...> - 2015-09-01 15:04:47
|
Hi Alain,
Sounds like an interesting idea. Probably not trivial though!
For the problem I have (long running calculations) I think it would still be necessary to be able to spawn off a dedicated thread (separate from the main execution thread) for performing the long running calculation (in order that the form is still responsive to other events), and a way to indicate that an action should be executed in a non-blocking manner is required I believe. While migrating all xpath evaluations to a (single) separate web worker might not solve the problem, the implementation of a feature for executing long running calculations in a separate worker thread would probably be simplified if the framework already dealt with web workers in some way or the other...
In any case, I am progressing with the implementation of the @mode=async attribute (working off your v595), which I hope shall work on xf:setvalue, xf:insert and maybe xf:setnode.
The approach I am taking involves serializing the XsltForms_xpath and XsltForms_exprContext objects (including relevant references), passing them to a new Worker thread, deserializing and evaluating the expressions there, then serializing the result, returning it to the caller thread and deserializing the result there to allow completion of the setvalue/insert/setnode action. All these steps happen inside a new method on the XsltForms_xpath object called xpath_evaluate_async() which must be called by the action instead of the normal xpath_evaluate(). The new method returns a Promise. (I am currently using a 3rd party serialization library... there is another library out there called vkThread which could also be interesting to look at). For time being, I am only considering evaluating the xpath expressions in the @value, @origin and @inner/@outer attributes in this manner. Binding expressions etc will be evaluated in the main thread as they are currently.
I realize that most likely my implementation will have some limitations (e.g. some xpath functions not supported since they have dependencies that might not be transferable, not all return types supported etc.) -- some which might be overcome with additional effort -- however I think most important use cases can be supported still with such limitations (e.g. calculating digests etc)...
I am interested to learn what you have in planning for a new XPath engine!? If the ability to evaluate expressions in web worker context is taken into account in the design, that would be great of course!
Welcome your feedback!
Mats
On Mon, 31 Aug 2015 21:18:53 +0200, Alain Couthures wrote:
Hi Mats,
The more I think about using a Web Worker for XSLTForms, the more
it sounds obvious that the right solution should be to dedicate a
Web Worker for storing/manipulating instances (XPath evaluations
and submissions): only node lists and values are to be present in
main thread actually!
First, this means that source code has to be adapted in a lot of
different locations.
Second, my Javascript XML DOM implementation is ready for
integration but my new XPath engine is not yet operational except
for very simple expressions...
What do you think of this different approach?
--Alain
Le 31/08/2015 07:25, Mats Eklund a écrit :Hi Alain,
Thanks for your feedback!
> XSLTForms supports
xf:setnode as an extension. So, with both
xf:setvalue and xf:setnode, at first glance, I
prefer a @mode="synchronous/asynchronous"
implementation (as in xf:submission).
One of the advantages I saw
with the xf:submission + proxied XMLHttpRequest option is
the submission-done notification event, which allows
chaining subsequent actions. I now realize however, that a
similar notification event is triggered by the xf:insert
action (xforms-insert), so if the @asynchronous attribute
could be applied on this action, the extension attribute
approach would probably be the more interesting option.
Furthermore, it looks like both xf:setvalue and xf:setnode
could be replaced by an xf:insert action if the XPath 3.0
functions fn:parse-xml() and fn:parse-xml-fragment() were
available in XLSTForms (for use in the xf:insert/@origin
attribute), in cases where the notification event is
important. This seems doable as well...
> I have not been working with Web Workers yet but I
read that there are limitations like these. XSLTForms
already has its own XPath engine but is currently using
native XML engines (an independent XML engine, fully
written in Javascript, is already in good progress!). Why
do you think that XSLT would also be required or is just
it that XSLT would be nice to have available too?
Concerning XSLTProcessor, large
XSLT transforms can be long running so it would be nice if
such could be run in a background thread. Furthermore, the
transform() xpath function is already part of the XSLTForms
core function library, and I'm thinking this entire library
should ideally be available also in the web worker context. I see there are some javascript
implementations of XSLTProcessors on the web (not sure if
Saxon CE is possible to use -- I'm trying to clarify).
By the way, which XML DOM level is required by XSLTForms'
XPath implementation for navigating on XForms instance
documents, do you know? So far it looks like the browsers'
native XML DOM Parser is not available in web worker
context...
/ Mats
------------------------------------------------------------------------------
_______________________________________________Xsltforms-support mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xsltforms-support
|
|
From: Alain C. <ala...@ag...> - 2015-08-31 19:32:05
|
Hi Mats, The more I think about using a Web Worker for XSLTForms, the more it sounds obvious that the right solution should be to dedicate a Web Worker for storing/manipulating instances (XPath evaluations and submissions): only node lists and values are to be present in main thread actually! First, this means that source code has to be adapted in a lot of different locations. Second, my Javascript XML DOM implementation is ready for integration but my new XPath engine is not yet operational except for very simple expressions... What do you think of this different approach? --Alain Le 31/08/2015 07:25, Mats Eklund a écrit : > Hi Alain, > > Thanks for your feedback! > > >XSLTForms supports xf:setnode as an extension. So, with both > xf:setvalue and xf:setnode, at first glance, I prefer a > @mode="synchronous/asynchronous" implementation (as in xf:submission). > > One of the advantages I saw with the xf:submission + proxied > XMLHttpRequest option is the submission-done notification event, which > allows chaining subsequent actions. I now realize however, that a > similar notification event is triggered by the xf:insert action > (xforms-insert), so if the @asynchronous attribute could be applied on > this action, the extension attribute approach would probably be the > more interesting option. Furthermore, it looks like both xf:setvalue > and xf:setnode could be replaced by an xf:insert action if the XPath > 3.0 functions fn:parse-xml() and fn:parse-xml-fragment() were > available in XLSTForms (for use in the xf:insert/@origin attribute), > in cases where the notification event is important. This seems doable > as well... > > > I have not been working with Web Workers yet but I read that > there are limitations like these. XSLTForms already has its own > XPath engine but is currently using native XML engines (an > independent XML engine, fully written in Javascript, is already in > good progress!). Why do you think that XSLT would also be required > or is just it that XSLT would be nice to have available too? > > Concerning XSLTProcessor, large XSLT transforms can be long running so > it would be nice if such could be run in a background thread. > Furthermore, the transform() xpath function is already part of the > XSLTForms core function library, and I'm thinking this entire library > should ideally be available also in the web worker context. I see > there are some javascript implementations of XSLTProcessors on the web > (not sure if Saxon CE is possible to use -- I'm trying to clarify). > > By the way, which XML DOM level is required by XSLTForms' XPath > implementation for navigating on XForms instance documents, do you > know? So far it looks like the browsers' native XML DOM Parser is not > available in web worker context... > > / Mats > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: Mats E. <mat...@li...> - 2015-08-31 05:25:35
|
Hi Alain,
Thanks for your feedback!
> XSLTForms supports xf:setnode as an extension. So, with both
xf:setvalue and xf:setnode, at first glance, I prefer a
@mode="synchronous/asynchronous" implementation (as in
xf:submission).
One of the advantages I saw with the xf:submission + proxied XMLHttpRequest option is the submission-done notification event, which allows chaining subsequent actions. I now realize however, that a similar notification event is triggered by the xf:insert action (xforms-insert), so if the @asynchronous attribute could be applied on this action, the extension attribute approach would probably be the more interesting option. Furthermore, it looks like both xf:setvalue and xf:setnode could be replaced by an xf:insert action if the XPath 3.0 functions fn:parse-xml() and fn:parse-xml-fragment() were available in XLSTForms (for use in the xf:insert/@origin attribute), in cases where the notification event is important. This seems doable as well...
> I have not been working with Web Workers yet but I read that there
are limitations like these. XSLTForms already has its own XPath
engine but is currently using native XML engines (an independent XML
engine, fully written in Javascript, is already in good progress!).
Why do you think that XSLT would also be required or is just it that
XSLT would be nice to have available too?
Concerning XSLTProcessor, large XSLT transforms can be long running so it would be nice if such could be run in a background thread. Furthermore, the transform() xpath function is already part of the XSLTForms core function library, and I'm thinking this entire library should ideally be available also in the web worker context. I see there are some javascript implementations of XSLTProcessors on the web (not sure if Saxon CE is possible to use -- I'm trying to clarify).
By the way, which XML DOM level is required by XSLTForms' XPath implementation for navigating on XForms instance documents, do you know? So far it looks like the browsers' native XML DOM Parser is not available in web worker context...
/ Mats
|
|
From: Alain C. <ala...@ag...> - 2015-08-30 20:02:56
|
Hello Mats,
> In HTML 5 there is the Web Worker object, and it should be possible to
> leverage this to perform the calculation in a background thread
> client-side.
XSLTForms is not yet using Web Worker but Google Chrome is already
complaining about XMLHttpRequest being called in main thread... ;-)
>
> I guess it is possible to implement the long running calculation in a
> javascript function that may be called via xf:load and where the
> result is returned via call to XForms DOM API
> (model.getInstanceDocument(), model.recalculate()...).
>
> However, it would be nice if the operation could be kept more "XFormy"
> and as declarative as in the "non-async" example above.
>
> I'm currently considering two possible options:
>
> 1) XForms extension attribute, like so:
>
> <xf:setvalue ref="mynode" value="..." @ext:async="true"/>
>
> 2) Implementing the operation as an xf:submission, but proxying the
> underlying XMLHttpRequest object to intercept selected submission URLs
> and handle them client-side:
>
> <xf:submission resource="http://client/myfunction?param1=..."
> serialization="...".../>
>
> and
>
> XMLHttpRequest.registerHandler("http://client/myfunction", myhandler)
>
XSLTForms supports xf:setnode as an extension. So, with both xf:setvalue
and xf:setnode, at first glance, I prefer a
@mode="synchronous/asynchronous" implementation (as in xf:submission).
>
> Both options seem to have their unique merits and possible usages.
> While the second option is probably quite straight-forward to
> implement, the second option may require some more work, like:
>
> 1) Porting XSLTForms XPath implementation, as well as some other
> objects (XSLTTransform), to work in a Web Worker context.
I have not been working with Web Workers yet but I read that there are
limitations like these. XSLTForms already has its own XPath engine but
is currently using native XML engines (an independent XML engine, fully
written in Javascript, is already in good progress!). Why do you think
that XSLT would also be required or is just it that XSLT would be nice
to have available too?
> 2) Finding a way to efficiently transfer relevant data (XForms
> instances) to the Worker context
> 2) Making modifications to the relevant action implementations in
> XSLTForms to handle asynchronous execution of the action
>
> Seems doable to me, but would be interested to hear if someone has
> experience to tell whether that'a crazy idea or not. Obviously, would
> be cool if such features could become native features of XSLTForms!
I will be happy to add such features in XSLTForms even if only recent
browsers will support them!
What do you think?
--Alain
|
|
From: Mats E. <mat...@li...> - 2015-08-26 14:45:15
|
Hi,
I am looking at options for performing time-consuming operations, like...
<xf:setvalue ref="mynode" value="digest(transform(instance('my-very-large-instance-document')),'SHA-1')"/>
...in my form as background operations that don't cause freezing of the form's UI.
Obviously, if my form had access to a web-server, such calculations could be posted to the server using an xf:submission, however, in my case, the form should work completely offline.
In HTML 5 there is the Web Worker object, and it should be possible to leverage this to perform the calculation in a background thread client-side.
I guess it is possible to implement the long running calculation in a javascript function that may be called via xf:load and where the result is returned via call to XForms DOM API (model.getInstanceDocument(), model.recalculate()...).
However, it would be nice if the operation could be kept more "XFormy" and as declarative as in the "non-async" example above.
I'm currently considering two possible options:
1) XForms extension attribute, like so:
<xf:setvalue ref="mynode" value="..." @ext:async="true"/>
2) Implementing the operation as an xf:submission, but proxying the underlying XMLHttpRequest object to intercept selected submission URLs and handle them client-side:
<xf:submission resource="http://client/myfunction?param1=..." serialization="...".../>
and
XMLHttpRequest.registerHandler("http://client/myfunction", myhandler)
Both options seem to have their unique merits and possible usages. While the second option is probably quite straight-forward to implement, the second option may require some more work, like:
1) Porting XSLTForms XPath implementation, as well as some other objects (XSLTTransform), to work in a Web Worker context.2) Finding a way to efficiently transfer relevant data (XForms instances) to the Worker context2) Making modifications to the relevant action implementations in XSLTForms to handle asynchronous execution of the action
Seems doable to me, but would be interested to hear if someone has experience to tell whether that'a crazy idea or not. Obviously, would be cool if such features could become native features of XSLTForms!
Welcoming your feedback!
Mats
|
|
From: Tim T. <tim...@gm...> - 2015-08-10 16:09:41
|
I'm curious to know whether any other XSLTForms users have experimented with JSON support in XSLTForms, and particularly whether anyone has extended the code to support JSON names that are not valid XML names[1]. I'm interested in the possibility of using JSON-LD as XForms instance data[2]. Best regards, Tim [1] Alain's "JSON for XForms" paper from XML Prague 2011: http://archive.xmlprague.cz/2011/files/xmlprague-2011-proceedings.pdf [2] http://json-ld.org/ -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library <ta...@pr...> |
|
From: Javier D. <jd...@tc...> - 2015-08-09 17:33:45
|
Hello, I would create in select list an empty value, and assign this value as the default value for the xml data associated to the select list. Another option is to assign a value of select list that is not an empty value as default value. The blank row that appears to you and then disappears I think is because the value of the xml data associated to the select list is empty but it isn't a empty value in select list. Best Regards, Javier El 05/08/15 a las 20:17, Tim Thompson escribió: > Hello, > > I have a form with dynamic select list and would like to always > maintain a blank row at the top of the list (with > @appearance="minimal" or @appearance=compact). > > Here's a working example: http://pulcams.github.io/subjects/ > > When a selection is made, the blank row disappears. I've also had > trouble on other occasions when trying to control the display of a > blank row in select lists in XSLTForms, especially in repeat > structures. Sometimes the blank row is duplicated, for example. > > Does anyone have a good solution for this (using either XForms/XPath > logic or external JavaScript)? > > Thanks in advance, > Tim > > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: Tim T. <tim...@gm...> - 2015-08-06 16:43:12
|
Hello, I'm implementing a quick paging solution using subforms and had another UI-related question. Example app (save button not currently enabled): http://pulcams.github.io/subjects/ I'm using a simple counter to iterate through a set of sequentially numbered subforms. This is done by using "previous" and "next" buttons or by inputting a number to jump to a page. Each time one of the buttons is clicked, an "Initializing" box briefly appears. This does not happen when a user types in a number (I'm guessing this has something to do with the "incremental" behavior). Is there an easy way to quiet the "Initializing" notice for the DOMActivate events as well? Thank you, Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library |
|
From: Tim T. <tim...@gm...> - 2015-08-05 18:17:50
|
Hello, I have a form with dynamic select list and would like to always maintain a blank row at the top of the list (with @appearance="minimal" or @appearance=compact). Here's a working example: http://pulcams.github.io/subjects/ When a selection is made, the blank row disappears. I've also had trouble on other occasions when trying to control the display of a blank row in select lists in XSLTForms, especially in repeat structures. Sometimes the blank row is duplicated, for example. Does anyone have a good solution for this (using either XForms/XPath logic or external JavaScript)? Thanks in advance, Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library <ta...@pr...> |
97 messages has been excluded from this view by a project administrator.
