creynders
commented
9 years ago I'm so excited about the progress I've made in branch next
In a nut shell: the wiring API's up and running. Not set in stone obviously, but pretty definite already.
So, there's a number of changes and new concepts. (Dropped factory for constructor)
// v0.7
context.wireView("SomeView", SomeView);
context.wireClass("someClass", SomeClass);
context.wireValue("someValue", "some value");
context.wireSingleton("someSingleton", SomeSingleton);
context.getObject("someSingleton");
context.hasWiring("someSingleton");
//v0.8
context.wire(SomeView).as.constructor("SomeView"); //will resolve to a constructor function
context.wire(SomeClass).as.producer("someClass"); //will resolve to an instance of SomeClass
context.wire("some value").as.value("someValue"); //will resolve to "some value"
context.wire(SomeSingleton).as.singleton("someSingleton"); //will resolve to "some value"
context.get("someSingleton"); //will return the SomeSingleton instance
context.has("someSingleton"); //will output `true`
//however, then things start happening.
//ALL `.as.<provider>` (and some other) methods accept a "string", an object, an array,
//parameters or any mix of those
context.wire(SomeSingleton).as.singleton("SingletonA", "SingletonB", "SingletonC"); //equals:
context.wire(SomeSingleton).as.singleton(["SingletonA", "SingletonB", "SingletonC"]); //equals:
context.wire(SomeSingleton).as.singleton({ a: "SingletonA", b: "SingletonB", c: "SingletonC"} ); //equals:
context.wire(SomeSingleton).as.singleton([["SingletonA"]], "SingletonB", {c: "SingletonC"});
//now what does this mean?
//They all share the same singleton instance
context.get("SingletonA") === context.get("SingletonB") === context.get("SingletonC");
//sometimes it's more beneficial to have separate singletons though, i.e. a "multiton"
context.wire(SomeSingleton).as.multiton("SingletonA", "SingletonB", "SingletonC");
//will create three separate singletons
//both of the above open up a ton of possibilities, where classes use the same dependencies,
//however they're named differently which boosts reuse, flexibility et cetera.
//but there's more: sometimes you want to create an instance (to configure it for example)
//at wiring-time, but you want its dependencies to be resolved lazily, that's possible now too.
var foo = new FooClass(); //it has its dependencies declared as a `wiring` object inside the prototype
context.wire(foo).as.unresolved("foo");
context.get("foo"); //will resolve its dependencies
//oh, and `get` and `has` are just as flexible as the `.as.<provider>` methods:
var result = context.get("SingletonA", ["someClass"], {view:"SomeView"});
console.log(result);
/*
output:
{
SingletonA: <SomeSingleton instance>,
someClass: <SomeClass instance>,
view: <SomeView instance>
}
*/
//but if you `get` a single key, it returns a single value
context.get("SingletonA");
//the same goes for `has`
var result = context.has("SingletonA", ["someClass"], {view:"SomeView"}, "notfound");
console.log(result);
/*
output:
{
SingletonA: true,
someClass: true,
view: true,
notfound: false
}
*/
//And if you simply want to be sure all keys have been wired:
var result = context.has.each("SingletonA", ["someClass"], {view:"SomeView"}, "notfound");
console.log(result);//outputs: false (since "notfound" is not wired)
//the same flexibility applies to `release`
context.release.wires("SingletonA")
context.release.wires("SingletonA", ["someClass"], {view:"SomeView"});
context.release.all();
//Oh, and wirings get merged.
function Foo(){
this.wiring = "a";
}
//either:
context.wire(Foo).as.singleton("foo").using.wiring("b");
var foo = context.get("foo"); //instance with "a" and "b" resolved
//or:
var foo = new Foo();
context.resolve(foo, "b"); //foo has its dependencies "a" and "b" resolved
//ah yes, wiring declarations are just as flexible:
function Foo(){
this.wiring = "a"; //resolves "a" into member "a"
this.wiring = ["a", "b"]; //resolves "a" and "b" into members "a" and "b"
this.wiring = { foo: "a", baz : "b"};//resolves "a" and "b" into members "foo" and "baz"
this.wiring=["a", {baz:"b"}];//resolves "a" and "b" into members "a" and "baz"
}Now on to tackle the rest.
I rewrote all tests, they're inside specs.
mmikeyy
So I started on the next minor/major version. I'd been thinking about 0.7.2 and what needed to be done: updating the tests, documentation and a number of patches here and there to get things better, until I suddenly realised I should be focusing on getting the next major version out instead of trying to modify 0.7 towards what I'd really want.
So, here's what's happening: I'm trying to
wireVieworwireCommand. Of course it will still be possible to wire views, commands et cetera. But just as we have nowireModelI think it's beneficial to make Geppetto a more flexible library which can be used in a MVC, MVVM, MyOwnCustomWhateverConcept w/o having the feeling of trying to fit a square peg in a round hole. As implied in #86 this could be potentially a powerful approach and selling point. To achieve this it's necessary to make the Geppetto concepts dedicated and not adhere to another paradigm. Obviously the role of the documentation will be to show the way on how to use it in an MVC or similar context.Forgive me the convoluted example, but I tried to cover as much ground as possible. I think most of it is pretty self-explanatory if you're familiar with the current version. Obviously everything that's done using the context API here, can be configured inside your components as well: wiring, handlers, et cetera. As you can see views are no longer wired as "view", but as factory. And
wireClassis replaced withas.producerwhich is a better fitting term, IMO. There's a new concept as well, "providers":Now, what's this all about? ATM Geppetto contexts allow for registering objects as singletons, values, ... but I wanted to allow developers to create their own types. E.g. the above example would allow maintaining a list of all
Requesterinstances. Theprovidemethod receives anItemClass, which in this case isRequester. It creates a new instance and stores it in a queue. TheSomeServiceclass is totally oblivious to whether it's receiving a singleton instance, or anewinstance, or (in this case) anewinstance which is stored in a queue. As you can see theContext#providemethod accepts a string which is used to expand the context API. I passed 'queue' to it, which adds aqueuemember towire.as. This allows for extremely powerful and versatile concepts and patterns. E.g. I can imagine use cases for an "object pool" or "cyclic" provider for instance.initializemethod which allows for a better life cycle as well:constructor: pre-resolution,initialize: post-resolution.Well, that's about it FTM. As always, @geekdave please pull the reigns if I'm off into cuckoo-land.