sammyt / dawn Goto Github PK

Chose if a callback should be triggered by all subtypes of just concrete typed passed to the add method

Currently when building an application with Dawn you have to create a CommandMap and a Builder separately. It is good that there libraries have separate entry points, so dependency injection can be used without the commands code, but for application that want both a facade across the two classes would be convient.

interface IDawn {
  function getObject():Object;
  function addConfig(config:IConfig):void;
  function addCommand(command:Class):void;
}

for day to day development sprouts is much nicer than maven. Just dont know if it supports everything I currently rely on

Mapping notifications to a class/interface that handles it is not necessary, since the handling interface can be determined by reflecting the [InjectHandler] method

Should be able to specify within a interface what the default implementation is.

Syntax option:

[ImplementedBy(qname='uk.co.ziazoo.Builder')]
interface IBuilder {
 ...
}

or if package is the same ?

[ImplementedBy(name='Builder')]
interface IBuilder {
 ...
}

Providers cant have dependencies at the moment, this is a bit of a limit for the provider idea

Need a get started guide, but in the mean time some docs or a blog on how to create a basic project would do the trick

Can begin by extending the PersonManager

Need some names for the framework as a whole (could stick with Beckys inspited boogawooble) and for the major components

The two main parts are:

• The Notification code
• The IOC code

could just go with notifier and ioc, but thats a little dry?

e.g.

map(IWibble).and(IWoo).to(WibbleWoo).asSingleton()

?

[Singleton]
class WibbleService {
}

[Transient]
class WobbleService {
}

something like Guices private modules
http://pastie.org/368348

Injectors can have children and parents

var child:IInjector = injector.createChild();
var child:IInjector = injector.createChildInApplicationDomain(appDomain);

child.getParent() // return IInjector

Child injectors inherit the mappings or their parent. Mappings on the child stay in the child and do not filter up to the parent

Currently only accessor based injection is supported, want to add constructor injection. It is currently not in the framework as the actionscript reflection api does not provide type information for constructor arguments.

Perhaps metadata could be used to explain the types and order of the constructors arguments

Something like

[Inject]
[Named(arg=doThing,name="DoOneThingImpl")]
class MyThing {
    function constructor( doThing:IDoOneThing, doAnother:IDoAnother){}
}

Need to check if the order of metadata is preserved, such that adding order to the metadata would be unnecessary.

Fussy is designed for this purpose, it will increase speed and allow for better error reporting

These exist but need to be exposed.

map(IWibble).to(Wobble).inScope(myScope);

need much more error checking to help people debugging incorrect mappings

Could define optional methods that are called before and after a managed object has its dependencies set. These methods could be identified by metadata so no compile time dependence is created

[DependenciesInjected]
function callMeWhenIHaveMyDependencies():void{}

asEagerSingleton will create the object before it is requested directly or as a dependency. This could be useful in creating a service object that can cache some data from the server before the view that needs it is created

currently cant remove handlers, get round to it you slacker

provide a quick way to add mappings to Dawn without having to implement IConfig

var dawn:Dawn = new Dawn();
dawn.map( IThing ).toClass( Thing )

Sometimes it will make sense for the user to create objects themselves, perhaps there are required constructor arguments of the object already exists.

Providers will fill the gap, allowing the ioc library to delegate some objects creation to custom user code

Should providers be classes or function (or both)?

[Inject]
[Provider]
public function getThing( stuffINeed:Stuff ):Thing{}

class ThingProvider{
  function ThingProvider(){}
  [Provider] function getThing():Thing{}
  [Inject] function set somthingThatIsNeeded(value:Somthing):void{}
}

[Provider]
fuction getSomeViewObject():View{
  Application.application.someViewId;
}

mxml is none DI. Objects are directly created within markup, you cant program to an interface in mxml, this is why providers are so crucial

providers could also be used to set properties on objects, these properties could even come from external (property files) sources?

Update

Have commited a first pass at providers. Only class based at the moment

waiting on this http://github.com/sammyt/fussy/issues#issue/2

Two objects may both require an instance of IDoSomthing, but they could need different implementations. Want a neat way, preferable with metadata of specifying which is desired by any given class

• this suggests that a class should have more than one provider
• extra providers could be named, so a class may specify it wants a particular flavor of provider, but unless that flavor is named in the config it would get the default

mapping.map( IWobble, WobbleProvider );
mapping.map( IWobble, MegaWobbleProvider, "Mega" );

The class could then specify that it would like the Mega provider

[Inject(name='Mega')]
function set wobble(value:IWobble):void;

Not all objects will want to the same level of detail about every notification that is sent. For some objects it may be overkill to implement the handler interface, for these objects a a callback could be mapped to a notification type.

addCallback( notificationType:Class, callback:Function );

This project need some form or build tool, maven seems like as good a choice as any.

uk.co.ziazoo.notifier ?

The injector currently depends on as3ds, which is no longer supported in actionscript. Refactor code to use simple custom tree structure code