Improve JavaScript and Node.js ecosystem friendliness

[epost]

Bonjour Alain! I created a javascript + node.js based tool for 'unpacking' your js.xml files back into plain javascript: https://github.com/epost/unjsxml. I needed this so I can work with your sources in my editor (which happens to be emacs). I think it would be great if we could work towards a build that doesn't absolutely require tools like PHP and httpd or stuff like that.

This is just a first step, but it should be fairly easy to additional functionality. For instance, running a webserver is just a few additional lines of js code. Qu'est-ce-que t'en penses?

[AlainCouthures]

Bonjour Erik,

While text editors can now help editing Javascript sources in various ways, I know that .js.xml files are just treated as XML... I have already tested Orion hoping for more intelligent editing of Javascript sources but, unfortunately, it did not work well enough with my sources...

PHP is currently allowing me to dynamically generate .js and .xsl files from the source files and it is very nice not to have to build them first each time I want to test a fix or a new feature. I would be happy to replace PHP with Node.js, because I clearly don't need all the power of Apache+PHP for that, but I still have to rewrite the txs.php application which requires a DOM implementation and an XSLT engine. My own DOM implementation for Node.js, named Fleur, now works like a charm but it does not yet also contain an XSLT engine...

BTW, Fleur is also designed to parse and serialize non-XML data, such as Javascript sources, and it could be used to convert from .js.xml to .js and back. The truth is, I always prefer using my own products because I don't like any dependency ;-) PHP is very stable, Node.js sounds too.

[epost]

Hi Alain,

If Fleur could somehow help here, that would be great. However, there is hardly any documentation at https://github.com/AlainCouthures/Fleur so it's a bit tricky to figure things out for me. In particular, the README doesn't mention the type of documents for which Fleur provides a DOM, so even if it were useful (which it no doubt is) I can't tell from the README.

In the meantime, I've updated https://github.com/epost/unjsxml. It now unpacks .js.xml files (including global config variables) and lists the required imports in the correct order, which makes it easy to concatenate them into a single .js bundle, and work with that in the browser.

Maybe if you have time, you could have a look and tell me what you think would need to be done so that you'd consider pointing to or including unjsxml in the xsltforms documenation or build? While it's far from ideal, it at least enables javascript people to work with xsltforms using regular tools, and without needing PHP and Apache. Turning this into a webserver that does the concatenation on the fly, like you describe, shouldn't be too difficult.

Cheers, Erik

Update: just found http://www.agencexml.com/amsterdam2015/Processing_non-XML_sources_as_XML.pdf which has some docs on Fleur.

[AlainCouthures]

Hi Erik,

I agree with you that current dev environment for XSLTForms is now old fashion. Javascript tools are more and more available while XML tools are disappearing...

I have been looking at PhoneGap last week and I am happy to see that Javascript and Node.js are also used in that context.

I am now starting to write my own HTTP server with Node.js to help developing for both browsers and phones. There is no need to keep an XML notation for Javascript source files and I will test unjsxml for initializing the new source folders.

My intent is to have a management form to customize everything: generate the XSLT stylesheet and the Javascript library from sources or pick a previous release, apply the XSLT stylesheet at server-side or at client-side, apply a Javascript preprocessing instead of an XSLT transformation, add runtime settings for targeted rendering, build a new release, build a PhoneGap project,...

What do you think?

Thanks! Alain

[epost]

Hi Alain,

That's great news! I'm not sure how familiar you are with the node.js way of doing things, but I think any small step in the direction of making the build easier for javascript people could be immensely useful. It would also simplify contributing a lot, I think. If you need some suggestions, feedback or help, let me know. I have my own node.js webserver for xsltforms by the way. It's just been pasted together from some bits on stackoverflow, but it's useful to me atm. Looking forward to your changes! :) :+1:

Thanks, Erik

[AlainCouthures]

Hi Erik,

I would be happy to have your point of view about the new development environment for XSLTForms which is hosted as a new project named "xphoneforms" (because I want it to finally build phone/web apps...).

Folders are differently organized: apps are grouped in a folder below the "www" folder. Common files might not be present in those folders but in top level folders: "src", "build" or "stable". Javascript files are always in the "js" sub-folder, CSS files in the "css" sub-folder, and so on!

The manager.js program is a Node.js HTTP server which performs the corresponding URL rewriting and dynamically composes executable files from sources . For example: "/stable/samples" will return "/www/samples/index.xml" and all missing files in "samples" will be retrieved from the "stable" folder, "/src/samples/js/xsltforms.js" will return "/src/js/xsltforms.js",...

I have enhanced your unjsxml.js program to generate new source folders with, now, regular .js, .css or .xml files (Eclipse Orion does not recognize .xsl files as XML and allows multiple document elements in an XML document!). I have extended the "project.json" file to store inclusion order.

What do you think?

Thanks!

Alain