Support Staff2 Posted by creynders on 09 Aug, 2011 08:02 AM
That's a lot of questions :)
The number of classes for events and command is increasing as we
progress. In my opinion the code gets harder to grasp. How would
one deal with this?
Organisation. Structure your packages neatly. The best practice
recommendations for file structuring are a bit limited, you need to
find a structure that suits you best.
I structure my packages as follows:
-----signals/events/messages (last one is if I go for a mix)
Obviously I only create a package if it contains classes, in
other words it will happen seldom that I have all the above
directories for one functional domain.
Should we just use services, events, models if appropriate and
otherwise fall back to RemoteObjects in Mxml-Components for trivial
I'd definitely not start using a mix of both, it will make it a
lot harder to maintain, debug and to get an overview of what is
What if a single form needs a lot of different collections
(ArrayLists) for several DropDownLists? How is this handled the
robotlegs way? Are there many classes or is the functionality
merged into one call?
It depends on a number of factors: will all those collections
readily be available when the form needs them? Or will they be
loaded on a request-basis? (Which is preferable IMO) Let's say they
are all populated from constants (in other words, readily
available) then it's perfectly acceptable that a command sends a VO
with all the collections in them.
If you choose option 2 however, one solution would be to let the
mediator send requests for each collection separately and separate
commands fetch the appropriate collections and send them back.
Or you could make sure that all collections are loaded and stored
in models before the view is instantiated and then let the mediator
access the corresponding models onRegister. It's a matter of
preference. The former is more flexible and allows for lazy
loading, the latter is faster to set up, but ties your mediator to
And how should we give information to the user, that a certain
service is loading or that an operation has succeeded or
Again it depends on what you want to achieve. If I have a single
"spinner" or other central loading feedback view, I create a
mediator which listens to all the separate service events:
and update the view state accordingly.
Or if the loading sequence is far more complex (service calls
depending on data from previous service calls for instance, or with
concurrent service calls) chances are that I have some kind of
state machine to sequence the calls and which dispatches state
change events. In that case the loading feedback view's mediator
will listen for the (appropriate) state change events and change
view state accordingly.
If however you want each view to be responsible for showing
bootstrapping/loading state, then each specific mediator should be
listening to the appropriate service events or state machine state
Support Staff4 Posted by creynders on 13 Aug, 2011 09:22 AM
Simple doesn't mean necessarily less work ;)
And I don't agree that it's more work. If you got a good IDE, which
is mandatory, and know how to use it, creating the extra necessary
classes shouldn't be taking any more time than creating the
RemoteObjects. Obviously learning a new way of working will take
more time in the beginning than following methodologies you already
know, that's the nature of learning. But that time you will be
regaining later on, when you need to modify things, because user
requirements or remote service implementations have changed.
This setup IS simple, it just doesn't feel that way yet. It's very
easy to make changes, add steps in between, change presentation
"Real" methods mean direct calling and responding, which means
no other actors are able to respond to what's happening. It creates
1-to-1 relationships that will make it harder to accomodate for
changes in the future, in other words less flexible. Let's say for
instance you call a service method directly from a mediator. But
later on you realize (or because the client requests a change) that
something else needs to happen before that service call, let's say
a different service call, then you'll be adding that service call
to your mediator too, making it more complex already since it'll
have async call chaining. But what if the results of the first
(new) service call have nothing to do with that mediator? Or those
results need to be stored in a model? Your mediator will be
transforming into some kind of controller-like hybrid and will be
responsible for things that have no relation to it at all. That
makes for happy hunting when you have to return to this project 6
months later on and something needs to change.
And an application facade is like global variables: evil. It
will tie your actors to your application, defeating the whole
purpose: reusability and flexibility. And your facade ends up being
this huge monolithic application controlling monster.
Anyway, why is there no facade in robotlegs? Maybe this would
save us some events and commands. Events with payload vs "real"
methods, the latter i like more.
This thread on the Robotlegs Convore site discusses a way to
eliminate some of the event "overload". I started this thread
because I also like "real" methods more then events flying around
without knowing where they will be handled.
Joel Hooks made a really good suggestion there. You basically have
a controller (with an interface) for a group of functionality, and
each method in the controller delegates to a command. Both the
command and the controller methods return async tokens (if you're
not using signals). This way it's much easier to debug and step
through the application, while keeping the reusability of the
commands and the controller won't be a huge beast with 1000+ lines