|
Title: Q: How much logic should remain in view components?? Post by: eco_bach on July 20, 2009, 03:25:36 Hi
I'm trying to keep things as simple as possible for my first PureMVC application and would appreciate any input. I understand the need to keep the view components as simple as possible but am confused as to when you should refactor the logic out of the view and into one of the other core PureMVC actors. A simple example Arrow buttons on the stage that, when clicked, simply moves an image in the corresponding direction....no change to the application logic, simply updating the view. Ok, now instead of arrow buttons, we have a scrollbar that when scrolled, changes the opacity, saturation, rotation value, etc of the image. What core PureMVC actors would be required and what would there repsonsiblities be? I've read all the best practice documents and I can still see several ways of accomplishing the above.... For instance in the 'minmalist example' http://www.as3dp.com/2007/12/27/minimalist-mvc-example-using-the-puremvc-framework/ it seems like overkill to me to have a seprate proxy just for keypresses...am I wrong? Title: Re: Q: How much logic should remain in view components?? Post by: puremvc on July 21, 2009, 07:22:18 Look at your home stereo system. It has components, right? Like, an amplifier, a cd player, etc.
So if you pop open the CD player, you'll find there's lots of complicated stuff going on in there. It holds its own. It encapsulates its behavior. It doesn't need anything else to play a CD or skip track to track. It doesn't need anything. Encapsulation of behavior is the name of the game with view components NOT 'keeping it simple'. If it takes 20 lines of code to get something done, its not made any simpler by moving that code outside the component into another actor. I have no problem building view components with lots of code inside (or subcomponents with lots of code in aggregate). Whatever it takes to encapsulate the behavior of the component. Beyond that, the Mediator has the role of adapting that component to the system. Feeding it its data, invoking exposed methods in response to notifications, and listening for events from the component that say something's happened that the system needs to hear about. Don't let your Mediator turn into a code-behind monster that has half of the view component's logic. Always consider the possibility that the view component you're writing will be used in another app, possibly without PureMVC. This will help you to stay focused on the encapsulation. -=Cliff> Title: Re: Q: How much logic should remain in view components?? Post by: JJfutbol on July 27, 2009, 10:17:44 To add on what Cliff said its also not only for reusability. A lot of people get tripped on this. It's not so much about reusability as it is flexibility and maintainability. Those are key. If you have a good separation between your view component and mediator maintaining the "simple" view component API then you can change the view component completely and not have to change a line of code in your mediator. This is crucial because your views will change often! No requirements come in, new releases, features, etc. I can't tell you how important that has been for me as I've seen firsthand with hard deadlines making drastic changes to a view component the night before a company presentation and not having to change code elsewhere. Encapsulate that view logic in your component and you'll reap the benefits down the road. There is a reason why you put a bit more effort up front.
|