Add a template to dump the parameters to a custom helper.

master
Tom Alexander 4 years ago
parent 9892d2f61d
commit a6641d9c72
Signed by: talexander
GPG Key ID: D3A179C9A53C0EDE

@ -3,6 +3,19 @@ var dust = require("dustjs-helpers");
var fs = require("fs");
const path = require("path");
dust.helpers.dumpParameters = function(chunk, context, bodies, params) {
// Dump the parameters to a dust helper to figure out what is passed
// to a helper. I figure I need to make sure I'm passing
// approximately the same information to my render functions if I
// end up supporting custom helpers in the future to make sure
// helpers can be ported easily.
// console.log(JSON.stringify(Array.prototype.slice.call(arguments)));
console.log("chunk: ", chunk);
console.log("context: ", JSON.stringify(context));
console.log("bodies: ", bodies);
console.log("params: ", params);
}
var argv = process.argv.slice(2);
if (argv.length < 1) {
console.error("Expecting only 1 argument (a path to a template)");

@ -0,0 +1,11 @@
This folder is for test cases that are NEVER expected to work on duster but I've written to investigate the behavior of original dust. Examples of this are:
Custom javascript dust helpers
------------------------------
Inside the shim I wrote a very basic custom dust helper to investigate the chunk, context, bodies, and params parameters so that I can theoretically expose a similar interface for custom rust dust helpers. Since I won't be perfectly replicating those objects, duster would never output a byte-for-byte identical output for that helper.
Javascript context helpers
--------------------------
I do not intend to integrate a javascript engine into duster, so context helpers written as javascript inside the json context will not work on duster. I believe, based on my interface-based approach, I'll be able to support runtime functions written in rust and stored in rust objects (not from JSON) to serve the same functionality as context helpers but that still remains to be seen.

@ -0,0 +1,30 @@
Chunk
-----
Some sort of object which contains an array of rendered elements. For example, using:
```
Testing dump parameters
{#names}
{.}
{/names}
```
The first interation would have `["Testing dump parameters", "Alice"]`.
Question: Do any helpers read from chunk or just write to it? If its just writing, then my current architecture of just returning a `String` would work fine, though having a shared buffer thats written to would probably reduce the allocations and therefore improve performance.
Context
-------
Some sort of object that contains essentially the "breadcrumbs" variable I am currently using to track the context tree. Also tracks template name, globals and options. I guess options would be that whole preserve whitespace or not option. I was just going to store this option on the dust renderer type, but I guess I should bake it into the breadcrumbs to pass into helpers if I implement support for custom helpers.
Bodies
------
No idea, but based on the name I assume it contains the contents of the helper, or at least some way to render the internal body of the helper.
Params
------
A mapping of the parameters directly on the helper.

@ -0,0 +1,7 @@
Testing dump parameters
{#names}
{.}
{@dumpParameters foo="bar"}
Internal
{/dumpParameters}
{/names}
Loading…
Cancel
Save