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