Example of template string parsing in fluid (and a comment on function docs)...
Tony Atkins
tony at raisingthefloor.org
Thu Mar 12 05:27:52 EDT 2015
Hi, All:
I have created a ticket for the tutorial here and will work on that next
week: http://issues.gpii.net/browse/GPII-1120
Cheers,
Tony
On Thu, Mar 12, 2015 at 10:21 AM, Tony Atkins <tony at raisingthefloor.org>
wrote:
> 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/
>>> 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
>>>
>>
>>
>> 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/b3bd4aab/attachment.html>
More information about the fluid-work
mailing list