tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/451-no-subjectRobotlegs: Discussion 2012-01-17T10:57:54Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-07T22:36:37Z2011-12-07T22:36:38ZNo subject<div><p>Move to the "Questions" discussion board?</p></div>E.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-08T12:03:15Z2011-12-08T12:26:51ZNo subject<div><p>Hi E.</p>
<p>You are right, in-component-use of RobotLegs is discouraged.</p>
<p>“If "data01" is set on the [MainComponentClass] and
"data01" is needed by a class deeper in the component tree, how
does one propagate "data01" to that component?”</p>
<p>There are many ways to do this depending on what you want to
achieve.</p>
<p>The question is: does the MainComponent have a Mediator? Do
these subcomponents have a Mediator?</p>
<ul>
<li>If the answer is yes, then there is an easy way to populate all
components with the same data. One possibility:</li>
</ul>
<p>Use a VO, let’s call it SomeVO, that has a property public
var someData:String.<br>
Map it as a singleton injector.mapSingleton(SomeVO);<br>
Then use the Mediators to pass the VO to their views.<br>
In a mediator you do:<br>
[Inject] public var someVO:SomeVO;<br>
in onRegister you can then do:<br>
view.someVO=someVO;<br>
In the View<br>
public var someVO:SomeVO;<br>
And then you can set the component’s data to someVO.someData
using getters and setters, for example.</p>
<ul>
<li>If the answer is no, the components aren’t mediated,
you’ll have to use one of the many ways to pass data from a
parent component to its children.</li>
</ul>
<p>I would prefer to use getters and setters:<br>
SomeChildView.mxml<br>
private var _labelData:String;</p>
<p>[Bindable]</p>
<p>public function get labelData():String<br>
{</p>
<p>return _labelData;</p>
<p>}</p>
<p>public function set labelData(value:String):void<br>
{</p>
<p>_labelData = value;</p>
<p>}</p>
<p><s:Label id="someLabelNeedsData" text="{labelData}" /><br>
SomeParentView.mxml<br>
someView.labelData=someData;</p>
<p>I hope this helps, but if it doesn’t answer your
questions, please provide more details:)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-08T13:28:49Z2011-12-08T15:28:38ZNo subject<div><p>Hi Ondina!</p>
<p>Thanks for your reply. When you are working as a solo developer
as I am it's nice to be able to get some feedback through a forum
like this.</p>
<p><em>If this post gets lengthy – the ramblings are aimed at
myself: It's helpful to think out loud in the presence of another
developer. And sorry for my English. Swedes are not as skilled in
the language as we think. ;)</em></p>
<p>First. I've heard many developers distinguish between
<strong>VIEWS</strong> and <strong>COMPONENTS</strong>. I find it a
fruitful distinction.</p>
<p>In short. "Views" are non reusable, application specific, domain
aware, ui parts.<br>
In short. "Components" are reusable, application agnostic, domain
unaware, ui parts.</p>
<p>Views aggregate components and other views. A LogInPanel is a
view. A LogInButton is a component.</p>
<p>Views take precedence over components. The view paints
(skins/styles) its components, positions them, handles their
events, passes them data ...</p>
<p>When using RobotLegs: A view is often handled by a domain bound
mediator. A component is often handled by a domain bound view.</p>
<p>It makes sense that we should not use RobotLegs below the view
level of the application. But the question remains: If we develop
"deep" ui components, how to propagate data set on the component in
the "view"?</p>
<p>A concrete example: I'm developing a time-line-based component.
A zoom value set on the main component is needed in a layoutClass
several levels down in the component.</p>
<p>As you say there are many options for propagating the data:</p>
<p>ALTERNATIVE ONE:<br>
We could make the component less encapsulated. Let the developer
assemble the component in the view and let the developer set the
data, not on the main component, but where it is needed.</p>
<p><em>Upsides:</em> Flexibility. It's easy to vary the component
from view to view. No data propagation mechanism is needed.</p>
<p><em>Downsides:</em> The developer must know what parts are
needed to assemble the component (when writing MXML components we
can't ask for parts in a constructor). Instantiating the component
can get lengthy and errorprone.</p>
<p>ALTERNATIVE TWO:<br>
Pass data from parent to child, as you suggests.</p>
<p><em>Upsides:</em> It's obvious how the data is propagated.</p>
<p><em>Downsides:</em> Adds a lot of overhead to the codebase.
Component middle layers must handle data it might not need, just
for the sake of its children.</p>
<p>The process can be automated by setting up bindings from parent
to child in a commonly shared super-class, but this option is not
always available if the different component parts needs to inherit
from different super classes.</p>
<p>ALTERNATIVE THREE:<br>
Make the MainComponentClass a dependency delegator. The
MainComponentClass listens for children added deeper in the tree
and injects dependencies in subParts as needed, depending on their
type. If subParts implements interfaces the MainComponent class is
decoupled from the actual subPart implementation.</p>
<p>Upsides:<br>
Keeps component encapsulation. Data is set directly from source to
target. Through interfaces component parts are decoupled from each
other.</p>
<p>Downsides:<br>
Not clear how data propagates through the component. Only viable on
the displayList.</p>
<p>Are there upsides, downsides I haven't noticed? Are there other
better options for propagating data inside a "component". Comments
welcome.</p></div>E.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-08T13:31:05Z2011-12-08T15:28:38ZNo subject<div><p>Hi Ondina!</p>
<p>Thanks for your reply. When you are working as a solo developer
as I am it's nice to be able to get some feedback through a forum
like this.</p>
<p><em>If this post gets lengthy – the ramblings are aimed at
myself: It's helpful to think out loud in the presence of another
developer. And sorry for my English. Swedes are not as skilled in
the language as we think. ;)</em></p>
<p>First. I've heard many developers distinguish between
<strong>VIEWS</strong> and <strong>COMPONENTS</strong>. I find it a
fruitful distinction.</p>
<p>In short. "Views" are non reusable, application specific, domain
aware, ui parts.<br>
In short. "Components" are reusable, application agnostic, domain
unaware, ui parts.</p>
<p>Views aggregate components and other views. A LogInPanel is a
view. A LogInButton is a component.</p>
<p>Views take precedence over components. The view paints
(skins/styles) its components, positions them, handles their
events, passes them data ...</p>
<p>When using RobotLegs: A view is often handled by a domain bound
mediator. A component is often handled by a domain bound view.</p>
<p>It makes sense that we should not use RobotLegs below the view
level of the application. But the question remains: If we develop
"deep" ui components, how to propagate data set on the component in
the "view"?</p>
<p>A concrete example: I'm developing a time-line-based component.
A zoom value set on the main component is needed in a layoutClass
several levels down in the component.</p>
<p>As you say there are many options for propagating the data:</p>
<p>ALTERNATIVE ONE:<br>
We could make the component less encapsulated. Let the developer
assemble the component in the view and let the developer set the
data, not on the main component, but where it is needed.</p>
<p><em>Upsides:</em> Flexibility. It's easy to vary the component
from view to view. No data propagation mechanism is needed.</p>
<p><em>Downsides:</em> The developer must know what parts are
needed to assemble the component (when writing MXML components we
can't ask for parts in a constructor). Instantiating the component
can get lengthy and errorprone.</p>
<p>ALTERNATIVE TWO:<br>
Pass data from parent to child, as you suggests.</p>
<p><em>Upsides:</em> It's obvious how the data is propagated.</p>
<p><em>Downsides:</em> Adds a lot of overhead to the codebase.
Component middle layers must handle data it might not need, just
for the sake of its children.</p>
<p>The process can be automated by setting up bindings from parent
to child in a commonly shared super-class, but this option is not
always available if the different component parts needs to inherit
from different super classes.</p>
<p>ALTERNATIVE THREE:<br>
Make the MainComponentClass a dependency delegator. The
MainComponentClass listens for children added deeper in the tree
and injects dependencies in subParts as needed, depending on their
type. If subParts implements interfaces the MainComponent class is
decoupled from the actual subPart implementation.</p>
<p><em>Upsides:</em> Keeps component encapsulation. Data is set
directly from source to target. Through interfaces component parts
are decoupled from each other.</p>
<p><em>Downsides:</em> Not clear how data propagates through the
component. Only viable on the displayList.</p>
<p>Are there upsides, downsides I haven't noticed? Are there other
better options for propagating data inside a "component". Comments
welcome.</p></div>E.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-08T16:56:30Z2011-12-08T16:56:30ZNo subject<div><p>Interesting questions!</p>
<p>"<em>If this post gets lengthy – the ramblings are aimed
at myself: It's helpful to think out loud in the presence of
another developer. And sorry for my English. Swedes are not as
skilled in the language as we think. ;)</em>"</p>
<p>I’ll answer just a few questions today, and more tomorrow.
Hopefully others will participate in the discussion as well.</p>
<p>Oh, if you’re sorry for your English, then I’ll have
to apologize for <strong>my</strong> English too;)</p>
<p>“First. I've heard many developers distinguish between
<strong>VIEWS</strong> and <strong>COMPONENTS</strong>. I find it a
fruitful distinction.”</p>
<p>In my understanding the <strong>V</strong> in the
Robotlegs-MVCS, the View tier, represents a
<strong>Component</strong> (interactive or non-interactive, visual
or non visual) paired to its <strong>Mediator</strong>.<br>
But very often we use the term View to denote a Component, be it a
simple Button or a pretty complex one containing lots of
sub-components, that is mediated. You can mediate every single
component or subcomponent in your application, the decision is
yours, depending on your project’s requirements and how you
want to group the functionality.<br>
To make it clear that a Component is mediated, a common practice is
to suffix the class names:<br>
SomeView (Component) paired to SomeMediator(extends Mediator)<br>
and to have a package like this (this is my personal preference,
other people do it differently):</p>
<p>-controllers</p>
<p>-models</p>
<p>-views</p>
<p>-----components</p>
<p>----------SomeView.mxml</p>
<p>-----mediators</p>
<p>----------SomeMediator.as</p>
<p>“Views aggregate components and other views. A LogInPanel
is a view. A LogInButton is a component.“<br>
In your example, using my terminology, LogInPanel would be the View
and would have a LogInMediator. The LogInPanel is actually a custom
component.<br>
The class package would be yourpath.views.components.LogInPanel
and<br>
yourpath.views.mediators.LogInMediator.<br>
The LogInButton could be mediated as well, if you wanted to, but in
this case of a simple login form it is probably not necessary, so
it would be just a subcomponent.<br>
So when we refer to the LogInPanel as being a View, we mean the
custom Component that has a LogInMediator.<br>
A custom component can of course contain other mediated Views
(custom components).</p>
<p>Some custom components can be reusable. That’s actually
one of the reasons why we use Mediators for communication with
other parts of the application.</p>
<p>“It makes sense that we should not use RobotLegs below the
view level of the application. But the question remains: If we
develop "deep" ui components, how to propagate data set on the
component in the "view"?”</p>
<p>LogInPanel would dispatch events that LogInMediator would handle
and redispatch it to the rest of your application, for example to
trigger the LogInCommand, that would call LogInService.<br>
On logInSuccessful the LogInService would dispatch an event that
LogInMediator would hear, and then utilize API methods on
LogInPanel to set some data, say change the label of the
LogInButton.<br>
To be consistent with what I said above, I would call LogInPanel
LogInView</p>
<p>More on this later...</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-08T20:14:47Z2011-12-08T21:56:26ZNo subject<div><p>Thanks for sticking with me :)</p>
<p>As you say: Inside an application the distinction between "view"
and "component" might be overkill. From the <em>"applications
perspective"</em> there is no distinction between "views" or
"components". They are all handled the same on the displaylist. And
RobotLegs can map a mediator to any ui-type known at
compileTime.</p>
<p>Why distinguish between "views" and "components". Well: Above
the <em>"application perspective"</em> there is the <em>"developer
perspective"</em>. The developer knows of other applications than
the one at hand and wants to reuse some components between
applications.</p>
<p>Given the <em>"application perspective"</em> we could have our
components tap the application dependency management system and our
problem is solved. Given the <em>"developers perspective"</em> this
may not be a viable option. A future application dependency
management system may not be known at component compile time.</p>
<p>Reusable components must be framework agnostic (or carry a
framework encapsulated inside them). Instantiating an application
framework at the component level is considered bad practice –
for performance and probably for many other reasons as well.</p>
<p>RobotLegs is great companion. But it can only accompany you so
far. What's best practice when we must leave RobotLegs behind and
carry our own data. (Insert tears on cheeks here.)</p>
<p>This may have turned in to a non RobotLegs question. But it is a
dependency management related question. So maybe it still belong in
this forum.</p>
<p>I've tried to look at the FLEX-components for guidance but they
all seem to be pretty flat architected (maybe thats my answer) and
when they're not they often depends on the developer to assemble
them at compile time.</p>
<p>I'm enclosing a picture with a sketch of the top layers of a
TimeLineComponent I'm working on. RobotLegs would operate behind
the yellow "view" Layer. The "components" above the yellow "view"
layer are intended to be reused in other applications and should
not depend on RobotLegs to push dependencies down the tree. Lets
imagine that a property needs to travel from the blue [TimeLine] to
the unnamed red component below the [EntitySubline]. How would one
do that?</p></div>E.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-09T13:02:51Z2011-12-09T13:02:51ZNo subject<div><p>So, you are actually looking for an architectural solution
independent from the robotlegs framework.<br>
If you don’t like the downsides of:</p>
<ul>
<li>setting the properties on a child component upon its creation
from a parent</li>
<li>using events dispatched by the sub-component to signal the need
for data</li>
<li>using BindingsUtils and ChangeWatcher</li>
<li>sharing bindable VOs</li>
<li>having a reference to the parent to get its data (not really a
good option)</li>
<li>other ways that I’m not aware of at the moment</li>
</ul>
<p>then using a Factory, a Proxy or a Delegate to manage the
creation of child components and control the access to them seems
to be the best solution for what you want to achieve: assigning
properties (and dynamically change them) to well encapsulated and
reusable components.<br>
An implementation of the Class Factory could be what you needed and
maybe the benefits of being able to pass properties or even styles
dynamically and to manage events would surpass the
disadvantages.</p>
<p>But I hope others will share their opinions as well :)</p>
<p>I think, and I might be wrong, that you wish there was something
similar to robotlegs on the components’ level, an MVC for
Views to compensate Flex’s limitations?</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-09T21:04:45Z2011-12-09T22:31:03ZNo subject<div><p>You are right: I am probably looking for the RobotLegs that is
to a component, what the real RobotLegs is to an Application.</p>
<p>Some sort of native dependency injection mechanism in FLEX would
be great! (Maybe @jhooks could lobby for it as the president of
Spoon! :)</p>
<p>Thanks for your list. Could you elaborate on "sharing bindable
VOs"?</p>
<p>Something similar to your Factory/Proxy/Delegate hint is in fact
the best solution I've been able to come up with for my
components.</p>
<p>STEP ONE:<br>
Define component parts at the Interface/Abstract level. E.g.
IScalable, ATimeLine, AEntityGrid, ALineLevel ...</p>
<p>STEP TWO:<br>
Implement actual component parts. E.g. DateLine (ATimeLine),
WeekLine (ATimeLine), LinedGrid (AEntityGrid) ...</p>
<p>STEP THREE:<br>
Implement a "Container" that aggregates selected component parts
and exposes a common component interface, aggregated from the
interfaces of the component parts.</p>
<p>In the views, the developer instantiates the container and sets
it's properties.</p>
<p>The container is responsible for propagating property data to
component parts. I usually have the Container set up bindings
between its own properties and component part properties. The
container gets notified of parts being added to its subtree by
intercepting the lifecycle events crawling the tree as parts are
added to the display list.</p>
<p>This way the component implementation is encapsulated at the
"view" level. And encapsulation continues inside the component. The
Container instantiates its concrete children, but are only aware of
interfaces of branches further down the tree.</p>
<p>Maybe this is a good way to do it after all. Now that I've
rambled about it a bit.</p>
<p>Any further thoughts or real world experiences are more then
welcome though.</p></div>E.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-12T11:42:17Z2011-12-12T13:19:43ZNo subject<div><p>Hi E.</p>
<blockquote>
<p>Some sort of native dependency injection mechanism in FLEX would
be great! (Maybe @jhooks could lobby for it as the president of
Spoon! :)</p>
</blockquote>
<p>Indeed.</p>
<blockquote>
<p>Could you elaborate on "sharing bindable VOs"?</p>
</blockquote>
<p>I mentioned it because it was one of the ways to populate
components with data. A bindable VO has its downsides, of course.
It is also Flex specific.<br>
The term “VO” has diverse meaning to different people.
I’m sure you already know all this:</p>
<p>-<a href=
"http://martinfowler.com/eaaCatalog/valueObject.html">http://martinfowler.com/eaaCatalog/valueObject.html</a></p>
<p>-<a href=
"http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-aggregates-and-roots/">http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects...</a></p>
<p>-<a href=
"http://domaindrivendesign.org/node/135">http://domaindrivendesign.org/node/135</a></p>
<p>-VOs (or TOs - transfer objects) are intended as data carriers
to shuttle typed data across tiers</p>
<p>-VO is a design pattern used to transfer data between software
application subsystems</p>
<p>-A VO should be immutable. It is born with a set of values, and
it contains these values until death. It's read-only.(Stray)</p>
<p>-A VO is an immutable representation of complex state. A
snapshot of how things are at a moment in time.(Stray)</p>
<p>So, in this light, we shouldn’t call it a VO, but for the
sake of an example I’ll call it SomeVO, as in a previous
post.</p>
<p>Add the [Bindable] metadata tag to the SomeVO class. Pass a
bindable reference to SomeVO to the actors interested in its
values. Say, ParentView and SubcomponentView, both hold a reference
to it and a change to the someVO.someData in one component will be
reflected in the other component as well.</p>
<p>I’m not necessarily advocating this way of using a VO, but
it is something doable.<br>
Since you don’t want to use robotlegs for passing data to
views you’d have to do it like this:</p>
<p>[Bindable]</p>
<p>public class SomeVO<br>
{</p>
<p>public var someVOData:String;</p>
<p>public function SomeVO()<br>
{}</p>
<p>}</p>
<p>In your ParentView</p>
<p>[Bindable]private var someVO:SomeVO=new SomeVO();</p>
<p><s:Label text="{ someVO.someVOData}"</p>
<p><components:SomeView id="someView" someVO="{someVO}"</p>
<p>In SomeView</p>
<p>[Bindable] public var someVO:SomeVO;</p>
<p><s:Label text="{ someVO.someVOData}"</p>
<p>Anyway, that’s probably not what you’re after. Your
solution sounds good, as far as I can tell from your
description.</p>
<p>For further inspiration you could also look at how Flex handles
styles’ inheritance (StyleManager & Co)</p>
<p>Others' opinions would be indeed welcome:)</p>
<p>Ondina</p>
<p>P.S.<br>
I don’t know what’s wrong with Tender, but from time to
time many posts get marked as spam and some get even deleted. All
of your posts have been deleted and I had to restore them every
time you’ve posted. We don’t get notifications about
such posts, so the only way to see if there are false positive
spams is to look into the Spam or Trash folder, and that’s
not a nice task:)<br>
Now, my questions to you are: have you posted via email? Have you
registered before posting? Maybe it should be better if you created
an account. Thank you.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-14T13:11:18Z2011-12-14T13:16:34ZNo subject<div><p>Hi Ondina!</p>
<p>Thanks for the info on the VO. Read up on something you know and
you will learn something new :)</p>
<p>The VO might be a good "helper" class if the data being passed
around is complex. But still – the VO becomes the data that
possibly needs to travel the depth of the component. And we are
back to unsatisfactory solutions like passing the VO reference from
parent to child, parent to child, parent to ... or some of the
other solutions we have been discussing.</p>
<p>The Flex styling mechanism is an option. It is actually a relief
when passing around visual configuration data. Like overriding
default skin classes for components in a custom project.</p>
<p>But there is something about the styling mechanism that gives me
the chills when I am implementing a custom component. My component
should not be qualified to reach out to the global state. This is
an illness of UIComponent and we should try to distance us from
it.</p>
<p>But on the other hand: Styles being everywhere in Flex and one
can hardly escape them. So maybe one should embrace them. (Keep
close to your enemies or something like that!) I don't know how to
test a UIComponent without something like FlexUnit's UIImpersonator
anyhow.</p>
<p>Watching the FlexSummit there seems to be smart people thinking
about Flex dependency management at the core, integrated with the
compiler (?). So maybe the best is yet to come!</p></div>eriktag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-15T12:45:15Z2011-12-15T12:45:15ZNo subject<div><p>Hi Erik :)</p>
<p>You’re right, there is no ideal solution (yet) for what
you want to achieve.</p>
<p>I share your frustration with the Flex SDK and with the lack of
an elegant way to manage complex Views (V in MVCS), i.e. a good
micro-architecture for components.<br>
There might be a couple of frameworks out there, trying to solve
this problem, but I have no idea what they do. I never tried them.
Some are targeting games architectures. So, I’ll mention
Gaia, Ember and Starling just as a hint.</p>
<p>I’ve looked through my bookmarks regarding SwiftSuspenders
and as3-signals and I found this:</p>
<p><a href=
"http://blog.cjcat.net/2011/10/redesigning-rusher/">http://blog.cjcat.net/2011/10/redesigning-rusher/</a></p>
<p>I haven’t had the time to study it, but it looks
interesting at first sight. Take a look at it. I'd like to know
what you think of it.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-15T14:06:25Z2011-12-15T14:06:27ZNo subject<div><p>Love to the people who have potential answers hidden among their
bookmarks :)</p>
<p>I'll take a look at the frameworks you posted and see if I find
something interesting.</p>
<p>/Erik</p></div>eriktag:robotlegs.tenderapp.com,2009-10-18:Comment/119635472011-12-15T14:47:15Z2011-12-15T14:47:15ZNo subject<div><blockquote>
<p>Love to the people who have potential answers hidden among their
bookmarks :)</p>
</blockquote>
<p>You do? Really? I’m glad you <em>genuinely</em> love it
;)</p>
<p>Actually, the “bookmarks” are part of a database
that I use in an AIR application. I’ve built it in order to
better manage the many resources I occasionally find on the
web.<br>
I’ve already shared (in a post on this forum) ~ 165 links
that I gathered under the ‘robotlegs’ category, because
I thought it might be useful to have robotlegs-resources in one
place.</p></div>Ondina D.F.