Introduction & Project Goals

[Ben Stucki]

Hi everyone,

Welcome to the Reflex Steering Committee, and thanks for joining. We
(Ryan, Tyler, Jacob and I) created this group to make sure we have an
open line of communication with those of you who are contributing to
similar initiatives or have the unique perspectives we need to make
this project successful (you're basically here to call us out when you
think we're screwing up). You might expect a few more people to join
as we get started, but we intend to keep the group fairly small to cut
down on unneeded noise. At the same time, we want the decisions made
about the framework (and the thinking behind it) to be open to
feedback. So while membership to the group is by invite only, the
messages are publicly viewable.

So, I thought I would start the discussion by listing my top
priorities and/or reasons for making Reflex.

1. Support Multiple Workflows - Reflex should support multiple
development environments and workflows including use in Flash Pro, use
with the CS3 component model, use in MXML without Flex, and use in
existing Flex applications. This has been pretty hard to do before,
but I believe we have a few unique solutions that will make it
possible with Reflex.

2. Size, Performance, and Memory - Reflex is a pay-as-you-go
framework. Therefore there is no additional file size for collections,
for instance, unless you use collections in your application.
Performance and Memory will also be critical concerns as we begin to
create a larger component set. This framework should be uniquely
suitable for embedded devices, large scale enterprise applications,
and everything in between.

3. Ease of Use - Reflex should be available in a form that is easy to
setup and understand. Components should be easy to customize and
follow familiar patterns for existing Flash/Flex developers. High
quality unit testing, documentation, and learning resources are also
important for this goal.

Does this fit with your expectations for Reflex? I know each of us
have unique reasons for wanting a new RIA framework, so let's hear
what your top priorities for are.

- Ben Stucki
http://blog.benstucki.net

[James Ward]

Hi Ben and all,

First off, thanks a ton for inviting me to be in this group! I think
those are great goals! One other goal that I think has been an
important part of Flex's success is the overridability / hackability of
the framework. Unfortunately in Flex the primary method of doing this
is monkey patching. But at least we have an Escape Hatch (to use Bruce
Eckel's term). I believe every successful framework / platform has a
great and well thought out Escape Hatch. I've thought about many ways
to do this well in an AS3 framework... Compiler tricks, Dynamic
Proxies, Categories (like in Objective-C), Composite Oriented
Programming (like in Qi4J), etc. But I haven't figured out the right
way to make it work in AS3. So this could be challenging but I think it
would lead to the kind of emergent growth we all envision for Reflex.

Thoughts?

-James

[Arpit Mathur]

Hi all,

Congrats on starting the new framework.

I would love to see how this project proceeds, but one thing we should consider is where the line between "included" and "left to the developer" is drawn. For example, while Flex has a bunch of features included in the framework, only a handful are discoverable without deep knowledge of the framework. What I have seen often is a lot of programmers end up implementing a feature on top of the framework when there is something included in already. I think it may be a good idea to keep the size of the framework small (and by this I mean number of lines of code) so that reading through the source isnt a herculean task, adding only features that a developer expects to be there. 

Also I have started looking at the idea of "plugin" libraries that build on top of the core, similar to jQuery. Keeping the core framework simple will probably go a long way in that.

Cheers,

-arpit

 

--
----------------------------------------------
Arpit Mathur
twitter: http://twitter.com/arpit
blog: http://arpitonline.com/blog
-----------------------------------------------

[Ben Stucki]

Hi James,

Great point, and I think we're all very much on the same page. I know the largest reason that OpenFlux (and probably Stealth) existed was because we weren't happy with the inheritance based "escape hatch" in the Flex components. The direction that we're going in with Reflex is to favor composition over inheritance (almost religiously). So, ideally, customizing a component is as simple as swapping out the functionality you need to customize (skins, behaviors, layouts, animations, etc) without affecting the rest. It was my bad for overlooking this important feature in the goals. Maybe we can fit it under point 3, ease of use.

3b - make radically custom component development fast and easy.

Still, I think our approach for composition will be pretty specific to components, so it might not have the low level language hacking that some people are looking for. I should have some more technical details for the group in the next couple of weeks, but in the meantime feel free to keep up with our github branches while we sort through the approach for the core classes.

http://github.com/benstucki/reflex/tree/master

Thanks,

- Ben

[Ben Stucki]

Hi Arpit,

Agreed (for my part). I think simplicity should definitely win out over bulky features for the framework. This is something that will continue to be an open conversation for a while longer - until we actually get to a point where we can add advanced features. Another related issue is balancing the composition and flexibility of the component model with well encapsulated and easy to use components. One thought was that the framework would provide the core concepts and light-weight components, and a separate library project would be created to offer feature rich components - both for use and as an example of creating custom components with Reflex. Again, I think this is a decision that can be left open for a while, but it's something to keep in mind as we create the core framework concepts.

- Ben

[Tyler Wright]

Agreed. Some developers want a robust, feature-rich (and expansive) set of components without much concern for filesize, while there are many scenarios where it's important to have a smaller feature-set, enough to just get by, such as for mobile development.

In the end if we've built the core framework right we will support both. How much ends up directly in the Reflex project is yet to be determined (eg it may or may not make sense to have a full graphics engine+markup unique to Reflex), but can be a later decision.

Right now the main task is to determine the core concepts and methodology and to build up a light structure of interfaces and base-classes to support that methodology. This group came together because of a similarity of goals and concepts, particularly between OpenFlux and Stealth. I'll try and finish up a new blog post I've been picking at - should help illustrate a few of these concepts plus some other ideas and findings I've run through more recently. Stay tuned...

Tyler

[Ryan Campbell]

These are just some quick thoughts I wrote out to get some discussion going. Feel free to modify, add or remove from this list.

Once we have the core well defined we can move on to some else (layouts, effects, remoting, collections, common behaviors, etc.)

Core should be responsible for:

1. Attaching Behaviors/Controllers

a. I see Behaviors as logic that could be attached to any object. Controllers are more specific behaviors that are attached to components.

b. For example, you might have a <Expandable target="{detailsText}" trigger="{moreDetailsButton}" expandedHeight="500"/> behavior that is used in your view.

c. A controller's target must implement IComponent and uses custom metadata to inject view elements and add listeners (exactly like OpenFlux).

2. Skinning/Styling/Themes

a. It should be easy to not only change the skin of a single component but also swap out all of the default skins with your own.

b. If you specify your own theme/default skins the default Reflex skins should not be compiled in.

c. Jacob's CSS without Flex example was great and should definitely be utilized.

d. Look in to whether we can utilize the new Flex 4 states syntax. If not at least make it easy to specify up, down and over states.

3. Invalidation

a. We should probably use the same component life cycle as Flex components (createChildren, commitProperties, measure, updateDisplayList)

b. It would be nice if we didn't have to have the same min, max, explicit, measured width/height properties as Flex. Possibly a bad idea though since I'm not sure what issues that would cause.

Ryan

[Ben Stucki]

Hey Ryan,

Great points. Here are a few thoughts.

1. Attaching Behaviors / Controllers - I don't think I want these to be different things. Behaviors are pretty much like Controllers in OpenFlux, but can be assigned to any object. The behavior might have expectations of the target (implements ISelectable, IList, etc), but if the target doesn't meet those expectations it basically just doesn't do anything. I think it would be confusing to try to seperate out these concepts. You could still implement an IBehavior that just doesn't use the metadata and such though.

2. Skinning/Styling/Themes - I agree with all of this with a few notes of caution. I think we need to make sure we support using custom skins (without compiling in the defaults) without requiring CSS. Basically CSS features themselves should not get compiled in unless you use CSS. So, no default.css in Reflex hopefully. Let's see what else we can come up with first at least. Also, on "d" I agree we need to look at this pretty soon. I have a feeling it will be difficult to support this because of the code injection going on, but we'll have to dig in and see.

3. Agreed. For the most part I don't have any problem with Flex's Measurement and Invalidation model. We'll want to define interfaces for these properties so they're optional in Reflex, but I think it'll largely be the same so far.

- Ben

[Jacob Wright]

a. I see Behaviors as logic that could be attached to any object. Controllers are more specific behaviors that are attached to components.

b. For example, you might have a <Expandable target="{detailsText}" trigger="{moreDetailsButton}" expandedHeight="500"/> behavior that is used in your view.

c. A controller's target must implement IComponent and uses custom metadata to inject view elements and add listeners (exactly like OpenFlux).

Interesting thought. I think that could be a good way to go. Controllers would separate user interaction from the component model. Behaviors would be add-on functionality, like drag-and-drop, that wouldn't be compiled in unless used.

 

2. Skinning/Styling/Themes

a. It should be easy to not only change the skin of a single component but also swap out all of the default skins with your own.

b. If you specify your own theme/default skins the default Reflex skins should not be compiled in.

If we want to swap out "themes" styling is the easiest way, and could allow for the Reflex skins to not be compiled in. Though we could use some other type of global styling that components could grab skins from upon instantiation.

 

c. Jacob's CSS without Flex example was great and should definitely be utilized.

I like how it turned out. Only compiles in when used, can work with any display objects, can set sub-properties (e.g. Panel.layout.padding) and the pseudos work with state or any boolean property, so Button:selected can be used to style something. And again, you only use it if you want, completely external.

 

d. Look in to whether we can utilize the new Flex 4 states syntax. If not at least make it easy to specify up, down and over states.

I've looked into this a little, and it compiles in a lot of Flex code. But we could try doing the same thing we did with styling where we hijack the mx classes with our own. That could be cool. It will add size though.

3. Invalidation

a. We should probably use the same component life cycle as Flex components (createChildren, commitProperties, measure, updateDisplayList)

b. It would be nice if we didn't have to have the same min, max, explicit, measured width/height properties as Flex. Possibly a bad idea though since I'm not sure what issues that would cause.

We could have a ISizable type object that a component's width and height grab from. The default could simply hold the width/height properties, but a more robust one could have measuredWidth, minWidth, etc. Then a component only has width and height to worry about, even though there could be more complex computing of it behind the scenes.

If we're truly competing with Flex and not just the Flash Professional components, we'll want to make sure these types of layout things are there. And I'm not talking about horizontal and vertical layout, I'm talking about the default kind. Like when there is more text in a button, the button gets wider. You need measured width/heights to deal with that. But it could still be pay-as-you-go for when you just want to throw a button on you CS4 movie.

Jacob

[Ryan Campbell]

On Tue, Sep 15, 2009 at 3:47 PM, Ben Stucki <bens...@gmail.com> wrote:

Hey Ryan,

Great points. Here are a few thoughts.

1. Attaching Behaviors / Controllers - I don't think I want these to be different things. Behaviors are pretty much like Controllers in OpenFlux, but can be assigned to any object. The behavior might have expectations of the target (implements ISelectable, IList, etc), but if the target doesn't meet those expectations it basically just doesn't do anything. I think it would be confusing to try to seperate out these concepts. You could still implement an IBehavior that just doesn't use the metadata and such though.

Possibly I worded it wrong. I don't see them as different things, I see a Controller (or maybe call it ComponentBehavior) as something that extends from Behavior and adds all of the common controller functionality I loved in OpenFlux.

 

2. Skinning/Styling/Themes - I agree with all of this with a few notes of caution. I think we need to make sure we support using custom skins (without compiling in the defaults) without requiring CSS. Basically CSS features themselves should not get compiled in unless you use CSS. So, no default.css in Reflex hopefully. Let's see what else we can come up with first at least. Also, on "d" I agree we need to look at this pretty soon. I have a feeling it will be difficult to support this because of the code injection going on, but we'll have to dig in and see.

Yes, I definitely agree CSS should be optional and not compiled in if not used.

3. Agreed. For the most part I don't have any problem with Flex's Measurement and Invalidation model. We'll want to define interfaces for these properties so they're optional in Reflex, but I think it'll largely be the same so far.

Yeah, I think it would be smart to use what already works well from Flex (no reason to reinvent the wheel and makes the learning curve not so steep). I already have a lighter weight version of the LayoutManager for invalidation.

[Jacob Wright]

I put together a little demo last week with some things I've been playing with.

http://jacwright.com/blog/resources/reflex-demo/

The component life cycle from Flex may not really apply to our components. I'll post more of the code later to explain why, but resize the browser and see how quickly the interface responds. Invalidation was built into the component as a little method. I'll try and get the code up this week to point out some of the ideas.

The demo also uses pseudos and styling to create the "theme." And it uses states in the CSS to change properties as well, which could be an alternative to Flex 4 states if we can't get it working. Thought it might be applicable to this thread. The styles are commented if you view the source.

Jacob

[Tyler Wright]

Love the demo. I haven't looked at the code at all, but it's really responsive and I love the cursors - never had cursors feel so solid in Flash before. I looks hot too

Sorry I can't contribute anything valuable as of yet, I'm interested in discussing the invalidation and the component lifecycle

Tyler

[Simeon Bateman]

That looks wicked slick. It is very responsive!

Something I have been thinking about is a way to be able to still
leverage FXG in the aspect of skinning. Perhaps not really at the
component level like in flex4, but more like png skinning in flex 3.

In flex 4 you can actually compile fxg to a static asset, like a png
or a symbol from a swf. Using this we could still define the states
of components visually using FXG and use those on our skins.

You wouldn't have animations and some of that, but it could be a way
to leverage all the work adobe has been putting into their tooling.

What do you think?

sim

[Ryan Campbell]

I've actually thought about that too and think it's a great idea.