Spring Actionscript, Dawn, SmartyPants, Swiz, Spicelib (used by Parsley) and SwiftSuspenders (used by Robotlegs) perform Dependency Injection.
Moreover they can all perform automatic DI by parsing class metadata. It would be grand if the common DI related metadata tags could be standardised. That way we really could write code that is decoupled from any particular framework.
Dawn, Swiz, Spicelib, SwiftSuspenders, SmartyPants: [Inject] (above property, setter or method)
Spring AS: [Autowire] (above property, setter or method)
[Inject] by 5
[Inject] is clear and simple and used by almost all of the libraries. It also directly correlates to @Inject from the JSR-330 Dependency Injection for Java specification. Let’s use it.
Dawn, SwiftSuspenders, SmartyPants: [Inject(name=“SomeName”)] (above property, setter or method)
Swiz: [Inject(source=“SomeName”)] (above property, setter or method)
Spicelib: [Inject(id=“SomeName”)] (above property, setter or method)
Spring AS: [Autowired(name=“SomeName”)] (above property, setter or method)
[Inject(name=“SomeName”)] by 3
Since you can define default attributes best practice could be to leave out the attribute: [Inject(“SomeName”)]
SwiftSuspenders comment: While there might, in the future, be demand for more named parameters, “name” is certain to be the most frequently used one. Thus, SwiftSuspenders will adapt this proposal as a supported feature and document it as best practice.
SmartyPants: [Inject(live)] (above property, setter or method)
SwiftSuspenders: Not yet supported
Spicelib, Swiz, Spring AS, Dawn: ?
[Inject(live)] by 1
SwiftSuspenders comment: SwiftSuspenders will support live injections in a future release. When that happens, we will adopt the “live” parameter used by SmartyPants.
SwiftSuspenders: [Inject] (optional, above class)
Spicelib: [InjectConstructor] (above class)
Swiz, Spring AS, Dawn: ?
?
I don’t see the need for an extra tag ([InjectConstructor]) when we could simply use [Inject].
SwiftSuspenders comment: Metadata annotation for constructors is only required if the injection is to be parameterized in some way, i.e., if one or more of the constructor’s dependency should be named. Otherwise, injection will just work.
SmartyPants: Not directly supported, but implied by [Inject(live)]
SwiftSuspenders: Not yet supported
Spicelib, Swiz, Spring AS, Dawn: ?
?
SwiftSuspenders comment: We propose to use [Inject(optional)] for optional injections, i.e. for injections that don’t make the injection throw if now mapping is found for the dependency. A future release of SwiftSuspenders will likely support this.
Additionally, we propose to let [Inject(live)] imply [Inject(optional)] as SmartyPants does.
Dawn, SwiftSuspenders, SmartyPants, Swiz: [PostConstruct] (above method)
Spicelib: [Init] (above method)
[PostConstruct] by 4
@PostConstruct is used in Java for the same purpose. Let’s use the most popular, established one.
SwiftSuspenders comment: SwiftSuspenders supports the – optional – parameter “order”, enabling the ordered invocation of multiple PostConstruct-annotated methods. As this is also used in Java for the same purpose, we propose to adopt it as a standard, too.
SwiftSuspenders, SmartyPants, Dawn: none?
Swiz: [PreDestroy] (above method)
Spicelib: [Destroy] (above method)
@PreDestroy is used in Java for the same purpose. Let’s use the most familiar, established one.
SwiftSuspenders comment: SwiftSuspenders will likely gain support for full Livecycle management in version 2. If and when that happens, we will adopt the [PreDestroy] annotation.
SwiftSuspenders, SmartyPants, Swiz: none?
Dawn: [Provider] (above method)
Spicelib: [Factory] (above method)
SwiftSuspenders comment: SwiftSuspenders will most likely gain full support for factory injection in version 2. If and when that happens, we will adopt the [Factory] annotation (most likely with some optional parameters, which are to be determined).
Swiz and Spring AS: [EventHandler] above method
Spicelib: [MessageHandler] (not specifically aimed at events)
Dawn, SwiftSuspenders, SmartyPants: ?
[EventHandler] by 1 or 2, depending on your perspective
For example:
[EventHandler(name="login, type="domain.events.LoginEvent")]
public function handleLogin (event:LoginEvent) : void {
Or, for sending the Event properties directly into the method:
[EventHandler(name="login, type="domain.events.LoginEvent", properties="user,role")]
public function handleLogin (user:User, role:String) : void {
Swiz, for example supports this syntax:
[EventHandler(event=“com.foo.events.UserEvent.ADD_USER”)]
But I think it would be nice to keep things in line with how custom events are normally documented (with name and type arguments):
[Event(name=“click”, type=“flash.events.Event”)]
[EventHandler] is clear in its purpose and intent. Flash Player is an event based runtime, so the standard should be based on Events.
SwiftSuspenders comment: Should SwiftSuspenders support event handling in a future release, it will adopt the [EventHandler] annotation with the “name” and “type” parameters as in [Event].
Is event handling outside of the scope of this document?
SwiftSuspenders comment: As most or all participating implementations seem to be geared towards becoming full livecycle-management solutions and/ or metadata processors, it seems to us that standardizing event handling is a good idea. Maybe we should rename this document, though :)