tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/783-robotlogs-framework-feature-listRobotlegs: Discussion 2018-10-18T16:35:35Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-12T11:53:42Z2012-01-12T11:53:42ZRobotLogs framework feature list.<div><p>Hi Deril,</p>
<p>that list looks about right to me.</p>
<p>The "easily extendable"-part comes from Robotlegs being based
on<br>
automated DI. When setting up your context, you can easily add<br>
whatever features you want - be it Signals instead of events,
view<br>
controllers instead of mediators or whatever you like.</p>
<p>In RL2, we're trying to make that go even further by making the
entire<br>
framework more modular. In a way, the new command map, mediator
map<br>
and even the event dispatcher are modules, similar to those
you'd<br>
write yourself when using the framework.</p>
<p>hope that helps,<br>
till</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-12T14:12:28Z2012-01-12T14:12:28ZRobotLogs framework feature list.<div><p>hm...</p>
<p>is Mediators still not accessible from commands in RobotLegs 2
same as RL1?</p>
<p>I failed to defend why not having this access is better to my
coo-workers ..... (who mostly used to do it in PureMVC...)</p></div>Deriltag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-12T14:20:33Z2012-01-12T14:20:33ZRobotLogs framework feature list.<div><p>Short practical answer:</p>
<p>1) mediators are not one-to-one, so if you have 3 instances of
SomeView on the stage, and you inject an instance of
SomeViewMediator, which instance should be injected? There are 3 of
SomeViewMediator in existence... you might not get the right
one!</p>
<p>2) mediators are transitory - they are created and destroyed as
the view comes and goes from the stage. So - inject an instance of
SomeViewMediator, then SomeView is removed from stage, then added
to stage, and now the instance of SomeViewMediator which is
mediating SomeView is not the same instance that you injected.</p>
<p>hth,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-12T15:02:20Z2012-01-12T15:03:25ZRobotLogs framework feature list.<div><p>to Stray:</p>
<p>1 : could be solved by allowing optional naming. For instance I
could manually map mediator to view object and add name to find it
with.</p>
<p>2 : well.. don't remove the view if you intend to work with it..
:) I see the problem of automatic mediator removal... and that can
happen with delay and cause problem. If view and mediator could be
removed or added in same time only - that would not be a
problem.</p>
<p>(again... looking from PureMVC point of view - both of these is
not a problem there.)</p></div>Deriltag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-12T15:08:38Z2012-01-12T15:08:38ZRobotLogs framework feature list.<div><p>The difference is that in PureMVC the working hypothesis is
that<br>
everything exists exactly once. Naming mediators makes them
different<br>
mediators, really. And creates coupling in that somewhere you have
to<br>
decide how to name them and have to disperse knowledge about
this<br>
naming through the system.</p>
<p>Of course, there are situations where all of that doesn't matter
and<br>
you need to communicate directly with exactly one mediator. While
I<br>
think that in almost all of these cases the mediator should
initiate<br>
these communications (e.g. by dispatching an event with a callback
in<br>
it), if you don't want to/ can't use that approach, you can
always<br>
create a model that works as a registry for your mediators. Then
you<br>
can inject that model into commands and thus access the
mediators.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T10:05:39Z2012-01-13T10:39:38ZRobotLogs framework feature list.<div><p>To be honest... it's not the side of implementation is most
interested to me. :) I understand your point about mapping in
RL(and i am OK with that!). (and point about PureMVC.... it's
enough to name 2 objects by mistake with same name to get why it
suxz..)</p>
<p>I approach is more from theoretical view of point.</p>
<p>Question is... what is better - have access to mediators or
not... and if limit access - why. (without thinking what RL does
too much.)</p>
<p>I don't have any good arguments against direct access. (only my
personal style... but that does not count.)</p>
<p>Also I remember the post stating that's impossible to get
mediators in current RL... and it's worth consider adding in next
RL releases.. (don't remember there...)</p></div>Deriltag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T10:39:08Z2012-01-13T10:39:08ZRobotLogs framework feature list.<div><p>Hi Deril,</p>
<p>Asking why RL Mediators aren't injected into commands is like
saying "This potato is defective, it totally sucks that I can't
squeeze orange juice from it!" If you want orange juice (view
controllers) then you really don't want to use potatoes (RL
Mediators) to make it - no matter how hard you try, it'll be
gross.</p>
<p>Why do I say that?</p>
<p>Well, the main issue is that 'Mediator' means something
different in pureMVC from the meaning it has in Robotlegs.</p>
<p>The way Robotlegs mediators are intended to be used - purely as
a translator - there is no architecturally sound example I've yet
been given for direct access to them. You would be using them as
view-controllers, which they aren't suited to - if you want
view-controllers then implement a view-controller layer (something
that RL2 makes much easier). This view-controller layer would
present APIs and would be suitable for the purpose you're talking
about.</p>
<p>The Robotlegs mediator has a single, well defined, purpose: to
allow your view to be ignorant of application-specific events, and
allow your app to be ignorant of view-specific events. (For events
you can read 'messages' or 'notifications' if you're also using
Signals). That's it. A different purpose would require a different
solution (one that didn't involve all the mediatorMap workings that
allow mediators to be automatically created and destroyed).</p>
<p>A view-controller factory is actually pretty trivial to
implement - you can inject it into your mediators and use them to
register each view with the factory (if the factory had already
registered this view then it would ignore the request). In the
factory you can set up whatever you need in terms of injecting into
Commands.</p>
<p>I can confirm that the next RL release also doesn't
automatically map mediators for injection (for all the same reasons
as RL1) - though it does make it easier to add a view-controller
layer or make a specific mediator available for injection with a
name, in association with the automagic creation of mediators, as
we've provided a way to hook into the mediator life-cycle for this
purpose.</p>
<p>I hope that helps you talk more with your colleagues about it -
it's unfortunate that in our use of language we always end up using
the same words to mean several different things.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T11:27:29Z2012-01-13T11:27:29ZRobotLogs framework feature list.<div><p>Hey Deril,</p>
<blockquote>
<p>Well, the main issue is that 'Mediator' means something
different in pureMVC from the meaning it has in
Robotlegs.(Stray)</p>
</blockquote>
<p>That’s not true:)<br>
The roles of Mediators in pureMVC are the same as in Robotlegs.
They are not meant to be View-Controllers. Also, injecting a
Mediator into a Command would be considered bad practice in pureMVC
too.<br>
So, what Stray said about Mediators in rl would be applicable to
pmvc as well. Of course, it’s up to you whether you follow
the recommended practice or not, be it rl or pmvc, but in many
regards they are similar :)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T11:39:20Z2012-01-13T11:39:20ZRobotLogs framework feature list.<div><p>My bad - I thought pureMVC mediators also sometimes had methods
for creating child views and so on - I'm relieved to hear that this
is also an abuse of them!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T13:13:19Z2012-01-13T13:13:19ZRobotLogs framework feature list.<div><p>Just for the sake of completeness :)</p>
<p>Excerpts from pureMVC’s Best Practices (
<strong>Mediators</strong>):</p>
<p>The responsibilities for the Mediator are primarily handling
Events dispatched from the View Component and relevant
Notifications sent from the rest of the system.<br>
...</p>
<p>Consider it a bad practice to retrieve other Mediators and act
upon them, or to design Mediators to expose such a manipulation
methods.<br>
...</p>
<p>The Mediator is meant to mediate communications between the View
Component and the rest of the system.<br>
Consider the role of a translator mediating the exchange of
conversation between her Ambassador and the rest of the members at
a UN conference. She should rarely be doing more than simple
translation and forwarding of messages, occasionally reaching for
an appropriate metaphor or fact. The same is true of the
Mediator’s role within PureMVC.<br>
...</p>
<p>A Mediator that wishes to communicate with another part of the
View should send a Notification rather than retrieving another
Mediator and manipulating it directly.<br>
Mediators should not expose methods for manipulating their
stewarded View Component(s), but should instead respond only to
Notifications to carry out such work.<br>
...</p>
<p>If much manipulation of a View Component’s internals is
being done in a Mediator (in response to an Event or Notification),
refactor that work into a method on the View Component,
encapsulating its implementation as much as possible, yielding
greater reusability.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T13:18:03Z2012-01-13T13:18:03ZRobotLogs framework feature list.<div><p>What a beautiful excerpt :)</p>
<p>Thanks! I'd heard people spout about the greater flexibility of
a pureMVC mediator - clearly they're bending things to their own
desires there too.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T14:09:04Z2012-01-13T14:09:33ZRobotLogs framework feature list.<div><p>Well said!</p>
<p>I failed to put those arguments in a sentence... :) this
helped.</p>
<p>Thanks for response.</p></div>Deriltag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T15:05:37Z2012-01-13T15:05:37ZRobotLogs framework feature list.<div><blockquote>
<p>What a beautiful excerpt :) Thanks! I'd heard people spout about
the greater flexibility of a pureMVC mediator - clearly they're
bending things to their own desires there too. (Stray)</p>
</blockquote>
<p>Yes, and they are free to do so, in my opinion. Best Practices
are <strong>just</strong> recommendations, a 'Getting started
guide', as you said yesterday. They cannot cover all the possible
ways to use a framework. Best Practices seem to be inflexible,
strict, a list of many NO-NOs, oh wait .. they really are like
this, actually. But that’s exactly what they should be, in
order to confer a sense of stability and safety to new comers. I
see Best Practices and frameworks as bones and joints to which
skeletal muscles (your own code) get anchored. They allow postural
control and locomotion. How you want to move, or how flexible you
become over time is a matter of experience and agility. You can
become a dancer, a performer, an athlete, or a swimmer, and all
these are <em>valid</em>, feasible, practicable or efficacious ways
of moving.<br>
But first you have to learn how to walk, before becoming a dancer,
and you have to watch and try different dance styles, tango, rave,
punk, waltz, ballet, hip-hop etc to get a sense of what you like or
need (the approach that best suits your project). If you want to
move in a way, untypical for a particular dance style (inject
mediators into commands), you are free to do so, of course, but
your trainer <strong>has</strong> to make you aware of the risks of
breaking your legs..<br>
Also, the dance steps and moves required are different from dance
style to dance style (from framework to framework, but also within
a framework). You can compare waltz with hip-hop if you wanted to,
but it wouldn’t make much sense from a practical point of
view.<br>
So, Deril, if you say, ‘look, that’s possible in pmvc,
why is it not possible in rl’ or vice-versa, you ask the
wrong questions :)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T15:24:01Z2012-01-13T15:24:01ZRobotLogs framework feature list.<div><p>I agree -</p>
<p>There are times when it's clear that you're building something
on sand. Mediators in Robotlegs are transitory, stateless (because
of being transitory), have timing issues and potential reparenting
issues (in RL1 at least, they can be 'paralysed' for a frame when a
view is reparented). All of that can add up to memory leaks,
hard-to-identify bugs and brittle code that breaks when refactored.
It would be irresponsible of us not to say to people "Look, that
will probably explode!", but if they really want to use it that
way, they still can.</p>
<p>It reminds me of when I learned to play the french horn. At the
beginning you are taught to play it a certain way, because for a
child this is all that is possible - you physically can't produce
the force required to play it 'properly'. Then, a few years later,
just when you feel like you are mastering it, your teacher says
"Now we must change everything" and you have to learn a new way of
playing - or you are stuck on the plateau.</p>
<p>TDD is the thing that most often creates this experience for
programmers as far as I can see. The day before they started using
TDD, writing code felt easy. Suddenly it feels hard again... and
not everybody can handle the pain while they strengthen those new
muscles!</p>
<p>Sx</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T16:20:26Z2012-01-13T16:20:26ZRobotLogs framework feature list.<div><p>to Ondina: my question was exactly opposite: "what is best way
to do it and why... despite how or what framework allows us to
do.."<br>
It's just PureMVC and RobotLegs is the best example case for the
question as they approach it differently.</p>
<p>also... I really hate framework that have many NO-NO's as you
put it. It defeats part of framework purpose. Good framework would
not enable you to misuse it without hacking... ...and I refuse to
accept any framework that does not meet this criteria.</p>
<p>"hacking" should be available.. to solve special cases. but if
you go that path you most likely know what you are doing and
why.</p></div>Deriltag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-13T17:04:33Z2012-01-13T17:04:33ZRobotLogs framework feature list.<div><p>Yeah, but a good hacker likes it when it’s challenging.
Easy code!=no fun. Kidding.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-15T12:49:28Z2012-01-15T12:49:28ZRobotLogs framework feature list.<div><p>Hi Deril, the thing with a framework is that it's a
<em>subset</em> of the features offered by a platform. A framework
can never do more than what is available on a particular platform -
it can only wrap up low level features into a high level API for
developer convenience. The process of wrapping up low level
features into a high level API places limitations on usage, and
working around those limitations requires hacking.</p>
<p>In the case of retrieving mediators the "hack" is one line of
code added to a mediator's onRegister hook:</p>
<pre>
<code>function onRegister():void {
injector.mapValue(SomeMediator, this);
}</code>
</pre>
<blockquote>
<p>I really hate framework that have many NO-NO's as you put it. It
defeats part of framework purpose.</p>
</blockquote>
<p>It does not defeat the purpose of a having a framework at all.
Frameworks are, by definition, limited. The benefit of those
limitations is to <em>reduce</em> the possible number of ways to
solve a given problem so that when working in teams, or maintaining
old code, the pattern for solving that problem is immediately
recognisable. Without limitations every developer on a project
would solve the problem in a different way and the code would be
hard to read and problematic to maintain.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/128525442012-01-15T19:58:22Z2012-01-15T19:58:22ZRobotLogs framework feature list.<div><p>(haha, I love how easy that is!)</p></div>Abel de Beer