tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/278-skinning-robotlegsRobotlegs: Discussion 2018-10-18T16:35:17Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/29340452010-09-12T21:23:26Z2010-09-12T21:23:26ZSkinning & Robotlegs<div><p>To me, the main reason for the mediator is to provide interaction<br />
between a component and RL framework events/commands/models/components<br />
in the app. So yes, even though Flex 4 provides for separating a<br />
component's view and logic, it won't separate the component from other<br />
framework objects if you start throwing mediator-type stuff directly<br />
into your component. In other words, if you don't use a mediator and<br />
you start dealing with the RL framework from directly within the<br />
component, your component is now tied to RL. It's not the end of the<br />
world and in the end it's your choice, but it's generally seen as<br />
better practice if your component is not tied to a particular<br />
framework. Then if you want to use the component in a non-Robotlegs<br />
project, you can copy it over and you don't have a bunch of RL<br />
dependencies you're dragging along.</p>
<p>That's my take.</p>
<p>Aaron</p></div>Aaron Hardytag:robotlegs.tenderapp.com,2009-10-18:Comment/29340452010-09-14T10:11:06Z2015-10-19T23:47:53ZSkinning & Robotlegs<div><p>Aaron,</p>
<p>Sorry for the late reply mate.</p>
<p>Agreed that is the stated purpose of the Mediator, to provide a
separation between the framework and the view.</p>
<p>I just wonder if the separation can be taken too far. I just
dont like typing so much I guess and am looking for any shortcuts I
can find :P</p>
<p>Mike</p></div>mike.canntag:robotlegs.tenderapp.com,2009-10-18:Comment/29340452010-09-14T10:19:24Z2010-09-14T10:19:24ZSkinning & Robotlegs<div><p>If 'typing' is a barrier to your preferred architecture, may I suggest that the problem is your toolset ;)</p>
<p>I use Sprouts/TextMate. Making a new class / function / test case etc is a joy!</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/29340452010-09-14T11:04:17Z2015-10-19T23:47:53ZSkinning & Robotlegs<div><p>Hehe Stray :)</p>
<p>Im being somewhat pedantic. I currently use FlashBuilder, mainly
for the refactoring support it gives, its not perfect but it was
the best out there when we started this project.</p>
<p>The comment / question I was trying to make was that the process
is really verbose and involves many files often with the same name
"AdminMenuSkin" "AdminMenuView" "AdminMenuMediator" "AdminMenu.css"
"AdminProxy" etc etc</p>
<p>I think im just getting lazy :P</p>
<p>Mike</p></div>mike.canntag:robotlegs.tenderapp.com,2009-10-18:Comment/29340452010-09-14T11:17:56Z2010-09-14T11:17:56ZSkinning & Robotlegs<div><p>:) Lazy coder? Apparently that's a good thing - aren't laziness, short attention span and stupidity meant to be the features that result in the best code?</p>
<p>I think architecture also depends on what your own personal strengths / weak spots are. Personally I'm in favour of a large number of classes with very select responsibilities - but that's partly just because my work day involves a lot of interruptions, and so this way I can get a class 'done' more regularly.</p>
<p>Yes, the names are similar (AdminMenuView / AdminMenuMediator etc), but wow - you know where to look for responsibility before you even open the file! To me, that's a good thing.</p>
<p>FlashBuilder is my nemesis :[ To me it's like the screwdriver that is actually slightly the wrong fit for the screw you want to tighten, but was right next to you when the rest of the toolkit is still in the van.</p>
<p>Stay lazy!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/29340452010-09-14T11:46:33Z2010-09-14T11:46:33ZSkinning & Robotlegs<div><p>Hey Mike,</p>
<p>My (cheeky) advice would be to make a new branch of your current project and take a stab at refactoring it into fewer lines/files. Go crazy, throw "best practices" out the window, experiment.</p>
<p>If you find that clarity increases then you "were doing it wrong" in the first place :) If you find that things have gone nightmarish then make a note of exactly "why" the various parts have become less understandable.</p>
<p>There is no one-size-fits-all approach to development, the best one can do is build up a good understanding of what makes systems easy to read, maintain, and develop. I do this by trying new approaches in each and every project I work on. I often go 360 on my opinions.. sometimes more than once. My current practices are so far from the RL "best practices" guide that it's almost amusing.. On the other hand, my experimental "shortcuts" often end up being pain-points.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/29340452010-09-14T12:25:49Z2015-10-19T23:47:53ZSkinning & Robotlegs<div><p>Hi Shaun / Stray,</p>
<p>What you said is so true Shaun. I am too trying to find my way
towards the optimum flow as I see it. I am constantly questioning
things and then changing then going back on my changes.</p>
<p>Your suggestion on doing a branch and trying something out is a
great idea. I think im going to have a go at ditching the Mediator.
I like commands and proxy and services but I think I can do without
the Mediator, but we will see, ill probably end up changing my mind
next week ;)</p>
<p>Agreed with the screwdriver analogy Stray. I too am frustrated
with flash builder. Especially when I see all the awesome things
the Java Development plugin for eclipse has. If only FlashDevelop
had better refactoring, debugging and profiling support and I would
go back it it in a heartbeat!</p>
<p>Cheers Guys,<br>
Mike</p></div>mike.cann