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 < [email protected]> 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 - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work >
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
