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

Tony Atkins tony at raisingthefloor.org
Thu Mar 12 05:21:27 EDT 2015


Hi, Antranig:

Certainly.  I generally set aside a little time each morning for things
like this, and will put the tutorial on my calendar for early next week.

Cheers,


Tony

On Wed, Mar 11, 2015 at 6:01 PM, Antranig Basman <
antranig.basman at colorado.edu> wrote:

> Thanks for taking the time to write this up, ADTKINS - it will be very
> helpful to other uses of the API. Do you think you might have time to make
> a markdown pull request for a mini-tutorial with the contents of the main
> section of this mail?
>
> We have a growing set of tutorials in our github docs such as this one -
> https://github.com/fluid-project/infusion-docs/blob/
> master/src/documents/tutorial-userInterfaceOptions/UserInterfaceOptions.md
>
> As for the Framework Function API - there has been work on producing an
> automatically generated version of this from the code and doc comments by a
> certain S. Githens - unfortunately the integration work for publishing this
> along with our main docs site appears to have stalled. Perhaps some of the
> OCAD team could chime in with an update of where this work currently stands
> - I know that Steve has said he would be happy to complete the work at his
> end if we can give him a summary of what we need from him before we can
> make this work live.
>
> I'm not sure which repo the doc generator lives in, sgithens - has it been
> checked in?
>
> Cheers,
>
> A
>
>
> On 11/03/2015 11:00, Tony Atkins wrote:
>
>> 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/033d9eadea896f43d640e5f386b2d8
>> f59753ad75
>>
>> 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
>>
>
>
> Nb - stringTemplate, not templateString
>
>  /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
>>
>>
>>
>>
>>
>>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20150312/0bf50029/attachment.html>


More information about the fluid-work mailing list