2014-11-02

AMD global require and relative path from HTML

In my environment there are lot of tests and templates are HTMLs with self-testing functionality. To make them path-agnostic I was using relative MIDs to same folder resources: scripts, templates and CSS.

ModuleFolder

  • MyModule.html
    • require(["./MyModule"],function(MyModule){ new MyModule({},createDivInBody() ).startup(); }
  • test/test.html
    • require(["../MyModule"],function(MyModule){ new MyModule({},createDivInBody() ).startup(); }
  • MyModule.js
    • require(["dojo/text!./MyModule.html","AMD/cssI!./MyModule.css"],function( template, css) {... }
  • MyModule.css
As dojo AMD and perhaps some other AMD implementations disrespect relative path on global require I need  either to work around or make AMD working as expected. By expected I mean not imaginary potential use of absolute path but real life expectation when looking on the code sniplet above.

There are 2 bugs exposed in the code:

  1. The repative path in HTMLs is treated not as module with JS extension assumed but rather abstract resource, so no JS extension added when path converted to URL. What it could be if not a JS and why there is a difference to MID ?
  2. In CSS plugin the relative path is not working either. It is computated relatively to dojo basePath
The bug fix is not an option(see bellow). What could be done?

  1. Shim the require() and rebase relative pathes with regard to existing basePath
  2. Create artificial "currentPage" package and place into require config, replace relative path dots with this package: require({paths:{currentPackage:location.href... }},["currentPackage/MyModule"]
  3. Use absolute package name: require(["lib/MyLib/PackageX/MyModule"
  4. give up on dojo and use another AMD loader
Perhaps someone could give a better suggestion which is quite appreciated.
If there is a solution, please share.

Regards,
suns

PS. Thank  Christophe Jolif's wisdom for this pain: https://bugs.dojotoolkit.org/ticket/14649
PPS. for interested will keep track on my blog.

JSON added to XmlView, a bookmarklet for web service presentation as sortable table

In addition to early promoted XML in XmlView the JSON format support appeared to be an easy effort. The recognition of JSON format and conversion to XML was all needed to make a sortable table presentation for JSON based web services.

It is not as efficient and scalable as XML though. JSON doubles the browser memory consumption, half of which reside in the JS VM; additional parser for JSON consumes extra CPU/time.

Is it possible to make a faster and smaller memory consumption implementation using JSON without XML?

I guess not. XML reside in browser memory and is not a subject for JS limitations which will be in place for JSON. There is no multi-threaded(yet?) template transformation from JSON to HTML. Not to mention there is no way to render directly DOM by template engine besides XSLT.

Potential for the improvement

There is a prototype for virtual scrolling via XSLT. It could be used as a base for rendering just visible part of data delegation the rendering on scroll in real time.

Happy coding!