. Eat whitespace before the template element

~ Eat whitespace after the template element

^ out=filter( template element ); where filter() is a standard function which calls an array of filter functions in array order and it is easy to add and remove functions from that array at runtime (Yes, I can easily implement filter without the shortcut character)

Question: Is there any plan to provide the same (or similar) convenience functions for navigating and querying JSON as for XML?

Another question: Why did you choose to use curly braces for outputting context node values? I prefer to use consistent bracketing practices, so I would have chosen double square brackets for that case or else provided yet another shortcut character.

Thanks for your post. Let me answer your questions.
1. I will think about the shortcut characters for the template processing. Now it is a global setting to ‘remove whitespace before template elements’.
2. I dont quite get what you mean by filter.. the XSLT template/apply idea? That one is implemented already.
3. JSON sounds like a very easy one to support with JSLT. I will consider it for a next version. Thanks for the idea.
4. I adopted the XSLT curly braces for inline xpaths. You can also use code brackets like so: [%$’xpath].

I applaud your skill but I think that you totally missed the boat with XSLT. Personally, I find XSL far simpler to write than almost any other programming language that I’ve come accross. If you treat it as a procedural or OO language then you’re going to get stuck, but if you treat it as a functional language (which folks much smarter than I have proven) then you start to see the great benefits it has.

for example you used some horribly inefficient XSLT in your examples, in some cases doing things in exactly the way that the XSLT “cool kids” say you shouldn’t do. For example:

Item of type A:

Item of type B:

should be

…

Item of type A:

Item of type B:

There are things that you could’t easily do with your JSLT that XSL does trivially. For example, if I wanted to sort that list of items by their price attributes, all I need to do is use sort:

Not to mention that if you simply do XSLT the “right” way (using templates well), you get modular, resuable code for free. With JavaScript in general, this is a LOT of work.

I agree that my if a/b example is poorely chosen as it is begging for your remark that i have misunderstood XSLT. It is also a bad example. I have removed it from the article, and will replace it with something that shows the benefit of JSLT better. However if you want to go the recursive/functional approach, you can just do that with JSLT with the template and apply functionality. Also, the sort functionality from XSLT is trivial to implement in JSLT, although i must confess i have not yet needed it myself so i haven’t added it to JSLT.
From a proof point of view, functional programming is very ‘clean’ and predictable. However from an every day life problem solving point it can become very annoying and often requires to bend problems that are of an iterative/branching nature into a recursive kludge.
This imho really limits the maintainability of many of the clever XSLT solutions as they are often more of an egotrip in (forced) overapplying recursion than actually solving a computing problem in the simplest possible way.
As for modularity, JS is extremely modular. Of course, it is less naturally modular than a (semi)functional language like XSLT (truly functional languages don’t have variable assignments) but that is a matter of finding the proper modularization.
As far as the template/sort structure goes. I often have a problem with XSLT binding its output order to the input order by the application of a template, and then to define a specific order to that processing to resort to sorting. This makes the actual flow through your template code very hard to see, and making little exceptions to the template flow a nightmare. With JSLT i can just pick wether i want implicit flow or explicit flow without much syntactic overhead.

cheers,
prakash

I could call it a ‘practical’ alternative for XSLT if you will. I have yet to encounter a client-side transform that is not easier to do in JSLT than XSLT, and i’ve done quite a few. As you claim XSLT is so much bigger than i have percieved, perhaps i have missed a whole class of XSLT usage i have never needed nor encountered. Please tell me what i have missed, or point to it. That way i will see what you mean. I know, for instance that i miss all the Xpath functions that return strings, because the browser DOM only allows xpaths that return nodes. However those functions are usuallly trivial to do in JS, and can be added easily. Please don’t forget JSLT is not a language in itself, it is a way to use Javascript as a templating language, extended with a few helper functions for XML traversal that mimic XSLT semantics.
For perspective, adding the XSLT template/apply structure to JSLT was just 10 lines of JS. I have a hard time believing you can do things in XSLT i cannot more easily do in Javascript especially with the power to extend the Javascript language to aid templating. However i’m sure there are cases with heavy namespace use, and processing huge XML files that JSLT will be less optimal (or functional) than XSLT. But as a client-side AJAX templating language it can be extremely useful and more maintainable.
I would love find and understand structures in XSLT that i have missed. Please tell me which ones, i’m very happy to be challenged on the usability scope of JSLT.

1. Ability to load input files using the ‘document’ function
2. Import and include additional files having templates
3. Assign default and explicit priorities to templates
4. call extension functions
5. Build temporary trees and call xpath on them though by using extensions
6. Loading the stylesheet dynamically with the XSL-stylesheet processing instruction
7. Using catalogs to resolve dtds, schemas and entities
8. Generate another stylesheet as result
9. Transform to XML, HTML, XHTML and text. The docbook stylesheets support additional formats.
10. Accept stylesheet parameters
11. normalize white-space
12. exclude unused namespace prefixes
13. Perform lookup using keys
14. call templates by name
15. perform grouping although with considerable effort

This is just the XSLT part without involving XPath. Many may not be required for your JScript version. I too haven’t checked your software so well. I will sometime so I get a better picture. Let me know if your software does any of the above.

cheers,
prakash

1. Ability to load input files using the ‘document’ function
JSLT: Very easy to add. JSLT just works with a local XMLnode object ‘n’. I already have a parse(”"){} function in JSLT with “” being the XML string. I can extend that to load files as well. You are free to store the parsed document in a variable for reuse anywhere aswell. I am thinking of a feature so you can prepend/join the node variable somehow with an xpath like so: [%value(otherdoc,’xpath’)]. In that case you can always flip documents and context nodes per xpath lookup.

2. Import and include additional files having templates.
JSLT is just javascript. It can recusively call itself easy. If you make a JS function like: [%jslt(”otherfile”);] you can inline process other JSLT files. If you want to parse them you can do this:
[parse(jslt(”otherfile”)){] now do xpaths on the output of the other jslt [}]

3. Assign default and explicit priorities to templates
I must admit i dont have a priority feature on my templates, but that can be easily added.

4. call extension functions
just add a JS function anywhere to your global object, or adapt the JSLT code and you can have as many extensions as you like.

5. Build temporary trees and call xpath on them though by using extensions
Temporary trees are easy. Like so:
[store(’temptree’){] <x><otherxml>blah</otherxml></x>[}]
[parse(fetch(’temptree’)){] {otherxml/text()} [}]
You can also nest this type by using pack
[parse(pack(){]
<x><otherxml>blah</otherxml></x>
[}){]
Fetch generated:{otherxml/text()}
[}]

6. Loading the stylesheet dynamically with the XSL-stylesheet processing instruction.
This is a feature of the xml parser / xml viewer so this will not be possible. However as you usually write software to process XML and not rely on the processing instruction, i never had a problem with this.

7. Using catalogs to resolve dtds, schemas and entities
I have to admit i never used this, or know what it really means.

8. Generate another stylesheet as result
JSLT can easily be used to create other JSLT. However because JSLT is far more dynamic than XSLT, the need to create other stylesheets is dramatically reduced.

9. Transform to XML, HTML, XHTML and text. The docbook stylesheets support additional formats.
JSLT outputs ‘text’. You can output any text based format like XML/HTML/XHTML with this. Of course it will not create a ‘tree’ but text. This might be a bit slower, and you can break the resulting XML tree more easily with a typo as you cannot XML validate the template.

10. Accept stylesheet parameters
You can use any JS variable/parameter in your template.

11. normalize white-space
JSLT has currently 2 modes, remove whitespaces at start of line or dont, and always removes newlines and tabs. This might need some tweaking.

12. exclude unused namespace prefixes
Dont know what you mean by that.

13. Perform lookup using keys
You can lookup anything. Xpaths are just strings so you can concat them like this: [value(’X'+value(’@id’))] (will do an xpath lookup on the X+id attribute)
Also you can use temporary JS arrays to easily store variables for future reference. Really handy for creating an index atop a transformed document.

14. call templates by name
You can load subtemplates, but you can also call templates by name, or make macros, or custom string transform functions. Anything you want.

15. perform grouping although with considerable effort
Grouping is really _really_ easy in JSLT.

To summarise:

Cons:
I’d say JSLT lacks in DTD/Schema support, and does not output XML tree’s directly but always text making it easier to break your output xml.
JSLT is a bit slower.

Pros:
JSLT is almost infinitely flexible in doing streams/reuse/loading data/using variables/storing temp data and creating extension functions. Imho

Thanks for your comments.

e.g:
[store(’temptree’){] blah[}]
[parse(fetch(’temptree’)){] {otherxml/text()} [}]
You can also nest this type by using pack
[parse(pack(){]
blah
[}){]
Fetch generated:{otherxml/text()}
[}]

Another important feature strikes me.You say JSLT outputs text and you also have templates in JSLT. Does this mean you output tags instead of nodes. i.e is the following possible:

enter template A:

exit template A:

enter template B:

exit template B:

If so, this is bad. XSLT doesn’t output tags. It builds a tree in memory and serializes them. Also, you cannot output a ‘

JSLT outputs ‘tags’ instead of nodes. It is a text-templating language. However, it could be extend to output tags. This will probably be a lot slower (DOM api from JS is really not fast), but that method will prevent missing tag errors. Sofar i have not run into issues with forgetting a tag. Just check the output of your template in an XML parser (as always happens when generating XML) to solve the problem.

On the unreadability part, i agree that it requires some getting used to reading JSLT. However, so does XSLT. I personally find large XSLT documents very hard to read, much harder than code. Especially if they have functionality encoded in recursive logic (that should be a loop or a temporary array). I guess its just something to get used to with JSLT.

is the following possible:

enter template A:

<new_tag>

exit template A:

enter template B:

</new_tag>

exit template B:

[}]

I don’t know if this is possible but it would be mighty useful.

Thanks,
Matt k.

I have added a sort function per your request. Please check the live example/ blog article for updates on sort.

Your example looks like this now:
[sort(’re’,'date’,sort_date){]

[}]

Please be aware the sort xpath is relative to the foreach xpath and is executed on each item in the foreachset to obtain the sorting set.
Also, the core sorting algo works on ’stringsort’ the function you pass in essentially converts the context node (date in this case) to a string
that can be properly sorted. the sort_date function converts a date to a 0 padded integer for example to apply stringsort.

When I first read this post on the Ajaxian my very first (somewhat unkind) thought was OMG do we really…

Buy fioricet online. Buy fioricet online that ships to missouri. Buy fioricet online without a prescription….