Frameworks, formatters, and drivers should register themselves.

[jejacks0n]

I'm still in the process of defining how frameworks will register themselves, but I came across a similar concept in https://github.com/modeset/teaspoon/blob/master/lib/teaspoon/formatters/base.rb#L6, and think we might as well make 1.0 about extending teaspoon.

I still want to keep it relatively simple and only break out the different frameworks, but at a core level we can begin to define and utilize an API layer that would allow additional drivers and formatters to register themselves too.

[jejacks0n]

@mikepack this is what I'm going to tackle next. You should be good to go on the javascript changes you want to make.

[mikepack]

You have most of the ruby side done, right? I'm getting to the point where I need to register the framework in JS. I'm wondering if we should keep it super simple:

On boot (initialize.coffee), the framework registers itself with core via something like:

Teaspoon.framework = Teaspoon.Jasmine2

Core would then assume a conventional structure for the framework, so:

reporter = Teaspoon.framework.Console

and eg:

if Teaspoon.framework.Reporters?.HTML?.SpecView
  @reportView = new Teaspoon.framework.Reporters.HTML.SpecView(spec, @)
else
  @reportView = new Teaspoon.Reporters.HTML.SpecView(spec, @)

The alternative seems way more complicated where each class type of registered with core or core provides a series of hooks for all situations where a framework might override a default.

Thoughts?

[jejacks0n]

I haven't thought about it much, but it doesn't need to be as complex as the ruby framework implementation -- because the ruby side determines which javascripts, and thus which framework to load.

That makes me think we can do a single interface for registering the setup (initializer) and the reporters. If we do that nicely, by specifying a scope or something, teaspoon can figure out which reporter to use given it's core setup (in the current case that's just specifying the reporter=Console param, but we could change that to make more sense -- to scope=console or something), and then load the reporter that was specified for the given scope. To be honest, it might be worth having a discussion about restructuring that so we're not using that param on the client as well but that might not have much value.

The implementation is up to you, and those are just my thoughts.