Answers to questions from Mike Skirpan
antranig.basman at colorado.edu
Thu Jun 16 20:23:55 UTC 2016
At his blog at https://github.com/wannabeCitizen/data-dashboard/blob/master/docs/journal/06-15-2016.md our
GSoC student Mike Skirpan has asked some chartAuthoring and Infusion-related questions which I will answer
> Registering the component's namespace. When to use it? [eg, https://github.com/fluid-project/chartAuthoring/blob/master/src/js/transformations.js ].
> It seems like it is mostly useful for creating simple helper-type components that aren't part of your main component tree.
Yes, that's correct. A call to "fluid.defaults" automatically registers the namespace of the component -
that is, it creates a function object with that global name, and creates all the parent objects necessary to
house it. You only need an explicit call to registerNamespace when
i) You have a helper function whose immediate parent name has not already been registered in the global
ii) You want to get access to an existing registration in an infusion system that is not visible in your own
visible in different files from one another)
> Use of "container" a lot without css ref, but some kind of IoC ref.
> EG, https://github.com/fluid-project/chartAuthoring/blob/master/src/js/transformations.js] How should
> one usethis keyword in infusion?
> Does it automatically refer to the container div of the given component; if so, where are you meant to
I guess you meant a site like:
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/chartAuthoring.js#L76 - this shows
setting up the selector/element from which the container of a viewComponent will be constructed. On
construction, the actually resolved container is assigned to that.container as a jQuery element - it can
then be referred to by configuration or code like any other member, e.g.
See references to the role of the container at http://docs.fluidproject.org/infusion/development/DOMBinder.html
> Would highly recommend a full example at bottom, here: http://docs.fluidproject.org/infusion/development/UnderstandingInfusionComponents.html
> So styles for a ViewComponent is only used as a sort of documentation tool?
Essentially, yes - there is no code in the framework which depends on or operates this - it is a convention
between users and implementors of the component. A similar convention is the use of a block named "markup"
to hold short-ish HTML template strings which might be passed in to fluid.stringTemplate before being slung
into the DOM via $()
> ? Example of crucial documentation that's confusing? --> "Note that as a result of growing power in the
> IoC framework toperform most actions "in place" with respect to an existing component in its original
> location without having to inject it elsewhere."
Agreed - highly confusing as well as being ungrammatical. It could better read something like "In many
cases, you will not need to inject components elsewhere in the tree since they can be effectively used in
their original position by means of IoC references (for reading) or options distributions (for modifying)".
Often you will inject components *down* the tree in order to have handy (and substitutable) references to
them via shorter paths, or inject them *up* the tree in order to promote a component to higher visibility
that is part of the implementation of some other assembly (the latter is rare)
> Renderer vs. View components -- which should I be using? I feel like I remember hearing that you're phasing
> out renderer components?
Yes, that's right. The renderer is still available for the intrepid, but in general we recommend the use of
simple schemes like string templating (as via fluid.stringTemplate mentioned above), or slightly more
complex libraries like handlebars, together with something like https://github.com/GPII/gpii-binder/pull/1
for data binding - I note that chartAuthoring has its own "micro-binding" framework at
> This is a bad set of examples: http://docs.fluidproject.org/infusion/development/SubcomponentDeclaration.html#injected-subcomponent-declaration
Yes, they are terrible - much of the material isn't even relevant, as well as being inadequately explained.
> Do you recommend using dynamic components for the Fields Component in the Data Dashboard spec?
Yes, they are a stable and indispensable facility, even they are still a little clunky to use. The "far
future" framework will allow us to image components into existence and nonexistence by a model-relay-like
> Can't find good info on templates... templateLoader
We had a Skype chat with Cindy and confirmed that this was an implementation detail of the prefs framework
that had "accidentally" leaked into public use. This should be split out into a self-contained file and
documented properly. In our call we traced through the implementation workflow involving the deprecated
https://github.com/fluid-project/infusion/blob/master/src/framework/core/js/FluidRequests.js#L53 and the
> In the chartAuthoring demo component, how does initialData get taken from the demo component and
> rendered? Can't follow this trail and its crucial to understanding everything...
In our Skype chat and the following discussion on IRC
https://botbot.me/freenode/fluid-tech/2016-06-16/?msg=68049015&page=1 we established that the chartAuthoring
component's workflow this is currently rather wacky, in that it reuses in the demo what should be an
implementation detail of the dataEntry component in order to round-trip the model data through the DOM in
order to get it into the model. That is,
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/chartAuthoring.js#L279 loads the data
into the entry UI from where the data binding facilities in
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/valueBinding.js fish it back out into the
dataEntry component's model. We agreed that this should be refactored in chartAuthoring but this will take a
little while (need to get Alan's big pull in first). You're free to try using the component's changeApplier
directly to update its model - if you run into any problems, we will straighten them out.
Thanks for this excellent set of questions and observations - this is code that we're keen to make highly
usable and greatly appreciate anything which might flatten out the learning curve for others. Looking
forward to developments -
More information about the fluid-work