Re: [Xsltforms-support] Evaluating long calculations asynchronously in background

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

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