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 <[email protected]> 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 < > [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/ >>> 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 - [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
