tag:robotlegs.tenderapp.com,2009-10-18:/discussions/feedback/31-using-robotlegsRobotlegs: Discussion 2018-10-18T16:35:35Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/128291802012-01-11T15:59:49Z2012-01-11T16:25:59ZUsing Robotlegs<div><p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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?</p></div>Jim Brychkatag:robotlegs.tenderapp.com,2009-10-18:Comment/128291802012-01-12T01:59:20Z2012-01-12T01:59:20ZUsing Robotlegs<div><p>Hi Jim,</p>
<p>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.</p>
<p>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.</p>
<p>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 <em>must</em> 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.</p>
<p>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.</p>
<p>Hope that helps!</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/128291802012-01-12T11:49:45Z2012-01-12T11:49:45ZUsing Robotlegs<div><p>+1 For what Shaun says.</p>
<p>"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".</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>They're also both apps that might want a different view on iPad
to the one you want on your laptop.</p>
<p>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.</p>
<p>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.</p>
<p>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!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/128291802012-01-12T15:28:46Z2012-01-12T15:28:46ZUsing Robotlegs<div><p>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.</p>
<p>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.</p></div>Jim Brychka