Example of template string parsing in fluid (and a comment on function docs)...

Tony Atkins tony at raisingthefloor.org
Wed Mar 11 07:00:36 EDT 2015


Hi, All:

Antranig and I have been discussing template handling in various client and
server-side components.  Although there are many other requirements, there
are two requirements I'd like to talk about:

   1. Users should be able to change the location of one or more templates.
   2. Users should not have to make an "all or nothing" choice, i.e. they
   should be able to use the default location for some templates and override
   others as needed.

To support this level of flexibility, the location of individual templates
needs to be specified as a full path.  Ideally, the repeating parts of
these paths should be expressed as variables.

I see from Cindy's recent work that there is an emerging pattern of
expanding *%variable* references:

https://github.com/cindyli/infusion/commit/033d9eadea896f43d640e5f386b2d8f59753ad75

If you're anything like me, it will take a while to drill down to the base
bits of infusion that make this possible.  I thought I would share a simple
demonstration of *fluid.templateString* usage.  Here is demo code that
wires in the existing *fluid.templateString* and *fluid.transform* functions
to make a new expander that results in parsed content with variables
interleaved:

// Sample demonstration of fluid.stringTemplate to parse %variable
>> references...
>
> "use strict";
>
> var fluid = fluid || require("infusion");
>
> var gpii  = fluid.registerNamespace("gpii");
>
>
>> fluid.registerNamespace("gpii.sandbox.variables.base");
>
> fluid.defaults("gpii.sandbox.variables.base", {
>
>     gradeNames: ["autoInit", "fluid.eventedComponent"],
>
>     terms:      {
>
>         one: "base one",
>
>         two: "base two"
>
>     },
>
>     templates: {
>
>         one: "The term named 'one' is set to '%one'.",
>
>         two: "The term named 'two' is set to '%two'."
>
>     },
>
>     listeners: {
>
>         onCreate: [
>
>             {
>
>                 funcName: "gpii.sandbox.variables.base.logState",
>
>                 args:     ["{that}", {expander: {func:
>> "{that}.parseTemplates"}}]
>
>             }
>
>         ]
>
>     },
>
>     invokers: {
>
>         parseTemplates: {
>
>             funcName: "fluid.transform",
>
>             args: ["{that}.options.templates","{that}.transformTemplate"]
>
>         },
>
>         transformTemplate: {
>
>             funcName: "fluid.stringTemplate",
>
>             args: ["{arguments}.0", "{that}.options.terms"]
>
>         }
>
>     }
>
> });
>
>
>> gpii.sandbox.variables.base.logState = function (that, parsed) {
>
>     console.log("\nMy friends call me '" + that.nickName + "'...");
>
>     console.log("terms -> one: " + that.options.terms.one);
>
>     console.log("terms -> two: " + that.options.terms.two);
>
>     console.log("template one: " + that.options.templates.one);
>
>     console.log("template two: " + that.options.templates.two);
>
>     console.log("one, parsed : " + parsed.one);
>
>     console.log("two, parsed : " + parsed.two);
>
> };
>
>
>> fluid.registerNamespace("gpii.sandbox.variables.child");
>>
> fluid.defaults("gpii.sandbox.variables.child", {
>
>     gradeNames: ["autoInit", "gpii.sandbox.variables.base"],
>
>     templates: {
>
>         one: "The term named one is set to '%one', also, I am a custom
>> template."
>
>     },
>
>     terms:      {
>
>         two: "child two"
>
>     }
>
> });
>
>
>> gpii.sandbox.variables.base({});
>
> gpii.sandbox.variables.child({});
>
>
When run, this demo produces output like:

My friends call me 'base'...
>
> terms -> one: base one
>
> terms -> two: base two
>
> template one: The term named 'one' is set to '%one'.
>
> template two: The term named 'two' is set to '%two'.
>
> one, parsed : The term named 'one' is set to 'base one'.
>
> two, parsed : The term named 'two' is set to 'base two'.
>
>
>> My friends call me 'child'...
>
> terms -> one: base one
>
> terms -> two: child two
>
> template one: The term named one is set to '%one', also, I am a custom
>> template.
>
> template two: The term named 'two' is set to '%two'.
>
> one, parsed : The term named one is set to 'base one', also, I am a custom
>> template.
>
> two, parsed : The term named 'two' is set to 'child two'.
>
>
Anyway, I hope that specific example is of interest to at least one other
person.

Since I learned about a handful of framework functions in my reading that
would be of use in my work, I went through the docs to see what I might
have missed in earlier reading.  It looks like the framework function
documentation
<http://wiki.fluidproject.org/display/Infusion14/Framework+API>has not yet
been migrated from the wiki.  Since I plan to review these functions in
more depth over the next few days, I would like to offer to migrate over
what we have, and add documentation for at least the undocumented functions
I already am aware of (such as *fluid.templateString*).

 Before I do that, I want to make sure I'm targeting the right place.
 This is the closest I could find in the GitHub documentation repo:
https://github.com/fluid-project/infusion-docs/blob/master/src/documents/to-do/FrameworkAPI.md

The placeholder content in that page points to a more general version of
the API docs <http://wiki.fluidproject.org/display/docs/Framework+API>
which does not include function documentation, but it still seems like the
right place.  I would appreciate quick confirmation from the team before I
start the pull request, as it will save time.

Cheers,


Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20150311/f117e4f3/attachment.html>


More information about the fluid-work mailing list