FLUID-6112: add a Developer Introduction to core concepts of Infusion #114

waharnum · 2017-01-16T22:56:29Z

JIRA: https://issues.fluidproject.org/browse/FLUID-6112

This is a document for Infusion 2.0 in the style of https://wiki.fluidproject.org/display/docs/Developer+Introduction+to+Infusion+Framework; it stays away from the pre-built components entirely (those might be covered in another, similar document) in favour of explaining some of the most important core framework concepts. It assumes a developer has some experience with Javascript development and jQuery.

I've used CodePen at each stage for a live code example of what's being demonstrated.

Tear it up, because we want this to be useful for people who haven't worked with the framework before. :)

michelled · 2017-01-17T00:25:50Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+IoC references allow us to refer to other parts of a component object (or another component entirely) in a declarative, context-specific manner, with `{that}` standing in for the current component configuration.
+
+We can use a listener definition, the `onCreate` lifecycle event and IoC `{that]` to have a component say hello when it's ready, rather than needing to be manually called:


typo on this line '{that]'

the-t-in-rtf · 2017-01-17T09:42:43Z

As the display of mixed HTML/markdown paragraphs is broken on GitHub, I am reviewing in docpad. My first question is, where will this live? It's not linked into any of the top level categories at the moment.

the-t-in-rtf · 2017-01-17T09:49:29Z

I'm getting the idea that this is meant to be a tutorial? It should be linked there. In any case, IMO it would be better to break this down into separate pages with a shared table of contents. For example, I think there's too big a gap between the first principles introduced and the summary. If you were to restructure into smaller pages, each page would hold part of the summary, and you could shorten each point in the overall summary and link to the section that demonstrates the principle.

If you break it out into sections, you also have more room to link to background information on general concepts we are applying (I will comment inline with examples).

the-t-in-rtf · 2017-01-17T09:49:56Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+The introduction assumes you are familiar with the basics of [JavaScript](https://developer.mozilla.org/en-US/docs/Learn/JavaScript) development, and with using a browser's [developer tools](https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_are_browser_developer_tools). You should also have some experience of the [jQuery](https://jquery.com/) JavaScript library that Infusion is built on top of.
+
+We will present an increasingly complicated "Hello, World!" implementation to demonstrate the core concepts, with live examples throughout using the [CodePen](http://codepen.io/) service.


"complex" seems better than "complicated" here.

the-t-in-rtf · 2017-01-17T09:52:29Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+### Summing Up
+
+This elaborate "Hello, World!" implementation has slowly introduced some of Infusion's core features. To summarize:


Perhaps "moderately complex" instead of "elaborate" would be better here. Also, "introduces" rather than "has slowly introduced" seems better.

the-t-in-rtf · 2017-01-17T09:53:16Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+This elaborate "Hello, World!" implementation has slowly introduced some of Infusion's core features. To summarize:
+
+* We implement our programs by designing [components](#components) that work together to provide the needed functionality. Components are Javascript objects adhering to certain syntax conventions that are created using the `fluid.defaults` function. While components have defaults, any of these defaults can be overriden at the time a specific instance of the component is created.


As I mentioned in my global comment, if you break things down by sections, you can expand on each concept within the section, and then use a condensed version here, linked to the expanded definition.

the-t-in-rtf · 2017-01-17T09:54:12Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+A new Infusion component is defined using the `fluid.default` function and a very basic "Hello, World!" component might look like this:
+
+<div class="infusion-docs-note">You can check out the [Live Example](http://codepen.io/waharnum/pen/oBYvwx?editors=1111) of the code below on [CodePen](http://codepen.io/)</div>


None of the codepen examples worked for me when I tested, seems to be a problem on their end.

the-t-in-rtf · 2017-01-17T09:55:53Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+});
+```
+
+Then, from the console, we'll use the ChangeApplier to change the model; notice how the modelListener we defined responds to the change and updates the message again:


Highlight ChangeApplier in backticks.

the-t-in-rtf · 2017-01-17T09:56:42Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+```
+
+Right now this component doesn't do anything new, but we will evolve its definition throughout this introduction to demonstrate further core concepts of the framework.
+


As an example, this would be a natural point for a section/page break.

the-t-in-rtf · 2017-01-17T09:58:52Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+### Models and Model Components
+
+Mutable data is expected to be stored on a component's [model](/infusion/development/FrameworkConcepts.md#model-objects). Component models in Infusion are altered through the [ChangeApplier](/infusion/development/ChangeApplier.md) functionality, which works to:


This needs to be fleshed out more. We obviously use non-model mutable data (member variables) all the time. Also, assume they might not have familiarity with MVC or what's good to put in a model, a link and a sentence summary would be helpful.

the-t-in-rtf · 2017-01-17T10:01:43Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+```
+var helloWorld = fluid.helloWorld({});
+helloWorld.sayHello();
+```


At the risk of making this too complex, IMO it would be good to demonstrate how an invoker can be overridden.

the-t-in-rtf · 2017-01-17T10:03:43Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+### Restructuring Infusion Components
+
+Infusion's configuration-oriented components make it easier to restructure code, especially as component configuration becomes unwieldy. In the example below, we extract the two "say hello" components into separate component definitions from the main component, then include them as subcomponents of the main component. We've also added a listener to the main component to announce (once) when it is finished creation.


"it is finished creation" seems odd. Perhaps "its creation is complete"?

the-t-in-rtf · 2017-01-17T10:05:11Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+});
+```
+
+### Using Invokers for Polymorphic Behaviour and Refactoring to Reuse Configuration


If you're going to use the word "polymorphic" multiple times in the doc, you should really have more than a deep dive link into our docs on the subject. A sentence summary of what we mean and a link to a WikiPedia article on the topic would be nice.

Or perhaps just add another link to "our" coverage of the subject here, you have one near the other references.

In thinking about this and reading the Wikipedia article, I removed all mentions of it in favour of simply talking about invoker/function overriding.

the-t-in-rtf · 2017-01-17T10:06:50Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+    // except for its implementation in the invoker
+    gradeNames: ["fluid.helloWorld.sayHello"],
+    invokers: {
+        sayHello: {


I commented earlier about demonstrating overriding. Mentioning it at the end of the "invokers" section and linking to this section would be a good way to handle that.

the-t-in-rtf · 2017-01-17T10:13:06Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+* Components can include [subcomponents](#subcomponents-and-model-relaying), and use [model relaying](#subcomponents-and-model-relaying) to keep state synchronized between different components in larger designs. Many kinds of model relays are possible aside from two-way synchronization.
+* As program designs evolve, Infusion's configuration-oriented components make it easier to [restructure a design](#restructuring-infusion-components) by splitting out functionality into multiple components and wiring them together through IoC references.
+* When it becomes clear two components have similar behaviour, Infusion's design helps in [refactoring to share functionality](##using-invokers-for-polymorphic-behaviour-and-refactoring-to-reuse-configuration) through the use of invokers and base grades.
+* Infusion has strong supports for [multimodal implementations](#adding-further-ways-of-saying-hello) that allow programs to adapt themselves to new contexts for input and presentation.


The summary needs a bit of work. As I've stated elsewhere, by this point you should be summarizing in much less detail, and linking back to the topic if people want to refresh their memory.

You should also really end with a "next steps" section, give them an idea of what they might do to continue learning from this point. Even something as simple as encouraging them to join the community and linking to those docs would be a good start.

I'm also noticing that we don't really make it easy to close the loop. We should end most tutorials with some idea of how to give feedback. If we say it only in introductory material, people are likely to forget it if they have questions or find errors while reading the actual tutorial.

waharnum · 2017-01-18T12:46:08Z

@the-t-in-rtf, thanks for all the comments - I think splitting it out into separate pages is entirely appropriate. I'd begun writing this as a short one-pager, and then it sort of evolved as I decided it needed to have code examples to illustrate the comments.

I'll be working on revisions in the next day or so once others have had a chance to comment.

amb26 · 2017-01-31T15:00:59Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+# Introduction
+
+Here we will boil down some of the basic concepts of Infusion for developers who may be interested in it, but uncertain of where to start. There's a lot going on in the framework, but grasping some core ideas helps a great deal in moving forward and learning.


Really great work on this tutorial, WWAHHARNNUM!

amb26 · 2017-01-31T15:01:30Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+After definition, instances of the component can be created by calling the component's name as a function, with the option to pass in further configuration options as an argument:
+
+```
+var helloWorld = fluid.helloWorld({});


You can leave out the {} since there are no options

amb26 · 2017-01-31T15:03:54Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+Programs using Infusion structure their data, functionality and interaction as various components defined using a common syntax.
+
+Components are [regular JavaScript objects that have certain characteristics](/infusion/development/UnderstandingInfusionComponents.md). Components can be freely combined together to form new components using the [grades system](/infusion/development/ComponentGrades.md), or organized into relationships with one another via [subcomponents](/infusion/development/SubcomponentDeclaration.md).


Not sure what it really adds to say that they are "regular JavaScript objects", but I guess it's the kind of thing that people say. You might want to say something, even at this early stage, about how they have their lifetime and scoping managed by the framework. Whilst you could say they are "a bit regular" they are not, for example, plain JSON-equivalent objects since (at least for the last couple of years) they have a non-default prototype supplied via Object.create().

amb26 · 2017-01-31T15:04:15Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+
+Component-based development emphasizes declarative configuration, loose coupling and flexible hierarchies.
+
+A new Infusion component is defined using the `fluid.default` function and a very basic "Hello, World!" component might look like this:


typo, should be fluid.defaults

amb26 · 2017-01-31T15:06:30Z

src/documents/to-do/DeveloperIntroductionToInfusionFramework.md

+});
+```
+
+### Restructuring Infusion Components


Good example - since my first thought on reading the previous section was, "These definitions should be extracted as grades" : P

…gement by framework.

jobara · 2017-07-10T20:36:28Z

...tutorial-developerIntroduction/DeveloperIntroductionToInfusionFramework-ConcludingRemarks.md

+We'll summarize what we've done below, then suggest some next steps.
+
+<div class="infusion-docs-note"><strong>Note:</strong> If you have feedback about this tutorial, we'd be glad to hear it via our <a href="https://wiki.fluidproject.org/display/fluid/IRC+Channel">IRC channels</a>, <a href="https://wiki.fluidproject.org/display/fluid/Mailing+Lists">mailing lists</a> or a <a href="https://github.com/fluid-project/infusion-docs/issues">GitHub issue on the documentation repo</a></div>
+


I wonder if we'd prefer to have them file issues in JIRA instead. It is something to think about if we want to use the separate github issue tracker, but we have been keeping most things in JIRA.

I vaguely recall I had some rationale based on a conversation with someone about asking to file documentation issues in the GitHub tracker, but I cannot for the life of me remember the details, or if this conversation actually occurred. I'll update it to point to the JIRA tracker instead.

jobara · 2017-07-10T20:37:02Z

...tutorial-developerIntroduction/DeveloperIntroductionToInfusionFramework-ConcludingRemarks.md

+
+## Summing Up
+
+* We implement our programs by designing [components](DeveloperIntroductionToInfusionFramework-Components.html) that work together to provide the needed functionality. Components are Javascript objects adhering to certain syntax conventions that are created using the `fluid.defaults` function. While components have defaults, any of these defaults can be overriden at the time a specific instance of the component is created.


References to other documentation pages should all point at the MD version, same throughout.

Thanks for catching this issue - they should all be fixed now.

waharnum · 2017-07-10T20:58:28Z

@jobara regarding the redirect, on the docs platform we have one link currently in SetUpYourEnvironment.md that points to the to-do document location. I'm not sure if there might be other external ones.

I'd feel fine about eliminating the redirect and changing the link from SetUpYourEnvironment.md. Or possibly removing it, as it may not be a relevant link any more from another tutorial (the document referred to used to be much shorter). Thoughts?

jobara · 2017-07-11T12:57:54Z

@waharnum okay, lets remove the redirect for now. If it becomes an issue we can think of ways to address it. Regarding the link in the SetUpYourEnvironment.md, what is the difference between the getting started tutorial and the developer introduction? Does the latter expand on the former?

waharnum · 2017-07-14T20:23:55Z

@jobara I've removed the redirect and (per our conversation) the link from the "Getting Started" tutorial.

waharnum · 2017-07-18T14:04:43Z

@jobara missed that one, sorry - fixed now.

jobara · 2017-07-19T15:16:08Z

...tutorial-developerIntroduction/DeveloperIntroductionToInfusionFramework-ConcludingRemarks.md

+* We implement our programs by designing [components](DeveloperIntroductionToInfusionFramework-Components.md) that work together to provide the needed functionality. Components are Javascript objects adhering to certain syntax conventions that are created using the `fluid.defaults` function. While components have defaults, any of these defaults can be overriden at the time a specific instance of the component is created.
+* Components use [invokers](DeveloperIntroductionToInfusionFramework-Invokers.md) to expose functionality "publicly", provide a consistent API for collaboration with other components or use by other code, and enable function overriding when deriving new components from existing ones.
+* All components support [events and inversion of control](DeveloperIntroductionToInfusionFramework-EventsAndInversionOfControl.md); these allow our programs to be built up of loosely coupled parts, and to manage sequencing through components observing and responding to their own events or the events of other components.
+* Components that need to track mutable data, state or content should be [model components](DeveloperIntroductionToInfusionFramework-ModelsAndModelComponents.md); model components can coordinate and synchronize their data with other model components, fire events when their models are changed, and take other actions to store and respond to state changes. Model components can use [model listeners](DeveloperIntroductionToInfusionFramework-ListeningToModelChanges.md) to respond to changes in model state.


The "model listeners" link is broken.

jobara · 2017-07-19T15:18:31Z

...tutorial-developerIntroduction/DeveloperIntroductionToInfusionFramework-ConcludingRemarks.md

+
+* Get [your own copy of Infusion from our GitHub repository](https://github.com/fluid-project/infusion).
+* Read about the [framework concepts](/FrameworkConcepts.md) to learn more about Infusion's design goals and overall philosophy.
+* Read [further documentation on Infusion](/), including many advanced topics not covered here such as [using Infusion in node.js](/NodeAPI.md), [advanced features of model transformation](/ModelTransformationAPI.md) and [unit testing](/jqUnit.md).


All of the relative links in the "Where to Go Next?" section are broken. Probably because they are relative to the infusion docs and not the tutorials.

jobara · 2017-07-19T15:25:19Z

...ts/tutorial-developerIntroduction/DeveloperIntroductionToInfusionFramework-OpeningRemarks.md

+
+Here we will boil down some of the basic concepts of Infusion for developers who may be interested in it, but uncertain of where to start. There's a lot going on in the framework, but grasping some core ideas helps a great deal in moving forward and learning.
+
+This introduction summarizes some topics (and leaves out many others) that are gone into at length in the [full framework documentation](/), and is focused on developers trying to orient themselves to the framework for the first time.


"Full framework documentation" link is broken

May only be broken in the github view.

jobara · 2017-07-19T15:26:56Z

...ts/tutorial-developerIntroduction/DeveloperIntroductionToInfusionFramework-OpeningRemarks.md

+
+3. [Events and Inversion of Control](DeveloperIntroductionToInfusionFramework-EventsAndInversionOfControl.md) to allow our programs to be built out of loosely coupled parts, and to manage sequencing and lifecycle throughout that loosely coupled structure.
+
+4. [Model Components](DeveloperIntroductionToInfusionFramework-ModelsAndModelComponents.md) that can track mutable data, state or content, and coordinate and synchronize their data with other model components and fire events when their state changes. [Model Listeners](DeveloperIntroductionToInfusionFramework-ListeningToModelChanges.md) are used to respond to changes in model state.


"Model Listeners" link is broken

waharnum · 2017-07-19T16:32:05Z

@jobara I've fixed the link issues you've noted.

Regarding the "Getting Started With Infusion" (http://docs.fluidproject.org/infusion/development/tutorial-gettingStartedWithInfusion/GettingStartedWithInfusion.html) tutorial and this one, I've got the following observations:

"Getting Started" presumes development on a local environment; the new tutorial uses Codepen to allow someone to try out Infusion without having to install anything locally
"Getting Started" encourages the use of the Renderer; the new tutorial stays away from the topic
I (personal opinion) think the "Getting Started" tutorial is more complex than the new one, in terms of introducing the core Infusion concepts.

What I'd propose for now is renaming "Getting Started" to something like "Getting Started with Infusion Component Design" - a lot of the material is about component design choices and figuring out which are appropriate (very valuable material, in more detail than what's in the new tutorial). We can keep the file names the same to avoid losing links from other places and the relationship between the tutorials is more clear.

Longer term (after the new Renderer, perhaps), I think we should rewrite the tutorial to be a more advanced coverage of building Infusion-based applications.

How does that sound?

jobara · 2017-07-19T20:04:08Z

@waharnum that seems reasonable to me.

waharnum · 2017-07-24T14:50:14Z

@jobara I've renamed the Getting Started tutorial accordingly and made a few changes to the wording of the opening to make it clearer by comparison to the Developer Introduction - have a look and let me know your thoughts?

jobara · 2017-07-24T16:28:31Z

src/documents/tutorial-gettingStartedWithInfusion/BasicComponentCreation-Components.md

-You'll notice that in this case we have been able to avoid binding to the entire component instance in our public function, and so our standalone public function `tutorials.currencyConverterAuto.convert` 
-is of more general utility than just for building a component method. 
+You'll notice that in this case we have been able to avoid binding to the entire component instance in our public function, and so our standalone public function `tutorials.currencyConverterAuto.convert`
+is of more general utility than just for building a component method.


Could you fix the bug in the code example code that this refers to. The function takes in exchangeRate but then uses that.options.exchangeRate internally.

jobara · 2017-07-24T18:14:51Z

@michelled did you finish looking over the content of this PR, is it okay to go in from the stand point. I think I've finished reviewing the structural/syntax parts now.

michelled · 2017-07-24T18:16:16Z

Yep, I'm happy with it!

jobara · 2017-07-24T18:55:43Z

Merged at aa4b061

waharnum added 6 commits January 13, 2017 15:57

FLUID-6112: commit current work.

2308c7b

FLUID-6112: restructuring flow.

6644039

FLUID-6112: updating code.

253185a

FLUID-6112: updating code.

e06ea98

FLUID-6112: add TTS component at end, other revisions.

703da65

FLUID-6112: add CodePen for each example; add a summing-up section.

de5e063

michelled reviewed Jan 17, 2017

View reviewed changes

the-t-in-rtf reviewed Jan 17, 2017

View reviewed changes

amb26 reviewed Jan 31, 2017

View reviewed changes

waharnum added 3 commits March 7, 2017 15:04

FLUID-6112: typo correction.

0cba5b9

FLUID-6112: move into navigation section.

9060bec

FLUID-6112: comment per @amb26's feedback on component lifecycle mana…

a45c9f2

…gement by framework.

jobara reviewed Jul 10, 2017

View reviewed changes

waharnum added 2 commits July 10, 2017 16:51

FLUID-6112: convert internal .html links to .md links.

4c11964

FLUID-6112: GitHub issue tracker -> JIRA.

81b1436

waharnum added 2 commits July 10, 2017 16:59

FLUID-6112: convert internal .html links to .md links.

ad4ac25

FLUID-6112: convert internal .html links to .md links.

d2b4e29

FLUID-6112: remove redirect / to-do.

973de3a

FLUID-6112: fix extra whitespace.

2f98cb7

jobara reviewed Jul 19, 2017

View reviewed changes

waharnum added 3 commits July 19, 2017 12:11

FLUID-6112: fix various links, esp. in GitHub markdown view.

0c81718

FLUID-6112: fix another link.

5d5f34d

FLUID-6112: fix another link.

1c10643

waharnum added 2 commits July 24, 2017 10:44

FLUID-6112: renaming 'Getting Started' tutorial.

7610019

FLUID-6112: renaming 'Getting Started' tutorial.

e739dec

jobara reviewed Jul 24, 2017

View reviewed changes

FLUID-6112: fix issue in code example.

4d63044

jobara merged commit 4d63044 into fluid-project:master Jul 24, 2017


		IoC references allow us to refer to other parts of a component object (or another component entirely) in a declarative, context-specific manner, with `{that}` standing in for the current component configuration.

		We can use a listener definition, the `onCreate` lifecycle event and IoC `{that]` to have a component say hello when it's ready, rather than needing to be manually called:


		The introduction assumes you are familiar with the basics of [JavaScript](https://developer.mozilla.org/en-US/docs/Learn/JavaScript) development, and with using a browser's [developer tools](https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_are_browser_developer_tools). You should also have some experience of the [jQuery](https://jquery.com/) JavaScript library that Infusion is built on top of.

		We will present an increasingly complicated "Hello, World!" implementation to demonstrate the core concepts, with live examples throughout using the [CodePen](http://codepen.io/) service.


		### Summing Up

		This elaborate "Hello, World!" implementation has slowly introduced some of Infusion's core features. To summarize:


		This elaborate "Hello, World!" implementation has slowly introduced some of Infusion's core features. To summarize:

		* We implement our programs by designing [components](#components) that work together to provide the needed functionality. Components are Javascript objects adhering to certain syntax conventions that are created using the `fluid.defaults` function. While components have defaults, any of these defaults can be overriden at the time a specific instance of the component is created.


		A new Infusion component is defined using the `fluid.default` function and a very basic "Hello, World!" component might look like this:

		<div class="infusion-docs-note">You can check out the [Live Example](http://codepen.io/waharnum/pen/oBYvwx?editors=1111) of the code below on [CodePen](http://codepen.io/)</div>

		```

		Right now this component doesn't do anything new, but we will evolve its definition throughout this introduction to demonstrate further core concepts of the framework.


		### Models and Model Components

		Mutable data is expected to be stored on a component's [model](/infusion/development/FrameworkConcepts.md#model-objects). Component models in Infusion are altered through the [ChangeApplier](/infusion/development/ChangeApplier.md) functionality, which works to:


		### Restructuring Infusion Components

		Infusion's configuration-oriented components make it easier to restructure code, especially as component configuration becomes unwieldy. In the example below, we extract the two "say hello" components into separate component definitions from the main component, then include them as subcomponents of the main component. We've also added a listener to the main component to announce (once) when it is finished creation.


		# Introduction

		Here we will boil down some of the basic concepts of Infusion for developers who may be interested in it, but uncertain of where to start. There's a lot going on in the framework, but grasping some core ideas helps a great deal in moving forward and learning.


		Programs using Infusion structure their data, functionality and interaction as various components defined using a common syntax.

		Components are [regular JavaScript objects that have certain characteristics](/infusion/development/UnderstandingInfusionComponents.md). Components can be freely combined together to form new components using the [grades system](/infusion/development/ComponentGrades.md), or organized into relationships with one another via [subcomponents](/infusion/development/SubcomponentDeclaration.md).


		Component-based development emphasizes declarative configuration, loose coupling and flexible hierarchies.

		A new Infusion component is defined using the `fluid.default` function and a very basic "Hello, World!" component might look like this:

		We'll summarize what we've done below, then suggest some next steps.

		<div class="infusion-docs-note"><strong>Note:</strong> If you have feedback about this tutorial, we'd be glad to hear it via our <a href="https://wiki.fluidproject.org/display/fluid/IRC+Channel">IRC channels</a>, <a href="https://wiki.fluidproject.org/display/fluid/Mailing+Lists">mailing lists</a> or a <a href="https://github.com/fluid-project/infusion-docs/issues">GitHub issue on the documentation repo</a></div>


		## Summing Up

		* We implement our programs by designing [components](DeveloperIntroductionToInfusionFramework-Components.html) that work together to provide the needed functionality. Components are Javascript objects adhering to certain syntax conventions that are created using the `fluid.defaults` function. While components have defaults, any of these defaults can be overriden at the time a specific instance of the component is created.


		Here we will boil down some of the basic concepts of Infusion for developers who may be interested in it, but uncertain of where to start. There's a lot going on in the framework, but grasping some core ideas helps a great deal in moving forward and learning.

		This introduction summarizes some topics (and leaves out many others) that are gone into at length in the [full framework documentation](/), and is focused on developers trying to orient themselves to the framework for the first time.


		3. [Events and Inversion of Control](DeveloperIntroductionToInfusionFramework-EventsAndInversionOfControl.md) to allow our programs to be built out of loosely coupled parts, and to manage sequencing and lifecycle throughout that loosely coupled structure.

		4. [Model Components](DeveloperIntroductionToInfusionFramework-ModelsAndModelComponents.md) that can track mutable data, state or content, and coordinate and synchronize their data with other model components and fire events when their state changes. [Model Listeners](DeveloperIntroductionToInfusionFramework-ListeningToModelChanges.md) are used to respond to changes in model state.

FLUID-6112: add a Developer Introduction to core concepts of Infusion #114

FLUID-6112: add a Developer Introduction to core concepts of Infusion #114

Conversation

waharnum commented Jan 16, 2017

Choose a reason for hiding this comment

the-t-in-rtf commented Jan 17, 2017

the-t-in-rtf commented Jan 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

the-t-in-rtf Jan 17, 2017 • edited

Choose a reason for hiding this comment

the-t-in-rtf Jan 17, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

waharnum commented Jan 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

waharnum commented Jul 10, 2017 • edited

jobara commented Jul 11, 2017

waharnum commented Jul 14, 2017

waharnum commented Jul 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

waharnum commented Jul 19, 2017

jobara commented Jul 19, 2017

waharnum commented Jul 24, 2017

Choose a reason for hiding this comment

jobara commented Jul 24, 2017

michelled commented Jul 24, 2017

jobara commented Jul 24, 2017

the-t-in-rtf Jan 17, 2017 •

edited

the-t-in-rtf Jan 17, 2017 •

edited

waharnum commented Jul 10, 2017 •

edited