Both use a WeakHashMap to store observers and both have an update method.
Make sure that code duplication is minimized so that it can be reused.

For consistency prefer

over

When adding oig-context element add ability to persist the context. Meaning that when the element is added to the dom again it should load the data from sessionStorage....
This means that the element somehow needs to assing a unique id that can be used as key for data storage. State of view model needs to be stored on removal of element from DOM

Let element be an instance of oig-context
Let attribute mode be persist
When element is removed from DOM then store viewModel properties inside sessionStorage
When element is appended to DOM again then preserve the viewModel without triggering Obect.observe

It's not needed to use data-oig for specifying target. binding-target is a non-existing attribute in HTML5 and is cleaner and easier to understand than using prefix data-oig

To be Refined:
Goal is to separate the DI, Object observing and viewmodel construction out of the project.
The core should not be dependant on Custom HtmlElement but just use data attributes to make it compatible with IE.

Core module should not have exports , amd or commonjs or whatsoever...that can always be added later on :-)

NB. All the custom elements like ng-if etc are not really what should be part of this small framework.
The view impl should be whatever you want it to be . eg manual dom/ template driven / two way databinding...etc)

• Needs polyfill for object.observe and array.observe (https://github.com/MaxArt2501/object-observe)
• Should be possible to construct views which can update the view when data model changes (eg. re-render a template)
• Use mutation observer to detect new view models
• Should bootstrap on DOMContentLoaded
• could also be change to use data-view="asdasd" where view-model is injected into a new view. when viewModel changes it should dispatch a change event which can be handled by the view to rerender the template
• weakMap can be used to attach viewModels to elements
• add on behaviour to delegate to viewModel
  eg. onclick="oig(event,'doSomething(name, 1)')"
  of onclick="oig.delegate(event,'doSomething(name, 1)')"
  signature:
  oig.delegate(event: Event, execute:string, viewModel?: string)
  where viewModel is optional but will delegate by default to current viewmodel
• Use TreeWalker on DOMContentLoaded and on MutationObserver to find view-model nodes
• http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-react-vs-web-components-polymer (Actually...when do we need two way binding??? yes when we have a form...so why not just have a view (code-behind) that calls the viewModel with the mutated values?
  this will make sure that only the viewmodel will update data (data flows one way)

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
In a well-designed MVVM architecture, the codebehind for most Views should be empty, or, at most, only contain code that manipulates the controls and resources contained within that view.(1)Sometimes it is also necessary to write code in a View's codebehind that interacts with a ViewModel object, such as hooking an event or calling a method that would otherwise be very difficult to invoke from the ViewModel itself.

When using oig-include then multiple requests are made for the same resource
oig.resource loader should make sure that it returns the same promise when a request is made for the same resource url

One time binding is currently not supported but mentioned in documentation
Add unit tests and examples for one time binding.

Proposal
<oig-binding binding-target="" bind="once"

Template element should support one way binding and update when viewModel/dataContext changes
This means Template Element should extend BoundElement
Also DOM only needs to be updated when the fragment is different (isSameNode ?? )

Instead of oig.Element use: OIGElement
Same -> IfElement -> OIGIfElement
That way it's more in line with HtmlElement, SVGElement etc

Some attributes like disabled do not need any value. Presence of attribute disabled actually means it's disabled regardless of the value.
Investigate list of attributes it involves and fix

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/observe

dataContext.values = [1,2,3];

When pushing a value to the array the object.observe will not work.
Somehow we need to watch arrays as well. Might need an algorithm for deep watching.

Change:

Leftover from clean up

Bindings for document and windows should be.added so that they can be injected and mocked.

Should use plain function to resolve window or.document.
Should not call new in dicontext when resolving
Will require typeparser to also parse function signatures to provide simple function binding

Add a new element named oig-repeat that can created elements based on iterating a property of the dataContext
eg.
viewModel : {
items: [{name: "John Doe"}, {name: "Jane Doe"}]
}

To improve knowledge on es6 the 6to5 transpiler could be used.
http://6to5.org/
https://github.com/6to5/gulp-6to5

When dicontext resolves and instatiates an instance it should delegate the instance and typeinfo to the protoprocessor so that annotations on methods can be processed

Example a proto has a method annotated with eg postconstruct. This method should be called after construction

Example a proto has a method annotated with event. The method should automatically be registered to the eventbus after construction

Example a method is annotated with a decoration annotation. This method should be decorated before construction.

Typeparser should be refactored to use prototype instead of being extension of object. Make it a first citizen class

Typeparser should have methods :
Hasannotation, getannotations getdecorations

Protoprocessor should have method to register custom annotations and decorations

Bind to should accept string and numbers so that properties can be injected these properties can be mutable and immutable

Bind(x).to(value).mutable()
Bind(x).to(value).immutable()
Where default should be immutable

Other options
Bind(x).toValue(y)
Or toConstant(y)

Create a template element that can use different template engines
Default template engine can/will be underscore microtemplating

example:

....

Also it should be possible to load external templates by using xlink:href=""
Where href can be a url or domId

When external templates are used there can be no childnodes inside the oig-template element

Setting template enginess:

Object.defineProperty(oig.templateEngines, 'dustjs', {
get() {
return {
compile: function (template, dataContext) {}
}
}
});

Add a new Custom Element oig-when to have elements rendered on page based on evaluation of expression in oig-if

When evaluated false then include the content as a comment node
Otherwise render the contents

Example:

• register as Singleton in Locator
• methods:
  • addEventListener('csv sep. list of event names', listener)
  • removeEventListener

Where listener can be:

• A function
• An instance with method handleEvent

Instead of method assignviewmodel to view pass provider argument to dicontextconstructor

So view should be injected to viewmodel and visa versa. Current implementation will throw circular dependency so that should be fixed by passing provider argument

Example: dicontext.resolve(viewmodel, {view: binding}. Where dicontext will call diconstructor and passing a provider for the current instance

This will actually solve circular dependencies in general so unit test needs to change to not throw circular dependency. Actually test should be removed

Oig view attribute will not be needed for di, only for view resolving in eg event handlers.

The element to which the viewcontext is bound should also be passed to dicontext.resolve as provider named element. That way the view dom element can also be injected

Pls use feature branch and pull requests

Circular dependencies in constructor injection is actual an anti pattern http://misko.hevery.com/2008/08/01/circular-dependency-in-constructors-and-dependency-injection/

We might need to rethink the solution maybe view needs a setter method for viewmodel or visa versa
Also viewmodel locator pattern is use in. Net

Lets discuss

To make unit testing easier pls add DI/Service Locator

Two way binding is currently not supported but mentioned in documentation
Add unit tests and examples for two way binding.

Proposal
<oig-binding binding-target="" bind="bidirectional|twoway|2way"

Value of attribute can be bidirectional|twoway|2way??
Bi-directional (2-way) binding can not be used when binding is one time binding. Therefor same attribute is used

Based on http://www.w3.org/TR/widgets/

Oig Include behaviours is still incomplete. It misses xml include fallback behaviour.
Implement by Spec: http://www.w3.org/TR/xinclude/

Let oig.context be the dependency context
Let component by the generic type of injectable
Let controller be a specialized type of component
Let service be a specialized type of component

Let oig.context.controller be a method to register controllers
Let oig.context.service be a method to register services
Let oig.context.component be a method to register components

Controller
Let default scope be prototype

Service
Let default scope be singleton

Component
Let default scope be singleton

Let name be name of controller
Let function be resolvable of controller
Let oig.contex.controller(name function) return Scope
Let Scope have two methods: singleton and prototype to override implementation
Eg.
oig.context.controller(name, function).singleton()
oig.context.controller(name, function).prototype() (Can prototype be used, ??, maybe instance())

Let API be fluent
oig.context.controller(name, function).singleton().context().service(name, function).context().service(name, function)

Registration:
When calling oig.context.controller it should register an instance in the oigLocator
Let name be test
Let resolver be DI aware resolver
oig.context.controller(name, function)
Should call oigLocator.register('controller.' + name, resolver)

DI Resolvers:
DISingletonResolver
DIInstanceResolver

Configuring dependencies
Uses comments that can be preserved by eg. uglify js
Comment parsing should only be done once (cache parsing)
function myController(/*!inject:myService/myService)

1. Create OIGViewModelResolver with method resolve(name)
   add oigLocator.register('oigViewModelResolver', function () {}) and return singleton of OIGViewModelResolver
2. Register viewModels using resolver.register(nameofviewmodel, function () { return viewModel}). This will later be replaced by DI Resolvable
3. Change partials from examples
4. add mock resolver to mocks
5. change unit tests to use resolver