Using Robotlegs
I’m doing some research for a new project that will have about 40 to 50 screens. I have used Cairngorm 2 for small projects but with starting a larger project, I wanted to get a current framework. I try to look beyond the cool factor and all the hype to see if a technology is worth learning and will benefit the project.
What I liked about Cairngorm is that it helped structure the code so that it was easier to maintain the application. A programmer that wasn’t familiar with the application could step in quite easily.
I read the ActionScript Developer’s Guide to Robotlegs and found it to be a good read. However, what concerned me was when I looked at the Mosaic Tool example and it took 11 steps to update the model when a user clicked a tile and 13 steps for a new task to get saved in the Personal Kanban application. My first thoughts were that this could be a maintenance nightmare.
So my question is this, is it just because I’m new to Robotlegs that I think the maintenance of an application could be difficult? What is the bang for the buck so to speak if I were to use Robotlegs over Cairngorm 2?
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
Support Staff 1 Posted by Shaun Smith on 12 Jan, 2012 01:59 AM
Hi Jim,
I think it's important to keep in mind that the approaches presented in that book are just approaches, and while they do represent the way that many people use the framework, they aren't the only ways to do so.
If you have a development style that you are comfortable (and happy) with, you should find that Robotlegs is perfectly capable of fitting in to that. You can still benefit from automated dependency injection and view management whilst structuring things in a way that makes sense to you and your team.
If you don't like all the indirection and layers of de-coupling presented in those approaches, feel free to make things a little tighter. I have an app that allows users to browse huge sets of data in various ways. That app does not benefit from keeping things super loosely coupled - the view layer must be kept tightly coupled to the structure of the data for things to actually work. If the data changes shape, the app must change. This is the nature of that app. With too much indirection the app would be a nightmare to maintain. But I've built plenty of applications that do need the extra de-coupling however. In those cases the de-coupling aided maintenance.
The goal is always to achieve "appropriate coupling". My suggestion would be to build a couple of test applications using the various approaches and get a feel for where the de-coupling is and isn't appropriate. That way you'll be able to choose an approach that best suites you project.
Hope that helps!
2 Posted by Stray on 12 Jan, 2012 11:49 AM
+1 For what Shaun says.
"Maintenance" is a bit of a thorny word in my view - it can mean anything from "Add a new feature" to "Fix a bug" to "Change how the data is saved out".
For bug fixes, if you've got a test suite then the number of steps in a process shouldn't make much difference - if the classes are well named then you'll be half-way to finding it, and the tests will reveal the gaps where the bug could lie.
For adding features and making changes, as Shaun points out, it all rather depends on the nature of the app and the change you're making.
In the book, the objective was to show how you could build the minimum viable implementation of apps that could easily be extended and expanded to add extra features. These are both applications in which the model and the view are highly decoupled - for example what a mosaic looks like and how you represent that design in data are quite different problems, so it makes sense for them to be well buffered from each other. Likewise with the KanBan app.
They're also both apps that might want a different view on iPad to the one you want on your laptop.
In addition, with both applications it's easy to see that adding "undo" would be a feature requested by any user almost immediately. At that point the command pattern really comes into its own - so they're good candidates for that approach, so even without the decoupling provided by mediators you'd be looking at 3 'transactions' to do an update.
It's worth noting that because we 'call out' both sides of each step in the example code you identified, the number of transactions is actually more like half the number of steps shown - so, even if you were to set a value directly we would have shown the code that uses the setter and the code in the setter, so that would appear to be 2 'steps' rather than just one. So the actual step counts are more like 5 and 6.
Hopefully what you also noticed is that in the Mosaic App, almost all the classes are under 60 lines - so you can see the whole class on a typical screen without any scrolling... and the responsibilities are really clearly separated. All of which makes maintenance easier in my experience. But tastes vary!
Stray
3 Posted by Jim Brychka on 12 Jan, 2012 03:28 PM
Thanks for the clarification. Yesterday, I ported over a screen with Robotlegs that was originally using Cairngorm 2. I see what you mean. There is a lot of flexibility in how you use it and the additional functionality you can use compared to Cairngorm.
I haven't read the testing chapter but something I need to do since I have never done automated testing on the Flex code but I'm sure there are large benefits to do so.
Ondina D.F. closed this discussion on 03 Feb, 2012 09:43 AM.