Swiz vs RobotLegs LIVE!
Since I began my DI framework journey I have used these two tools a lot. I’ve gone back and forth and back and forth over which I like better. Strangely, it’s usually the one I’m NOT currently using that I favor. The things I miss always stand out when I can’t use them.
Well on Wed Jan 27th I’m going to be hashing these two frameworks out live at the Phoenix Flash Platform User Group. For those unfamiliar with Dependency Injection frameworks I’ll go over the basics of how to get started with both Swiz and RobotLegs and how they are the same. It will be a “lab” session and my plan is to walk everyone who is interested through the process of building a working sample. Check back here the day of the presentation for links and resources to help us along. It MAY help to have a Facebook account and SOME familiarity with building Facebook apps with the AS3 API. I’m thinking of doing that as the example apps. What do you think?
Then I’m going to talk about how the two frameworks are different. I’m going to try very hard to be impartial. I LOVE both of these frameworks. There are a few points about them that I’m planning to go over (besides the basics of how to set them up).
- What is a Context and why does it make my hair look better?
- Will Swiz 1.0 alpha make by teeth whiter than 0.6.4?
- What if I want to process my own MetaData? Can any of this help me?
- I REALLY like to use PatternX instead of Pattern42 when dealing with my views. Can I do that?
- Commands vs Controllers on WWF SmackDown. Who’s logic will win?
- Does/should a 1.0 version really matter? (Yes, I want to talk about this one, but probably only AFTER the meeting once the booze has started flowing).
My question to you, the concerned reader is what else should I discuss? Are there any benefits or differences that you would like to see that I point out? Please leave your comments here (in a timely manner) and I will do my best to get the points into the presentation. I know there are other similar frameworks out there (Parsley is actually one I like a lot too) but these are the two I use daily and am most familiar with. They are the ones I decided to put into my toolbox so they are the ones I will talk about.
I will try to tape the presentation or at least make the slides available so maybe that can help others out there who want to get started.
Only reason I don’t use Swiz is the metadata. This causes a loss in strong-typing. While Ben & crew have apparently done work to ensure the runtime exceptions thrown are helpful, I’d prefer my compiler that I paid $700 for tell me, not an open source framework after my app is running. That, and no one has sold me on the injection concept yet (not in Robotlegs either).
Another thing too is Swiz’ loose approach to Mediators. For those fans of the Code behind, Passive View, Presenter pattern, etc. this is nice because they can make their MXML View’s “cleaner” by using a traditional View approach to code-behind vs. a framework approach (Robotlegs/PureMVC Mediators). Coupled with a fraemwork and Flex 4, though… this just complicates the shit outta View’s. View + skin + mediator and/or code behind… ugh. Too much code. Whatever, each their own. Don’t confuse this with “mediate event”.
Awesome stuff, that sounds like fun! Here’s a mail I sent to Joel when he asked me about my first impression of the Swiz’s new custom (user definable) metadata processing:
—-
The idea is certainly useful, but I’m not a fan of abstracting the wiring of a system out into un-type-checked (!?) metadata. And I’m not a fan of doing that wiring directly inside my leaf nodes (but that is another discussion). I need to properly formulate my thoughts on all this and write a blog post about it.. the problem is: I’m not 100% decided on how I feel about that kind of de-coupling. If it could be properly standardised it would be a different story (class portability would be then actually be possible for metadata driven designs), but Swiz is forging ahead and inventing their own brittle metadata dependencies. Parsley has a much better chance of pulling this off in the long run due to it’s (only slightly) more sensible metadata dependencies.
Many developers enjoy the framework app class de-coupling that Swiz and Parsley enable. It’s a reasonable stance. You don’t touch any framework classes (neither by extension nor composition) so your classes aren’t coupled to any framework, right? Wrong.
Why I think de-coupling via non-”standard” metadata is severely flawed:
Firstly, it’s a lie – your classes are still coupled to the frameworks that parse their metadata, the coupling just happens to be very fragile. Instead of programming to interface contracts you are programming to metadata contracts. But you can’t look at metadata contracts, you can’t step through them, and they only function correctly when “parsed” by the correct version of an instance of the framework against which they were written.
So, when you depend on complex, un-standardised metadata you are binding yourself to a particular version of a particular metadata parser, but you can’t specify which version that is. What if something else parses that class and interprets the metadata differently? The parser might complain at runtime, or it might do something completely unexpected, or nothing at all. What happens when a newer version of your parser (metadata-driven wiring framework) changes it’s contracts? Your old classes will still compile, but who knows what the hell will unfold at runtime!
Let’s have a look at this:
[Autowire( bean="appModel", property="subModel.fooObj.someString", destination="myCanvas.lbl.text" )]
Firstly, what on God’s Green Earth is “Autowire”? It’s not that I don’t like the word, it’s that it doesn’t have a commonly understood meaning.
Secondly, what’s a “bean”? For a framework that strives to distance itself from Java I really cannot understand thought process behind that word.
Thirdly, that’s a LOT of coupling. Although it might be quick and fun to dig through your object graph from the inside out, it’s a very bad idea flexibilty-wise. Does _parent._parent._parent not ring any bells? Law of Demeter – seriously. Awesomely enough, in this case the compiler can’t even type-check the nasty chain because it’s hidden behind metadata.
Anyway, I’m rambling, and as I said, I haven’t made up my mind yet. What was your first impression?
—-
I suppose the summary of that ramble is: I don’t trust metadata. Robotlegs make use of metadata: [Inject] and [PostConstruct] – but those words are well understood, and used by other ActionScript and non-ActionScript frameworks.
Swiz is innovating, and doing a damn good job of it, but personally I prefer granular, interchangeable libraries to parsers.
OK, I’ll bite and respond. :) pbking.com, where framework authors come to fight!
How is anything we’re doing brittle? We’re in control of the API, and it’s small and simple.
Regarding coupling, I think you’re missing the point. Swiz and Mate both allow you to write classes that are focused on their business purpose without extending this or implementing that. Sure, in Swiz you’ve got metadata sprinkled in, but you could move that class to another framework or app and fulfill its dependencies manually or in another way. The metadata will simply be ignored. If you want to talk about being tied to a specific implementation, that is exactly what happens when you extend and implement framework specifics. If things change you’ll know about it at compile time, but you will also have to rewrite your classes. With external config (metadata or a Mate map) you just have to find a new way to satisfy the class’s needs. The idea that an API will stealthily change its contracts though, is a bit outlandish, so I don’t think it’s really a valid argument to begin with.
And ah the straw man code sample. That tag is not even valid in Swiz 1.0 as property has been removed.
Firstly, Autowire is a minor derivation of @Autowired, the annotation Spring used to denote DI before JSR-330 introduced @Inject.
Secondly, bean is again a term from Spring, which Swiz is based on. Swiz does not strive to distance itself from Java. Our materials say it “Imposes no JEE patterns on your code”, which is a reference to the fact that we don’t require use of front controllers and commands a la Cairngorm.
Thirdly, we obviously don’t encourage that kind digging into objects in your metadata. We added support for dot notation to more closely resemble the mx:Binding tag, and in response to user requests. We added [VirtualBean] specifically to help avoid that kind of tag. Anything can be abused, so let’s not judge something based on the worst possible implementation of it. We strive to offer flexibility, and giving developers enough rope to hang themselves with comes with the territory. If you’re prone to tying nooses, Swiz may not be for you. :)
[Inject] is used by Parsley and a couple of obscure AS3 frameworks. Big deal. I think the name of the tag is an extremely trivial issue, but I went ahead and spent 10 minutes and added support for [Inject] to Swiz. The team will be discussing our policy for moving forward, but I personally would be OK with moving towards [Inject] in an attempt to create some standardization. [PostConstruct] also comes from Java/Spring, so I am not sure why it’s good and Autowire(d) is bad.
Finally, what about RobotLegs is interchangeable? Every example I have seen shows classes extending RL classes and/or implementing RL interfaces all over the place. If you are OK with that then fine, but calling it interchangeable makes no sense to me.
You still are hung up on the MVCS implementation eh? Robotlegs, the framework, is a set of discrete interchangeable utilities that provide a solid DI container solution. There is infinite flexibility and you can interchange and number of libraries for aspects of the system. You want to use Penner’s Signas? No worries, Robotlegs could care less. You want to inject into PBCommands or Flight Commands? Fuck ya, tear it up cowboy. Break out the CommandMap and go to town doing it YOUR way.
The examples are exercising the core of Robotlegs with a familiar MVCS implementation. That’s great, they were written for people to focus on and get a grasp of the framework and the out of the box implementation. Here’s the thing though, people are breaking out of that and using Robotlegs as a tool for creating apps in their style. This is kickass and what we hoped would happen. Smart people thinking out of the box doing cool things.
I think you’re being a little disingenuous about the extension of framework classes. It’s hard to tell if the convenience classes (AbstractController, IDispatcherBean, etc) are going to come back to Swiz. Comments in the examples mention that some things will be coming back, but maybe “early” adopters are getting hung out to dry here? That is what the extends/implements in the Robotlegs MVCS examples represent, clarity and convenience.
I am hung up on the MVCS implementation because it’s the only one I ever see. If you have links to alternative implementations I am definitely interested in checking them out.
I’m not sure what you mean about being disingenuous or adopters getting hung out to dry. AbstractController was a convenience class that is being refactored to be used via composition in 1.0, but all it really provides is a concise way to call services and assign listeners. IDispatcherBean and other interfaces are also generally for convenience, and if avoided will only cost you a few lines of code to replace their functionality. The RobotLegs ImageGallery example app, on the other hand, shows that every command, model, service, mediator and context extend a RobotLegs class! I’m sorry but that is just crazy. It’s kind of like a modular version of Cairngorm but with DI isn’t it?
LOLzors! Seems I missed all the Twitter action. Anyhoo, that was just my first impression of user customizable metadata, not a well thought out critique, and as I said: I’m not 100% sold either way – the convenience might outweigh the portability.
I should probably have mentioned that RL doesn’t actually know anything about any metadata – [Inject], [PostConstruct] or otherwise – that stuff is left up to the DI/IoC container. But I really do think that those 2 annotations are a little more “standard” than [Autowire]:
Inject: Parsley, Spring, Google Guice, SmartyPants IOC, SwiftSuspenders, Dawn
Autowire: Swiz
But you’re right, you *are* in control of the API, so perhaps it’s no biggie. I only pasted that old email in there because I felt it might be relevant to the “What if I want to process my own MetaData? Can any of this help me?” point above.. and I was too lazy/rushed to re-evaluate my thoughts on the matter!
Now, regarding framework class extension: When you extend the Robotlegs Mvcs Command class, for example, all you are inheriting is a bunch of injection points – dependencies that you will *probably* need. Nothing forces you to extend such a class; if you choose not to you simply need to define your injection points manually. Throw Robotlegs out and you’ll be left with a bunch of classes that declare their dependencies in a standard format. You could satisfy those dependencies with Parsley, SmartyPants, SwiftSuspenders etc.
RL and Swiz approach DI quite differently:
RL provides some tools to automate the dependency injection process, but hands the actual work over to a third-party DI framework. Put another way: RL leverages Flash Platform features (the Display List, the Event Model) in order to assist DI, but gives developers the freedom to choose their own dependency configuration tools. RL does not process metadata – that is up to the DI/IoC container.
Swiz, as far as I know, parses metadata and does cool things with it: sometimes simply injecting dependencies, other times dispatching and routing events, and.. I don’t know, what ever funky things you smart folks come up with ;)
Yes, I am being silly! None of this really matters when you’re using tools that you understand and enjoy :)
Autowired is also used in Spring. Ok, it has a ‘d’ at the end, but people will recognize the Autowire metadata when they see it. But a standard would be better, I agree.
In the Java/Spring world most of the DI, bean configuration was done in xml. But I see that more and more developers and Java standards are moving towards annotations(same as metadata in flex) to do that, and that’s the way Swiz is taking too probably, learning from the Java world.
Jason,
I am part of the Atlanta Flex User Group. Last month our group did an introduction to RobotLegs. I would really be interested in viewing the video of your presentation or at least the slides.
Would you mind making available what you can?
Thanks,
Joseph
Hello guys, nice discussion!
I’ve been using Swiz for some weeks and I find it great! I made an extension to the version 1.0 beta that uses custom metadata processor and Cairngorm Tasks. Why tasks? Simply because I don’t like controllers, because they always grow very fast and they have to much logic in… i really like the idea to have small separated task, that I can setup like lego ;) in parallel or sequence (thanks to Cairngorm Task implementation… can someone tell me why they named it Tasks? Command is the pattern…). So I have my custom metatag [DynamicMediate] in my DynamicTask class and in the beanLaoder I simply put and it invokes the method that has this metetag … for me it works great;) also when my DynamicTask makes a new instance of the taskClass I inspect all the tasks children and initialize them as beans, so every [Inject] tag works event in the children task (e.g. when SimpleTask extends cairngorm SequenceTask). I know that my thoughts here have basically nothig to your Swiz vs. Robotlegs argue but I only wanted to write that Swiz is a really great framework! Good job Swiz Team!
…beanLaoder I simply put….. .something has eaten my code;) – DynamicTask event=SimpleEvent.SIMPLE taskClass=SimpleTask – ….. and it invokes the meth….