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
[email protected]
https://lists.sourceforge.net/lists/listinfo/xsltforms-support
------------------------------------------------------------------------------
_______________________________________________
Xsltforms-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xsltforms-support
