Reflex Component Model White Paper

[Ben Stucki]

Hi all, I created a short white paper to define the core component model as it's layed out in my git repository today. Keep in mind that the core contributors aren't necessarily in agreement on all of the classes and interfaces, but it still defines the general approach we've agreed on taking so far. I thought it would be good to start hashing out the details here so that everyone has an opportunity to provide feedback at this critical stage. If you have questions or concerns over this approach, now is the time to talk it through. Thanks!

Reference Implementation (Incomplete)

Reflex Core Component Model White Paper (Draft)

- Ben Stucki

[Jacob Wright]

Hey Ben, I'm glad to see we're moving forward with this. It's looking good.

I think we're on the same page with the component-skin-behavior triad. Does a component need a skin? If the component was done in CS4 with the timeline, does its skin property point to itself?

One item in the white paper that either needs more research or needs rethinking is extending UIComponent conditionally. There may be a lot of API conflict in our component class with theirs. Incompatible overrides and such. But if we can manage it, that would be cool.

Jacob

[Simeon Bateman]

I was thinking about this concept as one of the "project" goals, and I
thought I would offer an opinion. I think the value of reflex is that
you loose the dependencies on the flex framework. I don't expect
someone to build applications that they try to jam into both. Or maybe
that is even a stupid statement.

So the idea is that a component that is written using reflex would
want to be utilized inside a flex app. So my thought on that is to
have a sub-library that includes whatever dependencies are required to
extend UIComponent and then lace in the refex component. So it would
provide the interface translation between the flex api's and the
reflex api's.

So I guess my thought is that being compatible with Flex maybe should
not be a core piece of the architecture of reflex. Because I'd hate
to see the team make decisions for reflex based on being compatible
with flex. I mean, the flex team cant even make good decisions about
their framework, reflex is supposed to save us from that. :) Not
saying that using reflex components in flex should not be easy, but I
dont want to hamstring decisions about reflex by depending on flex,
the way the flex team is getting screwed by decisions about builder
and catalyst.

Just thought I'd add a thought there.

Cheers,
sim

[Jacob Wright]

I was thinking about this concept as one of the "project" goals, and I
thought I would offer an opinion.  I think the value of reflex is that
you loose the dependencies on the flex framework. I don't expect
someone to build applications that they try to jam into both. Or maybe
that is even a stupid statement.

So the idea is that a component that is written using reflex would
want to be utilized inside a flex app.  So my thought on that is to
have a sub-library that includes whatever dependencies are required to
extend UIComponent and then lace in the refex component.  So it would
provide the interface translation between the flex api's and the
reflex api's.

So I guess my thought is that being compatible with Flex maybe should
not be a core piece of the architecture of reflex.  Because I'd hate
to see the team make decisions for reflex based on being compatible
with flex.  I mean, the flex team cant even make good decisions about
their framework, reflex is supposed to save us from that. :)  Not
saying that using reflex components in flex should not be easy, but I
dont want to hamstring decisions about reflex by depending on flex,
the way the flex team is getting screwed by decisions about builder
and catalyst.

Just thought I'd add a thought there.

100% agree 

[Ryan Campbell]

Yes I agree. I don't even want to have to think about UIComponent compatibility when developing components.

I know we once talked about creating a container class you'd use as the parent of your component when needing Flex support. Also saves you from having to re-compile the framework to extend UIComponent.

[Arpit Mathur]

So I guess Reflex wants to do what the JVM did, be an abstraction for the underlying framework?

Also do remember that Flex framework has a lot of non UI parts as well. For example, Lists have a strong tie in with ArrayCollections and at some point there will be a question as to whether we abstract collections away as well, similar questions will come for Effects as well.

Good to keep an eye out for that even though it may be a while before Reflex builds such components.

-a

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

[Ben Stucki]

Hey guys,

Jacob - I think for the Flash Pro use case in our default components, having the component point to itself as the skin should be a workable solution. Certainly you could build a component that doesn't implement ISkinnable and just bake all the graphics in as well, but of course for our components we're trying to support both without creating duplicate classes. Also, I agree that there are open issues around how well we can support conditional compiling to bake in the UIComponent, but I still haven't seen any show stoppers. We'll just have to see in the next few weeks.

Sim, Jacob, Arpit - I agree and share the concern. I want to say up front that I don't think compatability with Flex specifically is a primary project goal, but I do think it's important to include the Flex workflow as a peer with other workflows we want to support (AS3 only, Flash Pro, MXML non-flex). Which is to say let's explore how we can make it easy, but I'm certainly not willing to sabbotage or compromise Reflex by introducing bad Flex interface dependancies (a la IUIComponent). I do, however, think that supporting an easy workflow for Flex projects will improve early adoption. It's much easier to say "let's build this custom component using Reflex", than it is to say "let's build the whole application using Reflex" - for the near term at least. :-)

Arpit - So, some of these issues (collection dependancies, effects, etc) are certainly going to come into play later on. It's an important goal I think we've agreed on not to have dependancies on ArrayCollection or other, sometimes bloated, Flex classes - but we're still interested in supporting the use of these classes, where reasonable, through interfaces such as IList. Ideally, I'd like to support using lists with Array only, without wrapping it in a collection. Dependancies on a collection event and a few interfaces may still be pulled in by the default list component, but it should be pretty light. Anyways, I think we're tabling those issues for later so that we can get the core component model setup. We'll get there slowly, but surely.

- Ben

[Tyler Wright]

Something to keep in mind whether we extend UIComponent or not - two component sets existing in the same Flash Application will likely have difficulties with focus management. Because the Flash Player focus management is global you have to be careful about who else is using it - I assume we still want to support accessibility, etc. I don't know what Flex focus management is like under the hood but it's often necessary to hijack the default focus management in order to provide a moderately robust feature set. I suspect we'll have to do retrofitting to get the two to play nicely.

The whitepaper is excellent Ben, thanks for providing that. I'm still not sure if I'm sold on the specific Interface setup but I'm reviewing to see if I have any alternate suggestions. Either way this is a good starting point for the project.

Tyler

[Ben Stucki]

Agreed. Focus management is sometimes a pain point in Flex (especially in use with modules and loaded swfs) because of this reason. Flex uses it's own FocusManager singleton, but by extending UIComponent and/or playing nice with a few small interfaces we should be fine in the Flex workflow. We'll want to address focus management and accessability when using the non-flex workflow pretty early though. Hopefully we can keep away from having "manager" singletons, but we'll have to think about what the alternative is, since it is inherently global.

- Ben