Skinning & Robotlegs

mike.cann's Avatar

mike.cann

12 Sep, 2010 06:15 PM

Hi,

I have run a search for this topic but got nothing so thought I would post..

This is a Flex 4 question. With Spark we get the skinning architecture. As I currently see it Adobe have attempted to separate the skin from the component. I currently see this as a separation of a components presentation from its handling code.

Now what im wondering is if a mediator is really necessary in this setup. You could use skin parts to add listeners to components implemented in the skin. I know there is a coupling between the skin and the host via "hostComponent" property but this is fairly loose.

Im just looking for some sort of guidance here with skins and RobotLegs. It just seems very verbose writing a skin & view & mediator & css for each component.

Thoughts? How do you guys do it?

  1. 1 Posted by Aaron Hardy on 12 Sep, 2010 09:23 PM

    Aaron Hardy's Avatar

    To me, the main reason for the mediator is to provide interaction
    between a component and RL framework events/commands/models/components
    in the app. So yes, even though Flex 4 provides for separating a
    component's view and logic, it won't separate the component from other
    framework objects if you start throwing mediator-type stuff directly
    into your component. In other words, if you don't use a mediator and
    you start dealing with the RL framework from directly within the
    component, your component is now tied to RL. It's not the end of the
    world and in the end it's your choice, but it's generally seen as
    better practice if your component is not tied to a particular
    framework. Then if you want to use the component in a non-Robotlegs
    project, you can copy it over and you don't have a bunch of RL
    dependencies you're dragging along.

    That's my take.

    Aaron

  2. 2 Posted by mike.cann on 14 Sep, 2010 10:11 AM

    mike.cann's Avatar

    Aaron,

    Sorry for the late reply mate.

    Agreed that is the stated purpose of the Mediator, to provide a separation between the framework and the view.

    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

    Mike

  3. 3 Posted by Stray on 14 Sep, 2010 10:19 AM

    Stray's Avatar

    If 'typing' is a barrier to your preferred architecture, may I suggest that the problem is your toolset ;)

    I use Sprouts/TextMate. Making a new class / function / test case etc is a joy!

  4. 4 Posted by mike.cann on 14 Sep, 2010 11:04 AM

    mike.cann's Avatar

    Hehe Stray :)

    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.

    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

    I think im just getting lazy :P

    Mike

  5. 5 Posted by Stray on 14 Sep, 2010 11:17 AM

    Stray's Avatar

    :) 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?

    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.

    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.

    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.

    Stay lazy!

    Stray

  6. Support Staff 6 Posted by Shaun Smith on 14 Sep, 2010 11:46 AM

    Shaun Smith's Avatar

    Hey Mike,

    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.

    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.

    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.

  7. 7 Posted by mike.cann on 14 Sep, 2010 12:25 PM

    mike.cann's Avatar

    Hi Shaun / Stray,

    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.

    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 ;)

    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!

    Cheers Guys,
    Mike

  8. Stray closed this discussion on 12 Feb, 2011 10:58 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac