MVC implementation

3 views
Skip to first unread message

Jacob Wright

unread,
Sep 16, 2009, 4:58:45 PM9/16/09
to reflex-steer...@googlegroups.com
I almost sent an email about validation, but I promised I'd talk about MVC first, so here we go. ;)

I'm liking some of the things we're doing with interfaces, though I'm unsure how many we need. At first I was thinking each component would simply be broken up into 1 model (the component), 1 view (skin), and 1 controller (behavior). After talking with Ben it seems we will most likely be having many behaviors per component, possibly one for each interface the component extends. I think that could be a really cool solution, depending on how granular we get. Having a ScrollBehavior for all IScrollable components makes a lot of sense. But the more objects we have, the more memory is used up, so we don't want to go overboard.

The idea I'm starting to see in my mind is that the component will be completely independent and minimal. This allows for pay-as-you-go. It may have properties like skin, behavior, layout, features, etc. but it won't have any logic for skin short of setting the target of skin to itself when skin is assigned. This allows a component to be used without any of the features. Layout, for example, can listen to the width and height change events and update off of those.

As such, if we do it this way, behaviors, features, skins, and layouts could work on any display object providing they don't need a particular defined interface to function. Our Drag and drop behavior/feature could work on a regular movie clip probably. Most layouts could probably work with shapes, textfields, etc. I'm not saying you would use them for other things, but that everything has minimum requirements. And maybe people would want to use Reflex layouts in their non-reflex projects, who knows.

I think the general MVC relationship is good. It's now more a matter of defining the interfaces that will be reused and the behaviors that will affect them. And agreeing upon what goes into the base component class. And whether behavior is our end-all plugin framework. I still think "features" is a great way for non-behavior pluginability. Or a composite behavior proxy that you can access behaviors by name to set properties on them (or call methods?).

There, now I can send my validation email. :D

Jacob
Reply all
Reply to author
Forward
0 new messages