Re: [Xsltforms-support] Declarative4all Overview?

[Tim T. <tim...@gm...>]

Gary,

My perspective as an XForms user: XQuery is designed for querying and
working with document structures, which makes it a great fit for
declarative client-side DOM manipulation--as I recall, the XQuery
implementation in Fleur.js lets users manipulate the HTML5 DOM directly
(even though it's not well-formed XML). XQuery is a superset of XPath, so
client-side XQuery is the pathway to adding support for XPath 3.0 and
XForms 2.0 features to XSLTForms.

Tim


--
Tim A. Thompson
Metadata Librarian
Yale University Library

On Tue, Mar 30, 2021 at 2:00 PM Gary Kopp <ge...@ru...> wrote:

> Thanks, Alain. Your explanation is very helpful, and thought-provoking. I
> imagine other new outsiders will also find it helpful.
>
>
>
> A question, if you will indulge someone that doesn’t fully understand the
> XForms technology landscape yet. Why do we need a new XQuery engine? I
> believe XQuery on the server side is already well supported (but I could be
> misunderstanding something). It seems Fleur.js will allow also XQuery on
> the browser side, but I personally don’t see a use case for that. I’m sure
> I’m missing something…
>
>
>
> --Gary
>
>
>
> *From:* Alain Couthures <ala...@ag...>
> *Sent:* Tuesday, March 30, 2021 11:20 AM
> *To:* Gary Kopp <ge...@ru...>;
> xsl...@li...
> *Subject:* Re: [Xsltforms-support] Declarative4all Overview?
>
>
>
> When developing web applications, XForms, because it has been specified to
> be implemented in browsers, is not enough.
>
>
>
> XSLTForms is a client-side XForms implementation using XSLT 1.0 as a trick
> to transform XForms pages into HTML pages with CSS and Javascript. It works
> within browsers...
>
>
>
> XSLT 1.0 is still supported in major browsers, but vendors would like to
> get the corresponding memory space for new features instead... XSLTForms
> must evolve...
>
>
>
> Since 1.5, XSLTForms uses its own HTML5 notation for XForms. It allows
> authors, if they prefer this, to write forms directly without the XSLT step
> being required, which, is now also available in Javascript for Nodejs! BTW,
> Cordova supports this HTML5 notation, too.
>
>
>
> The XPath engine of XSLTForms is also evolving. The corresponding parser
> has been rewritten from XSLT 1.0 to Javascript. This parser has been
> extended to support XQuery 3.1. Then, a new XQuery engine has been created,
> named Fleur.js, for both browsers and Nodejs.
>
>
>
> We, also, have Nodejs to easily develop and run light HTTP servers. It
> allows XQuery at server-side (with Fleur.js) to access files, query other
> web servers, ... and XForms at client-side (with XSLTForms) to render and
> modify data.
>
>
>
> Next step: Fleur.js for XSLTForms is now in alpha...
>
>
>
> So, Declarative4all is a project to host all that stuff and more... It is
> the not-private part of the dev environment, actually...
>
>
>
> --Alain
>
> Le 29/03/2021 20:22, Gary Kopp <ge...@ru...> a écrit :
>
>
>
>
>
> I’m new to XForms with eXist and quickly realized I needed XSLTForms to
> get started. I found XSLTForms 1.3 on Github and thought I was done,
> although I was concerned that it hadn’t been updated for years. Then I was
> given a link to Declarative4all and now see that XSLTForms is alive and
> quite well. But I’m a little confused – is Declarative4all just an
> xsltforms.js upgrade, or is there more to it from a functional standpoint?
> Is there a summary statement somewhere of what Declarative4all actually is?
>
>
>
> --Gary Kopp
>
> _______________________________________________ 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
>