Marking items as [Injectable] vs a Context (as seen in Potomac framework )

Tim Oxley's Avatar

Tim Oxley

28 Jan, 2010 10:59 AM

I was just checking out this Potomac framework by the guys who do SourceMate, and I noticed they do metadata-driven dependency injection too.

Looks kinda interesting, but I noticed rather than having a 'context' and using injector.mapSingleton etc, they use metadata to declare injection sources:

Potomac Framework Metadata Injection Example

I was just wondering what you guys thought about that idea. To me it looks like it makes the injection process quite simple and localised to the data that needs injecting, without having to create additional property 'noise' by injecting the injector. Currently, the context for my app has 42 lines of import statements, and I have a funny 'god object' feeling about it. Though having injections strewn throughout the app could also be troublesome: if you accidentally map to the same type it might cause some confusing bugs to arise.

While it is convenient that all of the mappings are laid out in one place, for a medium sized app it can become quite a ramshackle of variable instantiations and mediator mappings etc

I guess an issue is: how does the injector know about the class if it's not on the display list, without some kind of context-like object? Perhaps a solution could be a preprocessor (like the way mxmlc does [Binding]? A preprocessor is desperately needed by flex anyway, with no ability to define variables in metadata (?!), there are many, many string literals through any app that uses flex metadata extensively, that should be turned into variables.

Anyway, I'm interested to hear your thoughts on using metadata to define the injection mappings and if it's even reasonably possible/a good idea.

  1. Support Staff 1 Posted by Till Schneidere... on 28 Jan, 2010 12:47 PM

    Till Schneidereit's Avatar

    Without having looked into how exactly Potomac pulls this off, I've
    got several questions:
    - In an application that consists of several modules (as Potomac apps
    will, by their very nature), how do they know which module an
    injectable belongs to?
    - How do they make their app even compile-in these injectable classes?
    In cases where the injection point is typed as the concrete class that
    gets injected, that's obvious, but what about injecting as interfaces?
    - What about dynamic mappings? These might not be too important for
    many applications of automated DI (and are considered bad practice by
    many knowledgeable people), but they play an important role in
    Robotleg's internals by enabling the seamless injection of temporarily
    mapped views and events into mediators and commands, respectively.

    I think you're spot-on about the need for a preprocessor for this
    functionality. And while I think you're right about the AS3 ecosystem
    being ripe for some advanced features in this area, I'm not sure a
    preprocessor is really the way to go. And I'm definitely sure that
    Robotlegs isn't going to rely on one anytime soon. Then again, I
    suppose it wouldn't be too hard to implement a basic preprocessor that
    parses [Injectable] metadata and spits out a fully configured context
    based on that. Or at least an InjectorMappingsCommands to be mapped to
    ContextEvent.STARTUP. That way, Robotlegs wouldn't even need to know
    the first thing about [Injectable]. Jos Yule's [work on automatically
    creating Flash IDE configuration
    XMLs](http://github.com/hyakugei/robotlegs-utilities-robotxml) might
    be a good starting point for that.

  2. 2 Posted by Chris on 08 Feb, 2010 07:15 PM

    Chris's Avatar

    Hi guys,

    I'm the founder of ElementRiver and the architect of Potomac. I got routed to this thread via my Google alerts. Since I'm here I figured I'd throw out some answers to your questions.

    In an application that consists of several modules (as Potomac apps will, by their very nature), how do they know which module an
    injectable belongs to?

    We do all sorts of preprocessing as you guys have guessed. Any [Injectable] and in fact all metadata tags are gathered and placed into a payload that is automatically downloaded and processed by Potomac. So we know about any tag declared by any classes even if that class is in a module that isn't yet downloaded. As you can imagine, with large modular apps it becomes important to know about various tags without having to rely on the module being loaded.

    How do they make their app even compile-in these injectable classes? In cases where the injection point is typed as the concrete class that
    gets injected, that's obvious, but what about injecting as interfaces?

    The Potomac Flash Builder plugin creates modules from Library Projects (as well as all that preprocessing stuff). So all classes selected to be included in a Library project's swc end up in the module swf. With FB4, most people just choose the option to always include all classes (a feature that should have been there long ago). Thus we don't rely on FB's standard static linking. Static linking is really the bane of modularity.

    What about dynamic mappings? These might not be too important for many applications of automated DI (and are considered bad practice by
    many knowledgeable people), but they play an important role in
    Robotleg's internals by enabling the seamless injection of temporarily
    mapped views and events into mediators and commands, respectively.

    You can always inject the Potomac Injector (probably like your context) and dynamically create any bindings you want.

    Anyway, I think it would be cool if you guys supported [Injectable] but I understand its not really easy. Flex/AS metadata seems to be only loosely designed as a language feature. Comparatively, Java annotations are a standard language construct. Hopefully in the future they'll support them more officially (and preprocessing would likely come with that). We couldn't wait so we did our own stuff with Potomac (and also added alot of metadata support to SourceMate too).

    regards,
    -Chris

    p.s. I probably won't be able to follow subsequent comments so feel free to email directly at cgross at e******river.com.

  3. Stray closed this discussion on 13 Feb, 2011 04:25 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac