Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

An attempt to standardise AS3 DI Metadata tags

branch: master
README.textile

AS3 DI-Related Metadata Standardisation Effort

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.

Injection by Type

Dawn, Swiz, Spicelib, SwiftSuspenders, SmartyPants: [Inject] (above property, setter or method)
Spring AS: [Autowire] (above property, setter or method)

Most popular

[Inject] by 5

Notes

[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.

Injection by Name/Id

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)

Most popular

[Inject(name=“SomeName”)] by 3

Notes

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.

Live Injections

SmartyPants: [Inject(live)] (above property, setter or method)
SwiftSuspenders: Not yet supported
Spicelib, Swiz, Spring AS, Dawn: ?

Most popular

[Inject(live)] by 1

Notes

SwiftSuspenders comment: SwiftSuspenders will support live injections in a future release. When that happens, we will adopt the “live” parameter used by SmartyPants.

Constructor Injection:

SwiftSuspenders: [Inject] (optional, above class)
Spicelib: [InjectConstructor] (above class)
Swiz, Spring AS, Dawn: ?

Most popular

?

Notes

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.

Optional Injections

SmartyPants: Not directly supported, but implied by [Inject(live)]
SwiftSuspenders: Not yet supported
Spicelib, Swiz, Spring AS, Dawn: ?

Most popular

?

Notes

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.

Object Lifecycle – Post Injection:

Dawn, SwiftSuspenders, SmartyPants, Swiz: [PostConstruct] (above method)
Spicelib: [Init] (above method)

Most popular

[PostConstruct] by 4

Notes

@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.

Object Lifecycle – Teardown:

SwiftSuspenders, SmartyPants, Dawn: none?
Swiz: [PreDestroy] (above method)
Spicelib: [Destroy] (above method)

Most popular

Notes

@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.

Factory/Provider:

SwiftSuspenders, SmartyPants, Swiz: none?
Dawn: [Provider] (above method)
Spicelib: [Factory] (above method)

Most popular

Notes

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).

Event handling

Swiz and Spring AS: [EventHandler] above method
Spicelib: [MessageHandler] (not specifically aimed at events)
Dawn, SwiftSuspenders, SmartyPants: ?

Most popular

[EventHandler] by 1 or 2, depending on your perspective

To Be Determined: Arguments

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”)]

Notes

[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 :)

Something went wrong with that request. Please try again.