Metadata, use it or lose it?

[Jacob Wright]

We currently have support for metadata in our framework, however I would like to put forth the argument that it should go away. I actually like the metadata, but there are pros and cons to it and I want to do the best thing for the framework, so I'd like to get your feedback.

Current Usage

We are currently using metadata in binding and behaviors. Binding metadata, assuming we aren't using the event property changes, isn't needed and just says to the user "this setter is bindable". Behaviors use it to set up binding and events in the same way that Bind can. Example:

[EventListener(type="stateUp", target="target")]

public function onStateUp(event:MouseEvent):void {...}

vs

public function ButtonBehavior()

{

Bind.bindEventListener("stateUp", onStateUp, this, "target"); // at the top of the behavior

}

public function onStateUp(event:MouseEvent):void {...}

So you can see that either way you're adding one line to set up the bind for an event listener. There is also [Binding] and [PropertyListener] that do the same as Bind.addBinding and Bind.addListener.

Pros

• it can be more readable
• it can be more concise, though not in the case of behavior really
• It's cool

Cons

• slow, you have to use a cache if you don't want to kill your app
• heavy, you use up memory storing all the XML in said cache (for every object that has binding and every behavior)
• no autocomplete (FDT might now actually), can be hard to remember tag names and settings that go in them
• does not work in Flash CS4/5

If we were to take metadata out completely of the core of Reflex we would increase startup time (because we'd eliminate those initial calls to describeType), we would decrease memory (no storing of the XML reflection data), and we would always be compatible with Flash CS4/5/6/etc. In addition, I would put forth that it might be more difficult to get into Reflex trying to remember the 3 metadata types for behaviors and their required properties without useful autocomplete. And lastly, and probably least, file-size would be slightly smaller because 1. the swf wouldn't be storing the metadata and 2. we wouldn't have the utility classes used to work with metadata linked into the code-base. This would probably be only 1k or 2k difference though, no biggie.

What do you guys think? Should we go for compatibility and performance, or ease-of-use in this case? Is it that much more performant without? Or, is it that much more easy to use with?

Jac

[Tyler Wright]

[EventListener(type="stateUp", target="target")]

public function onStateUp(event:MouseEvent):void {...}

The above looks nicer IMO, but forces you to scope your listeners to the public namespace, adding API where it shouldn't be added. To me that is the biggest reason to use the example shown below.

 

public function ButtonBehavior()

{

Bind.bindEventListener("stateUp", onStateUp, this, "target");

}

private function onStateUp(event:MouseEvent):void {...}

Tyler 

[Robert Penner]

> If we were to take metadata out completely of the core of Reflex we would increase startup time

I think you mean increase startup _speed_, decrease startup time. =)

Generally, I'm not in favour of doing something in metadata that can
easily be done in ActionScript, which is more type-checked and
debuggable.

Robert

> To unsubscribe from this group, send email to
> reflex-platform+unsubscribegooglegroups.com or reply to this email with the
> words "REMOVE ME" as the subject.
>

[craig w]

+1 for what Mr. Signals, I mean Robert, said.

[Paul Taylor]

The metadata looks nicer, but it introduces a layer of "magic" between
the Behavior developer and the framework that isn't evident. Adding
event listeners and creating bindings yourself is explicit, straight
forward, and relatively easy. I think keeping the framework simple is
a higher priority than worrying about developers having to write a few
more lines of code per behavior. If we're really bothered by it down
the road, we can write an EventMap into Behavior, like RL has in their
Mediators.

Paul

On Mar 26, 5:39 pm, Tyler Wright <xty...@gmail.com> wrote:
> > [EventListener(type="stateUp", target="target")]
> > public function onStateUp(event:MouseEvent):void {...}
>

> The above looks nicer IMO, but forces you to scope your listeners to the *
> public* namespace, adding API where it shouldn't be added. To me that is the

[viatropos]

Hey,

Our framework too initially had lots of metadata because it makes code
DRYer, makes it easier to read, and makes it more exciting to program
because a little goes a long way (hello dynamic languages). But
eventually it increased the startup time too much. But I really love
the whole metadata thing.

One thing I tried that was decently successful at descreasing startup
time (b/c of the xml parsing and such), was to pre-build all metadata
nodes into Directives (I used Openflux's idea of a Directive), and
added that into the application via a mixin. So you'd have a huge
method something like this:

public static function init(systemManager:*):void
{
var metadataByClass:Object = {};
var metadata:Object = {};
var directivesByTag:Object = {};
var directives:Array = [];
var tag:String = "EventHandler";

var directive:EventHandlerDirective = new EventHandlerDirective();
directive.dispatcher = "component";
directive.handler = "myHandler"
directive.priority = 10;
directives.push(directive);
metadata[tag] = directives;
// ...
metadataByClass["mx.controls.Button"] = metadata;
MetadataManager.metadataByClass = metadataByClass;
}

All that was generated by hacking MXMLC trace output using Project
Sprouts in Ruby, so I could run a basically headless app, process all
my components using the MetadataManager class, and print out
actionscript code into that MetadataMixin.init method. I'd use that
for deployment to cut down on startup costs by a decent amount.

It also cut out having to deal with XML entirely. But Flex would
still use it's own DescribeTypeCache, so it was kinda pointless there,
but with Reflex, if there were no describeType calls, it might help.

But it doesn't get rid of the "keep objects in memory" part.

What would work, however, that would give us the best of both worlds,
is customizing the compiler. If all metadata was defined in such a
way that it mapped directly to a small actionscript code block, then
you could convert metadata into pure actionscript at compile time (say
only for Production mode). This way [Bindable] would be converted to
getters/setters with dispatchEvent, [EventHandler] would be converted
to "addEventListener", etc. That wouldn't be too hard to implement.
I even think one could rebuild the MXMLC compiler in ruby (or at least
a low-level wrapper for it).

Metadata gives you a huge productivity and confidence boost when
programming, but it comes at a performance cost. The performance cost
could be mostly eliminated if all metadata could be mapped directly to
actionscript code, which it should be able to.

Just some thoughts,
Lance

On Mar 26, 5:13 pm, craig w <codecr...@gmail.com> wrote:
> +1 for what Mr. Signals, I mean Robert, said.
>

> On Fri, Mar 26, 2010 at 6:43 PM, Robert Penner <i...@robertpenner.com>wrote:
>
>
>
> > > If we were to take metadata out completely of the core of Reflex we would
> > increase startup time
>
> > I think you mean increase startup _speed_, decrease startup time. =)
>
> > Generally, I'm not in favour of doing something in metadata that can
> > easily be done in ActionScript, which is more type-checked and
> > debuggable.
>
> > Robert
>

[Baz]

I also think using the metadata is much nicer, but the cost seems too
high. The "1k or 2k difference" is significant for far removed
sub-system helper functionality, that kinda-sorta isn't even part of
the *real* framework. It's a slippery slope and those will add up - I
think you should be very stingy with your k's. For my desktop I run
TinyCoreLinux [tinycorelinux.com] which is a 10mb linux distro that
reminds me a lot of this project for their focus on streamlining and
minimizing bloat. You add what you need. At the beginning I was
annoyed a couple of times at some decisions they made not to include
some convenient features, but after following the project for a year,
I realized that they are constantly faced with those decisions, and if
they hadn't made the tough choices, the distro would be 20mb-30mb (not
suitable for embedded applications for example) and a very different
beast. I like viatropos' suggestions as they seem to let us have our
cake and eat it too, but I don't know enough to comment on its
feasibility.

Cheers,
Baz

[Baz]

One more thing... The single most important draw of the framework so
far as I see it, is the anti-bloat-lightness of it. At this stage,
barring any hard evidence (i.e. overwhelming user complaints) I would
always choose to err on the side of efficiency, then, as Paul
mentioned, slowly and begrudgingly add the conveniences that are
needed. This will also simplify and accelerate the development
process.

Cheers,
Baz

[Jos Yule]

I work with many shops which only have the Flash IDE, so i'm in favour of no metadata, simply so i can use these libraries with those clients.

j

ps. Robotlegs uses some metadata, but also has a way of suppling the required meta-info via XML. I wrote a small utility which looks at the source as files and generates the XML. While this isn't ideal, it was a way to get Robotlegs working with the Flash IDE.

[Marvin Froeder]

Guys, what about an metadata that is processed by the flex compiler and then turned into the target as3 code?

Andrew and I have patched flex SDK to allow you adding (or even removing) metadata extensions....  that way you could enable metadata for those (like me) who prefer the metadata way and the programmatic version for those (like Jos) who can't use metadata for some reason.

What do you think?  We should be submitting the patch to Adobe soon.


VELO

[Andrew Westberg]

To expand on what Velo said...

If you want take metadata tags and turn it into AS3 code, you specify that compiler extension's jar file on the cmd line.  If you want to keep the metadata or do X with it, you can specify another.

While we haven't coded up the actual extension code yet, we have enough to send to adobe so the proper hook can be in place for the next compiler release.

-Andrew Westberg

[Jacob Wright]

Cool. So for now I think we should go without metadata and then add it as we can. I'll be posting some How-Tos soon for people to get into building behaviors, skins, and components. Then we can all get into creating the components in a standard way while the core is still being solidified. I'll let you know when it's posted.

Jac

[Ben Stucki]

Hi all. This is an issue we've debated a lot since the very inception of the framework, and each of us on the team have been back and forth on it individually. After taking some time to really think it through I have to be in favor (strongly in favor) of using metadata. As Baz inadvertently pointed out, most projects with such a high focus on being light-weight become relegated to specific outside use cases. That's not what we want for this framework. We want to make something everybody will use, and we believe that our other goals do not have to impact features or workflow. Usability is also a high level priority for us.

Metadata & Magic

Take a moment to think about the ideal workflow for creating a behavior. If metadata and the inline code were on equal size and performance terms, which would you really prefer? If you haven't looked at these workflows you might need to.

Here's a behavior with metadata: http://github.com/benstucki/reflex/blob/master/src/reflex/behaviors/ScrollBehavior.as

Here's the same behavior with inline code: http://github.com/jacwright/reflex/blob/master/src/reflex/behaviors/ScrollBehavior.as

I'm going to guess that you prefer the metadata, and I'll tell you why. I think whether or not you use metadata there is still going to be magic in these classes. Which is to say that what's going on under the hood is largely hidden. If there were no magic for example, you would be required to manually add/remove all listeners each time the host component is changed, or the host component's skinPart or variable... etc. Understanding this magic might be somewhat strait-forward for us on the list because we could code it ourselves, but that's not true for most of the people we want using the framework. Now I think the difference between inline and metadata is how that magic is documented. Using metadata makes the magic self documenting, and therefore easier to understand. Inline code sends the magic down into an api call, which is more difficult to understand. Now I definitely don't like metadata for everything, but it is perfectly suited for this.

Alternatives

If we can agree on that, let's take the equality out of the picture. We would, if we could, use metadata. It is a better workflow, but we would have to sacrifice size, performance, etc - and we're not sure what we're willing to trade off. I take this as a problem to be solved, not a given. Like everything else in the framework, let's offer a viable solution. As Marvin and Andrew have pointed out we can offer some compiler preprocessing/hooks to automatically generate inline code for our metadata when using our compiler. This means that anyone using Flash Pro would have to use the provided swcs, but otherwise everything would be fine. I think this is the ideal solution, and it's one we actually agreed on during a Skype call months ago. I think the fact that two groups reached it independently should serve as validation.

So, I would suggest we continue using metadata in our code-base with the intent to provide compiler customization and swcs which are compatible for use with Flash Pro. I don't think we can afford to sacrifice ease of use and ultimately reflex adoption for outside use cases where a hardcore fanatic isn't willing to use the swc (or just compile their own). Thoughts?

- Ben

[viatropos]

+1. I love metadata a ton for all the reasons you've outlined. I
basically took Openflux back in the day and added a ton of behaviors
to make it into this site (http://www.josephjewell.com/), but after
having about 60 behavior classes and about 20 custom components all
using a lot of metadata, metadata alone added about 2-3, maybe even 5,
seconds to the load time, so I had to completely remove it in the end,
though I'm still using some. Once it was all set up though, after the
app loaded, everything ran fine. It was just that initial processing
that sometimes would make the app freeze for a second or two (in
addition to the million other things that you have to optimize with
Flex that you don't get out of the box).

So I had to really sit down and be like "sigh, we're gonna have to
manually add and remove the event listeners in those 60 behaviors,
manually set up those [ModelContract]'s, etc. Are we cool with
that?" All I was thinking about was Spark's "partAdded/partRemoved"
methods, which are exactly that: add listeners and set properties in
the first, remove them in the second. Writing them is just too
repetitive. The only thing that was motivating about that shift away
from metadata was the startup performance gain. But to be honest, I
was looking into the Flex compiler for a few weeks to see if I could
add custom extensions that would convert metadata to raw Actionscript
because that would've been more fun than removing the metadata.
Metadata is just so clean and so clear. Never ended up going the
compiler route b/c it was a little too involved :), but if there is
one thing that I think would solve this problem completely, it would
be the ability to write custom compiler extensions in a day that would
convert metadata into code. If I had that, man, metadata would be
even more powerful.

Here's a random article somewhat related that just reminds me how neat
metadata or "magic" is:

http://yehudakatz.com/2009/06/04/the-importance-of-executable-class-bodies/

While Actionscript doesn't have executable class bodies and isn't a
dynamic language, Metadata kind of makes it like so. I like that.

I vote for the compiler extension and Flash Pro compatible swcs.

Best,
Lance

On Mar 29, 8:25 am, Ben Stucki <benstu...@gmail.com> wrote:
> Hi all. This is an issue we've debated a lot since the very inception of the
> framework, and each of us on the team have been back and forth on it
> individually. After taking some time to really think it through I have to be
> in favor (strongly in favor) of using metadata. As Baz inadvertently pointed
> out, most projects with such a high focus on being light-weight become
> relegated to specific outside use cases. That's not what we want for this
> framework. We want to make something everybody will use, and we believe that
> our other goals do not have to impact features or workflow. Usability is
> also a high level priority for us.
>

> *Metadata & Magic*

> Take a moment to think about the ideal workflow for creating a behavior. If
> metadata and the inline code were on equal size and performance terms, which
> would you really prefer? If you haven't looked at these workflows you might
> need to.
>

> Here's a behavior with metadata:http://github.com/benstucki/reflex/blob/master/src/reflex/behaviors/S...
> Here's the same behavior with inline code:http://github.com/jacwright/reflex/blob/master/src/reflex/behaviors/S...

>
> I'm going to guess that you prefer the metadata, and I'll tell you why. I
> think whether or not you use metadata there is still going to be magic in
> these classes. Which is to say that what's going on under the hood is
> largely hidden. If there were no magic for example, you would be required to
> manually add/remove all listeners each time the host component is changed,
> or the host component's skinPart or variable... etc. Understanding this
> magic might be somewhat strait-forward for us on the list because we could
> code it ourselves, but that's not true for most of the people we want using
> the framework. Now I think the difference between inline and metadata is how
> that magic is documented. Using metadata makes the magic self documenting,
> and therefore easier to understand. Inline code sends the magic down into an
> api call, which is more difficult to understand. Now I definitely don't like
> metadata for everything, but it is perfectly suited for this.
>

> *Alternatives*

> > On Mon, Mar 29, 2010 at 7:09 AM, Andrew Westberg <andrewwestb...@gmail.com

> > > wrote:
>
> >> To expand on what Velo said...
>
> >> If you want take metadata tags and turn it into AS3 code, you specify that
> >> compiler extension's jar file on the cmd line.  If you want to keep the
> >> metadata or do X with it, you can specify another.
>
> >> While we haven't coded up the actual extension code yet, we have enough to
> >> send to adobe so the proper hook can be in place for the next compiler
> >> release.
>
> >> -Andrew Westberg
>

> >> On Mon, Mar 29, 2010 at 9:02 AM, Marvin Froeder <velo...@gmail.com>wrote:
>
> >>> Guys, what about an metadata that is processed by the flex compiler and
> >>> then turned into the target as3 code?
>
> >>> Andrew and I have patched flex SDK to allow you adding (or even removing)
> >>> metadata extensions....  that way you could enable metadata for those (like
> >>> me) who prefer the metadata way and the programmatic version for those (like
> >>> Jos) who can't use metadata for some reason.
>
> >>> What do you think?  We should be submitting the patch to Adobe soon.
>
> >>> VELO
>

[Andrew Westberg]

Marvin and I should have a JIRA bug for you all to vote on later this afternoon that gives us a hook for Metadata processing in the flex compiler.  I'll post it here when I have the link.

-Andrew Westberg

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Marvin Froeder]

May be we could share our tampered flex SDK for now? what do you think? So people can start playing with it....

I already drop the word and swiz guys wanna see that in action too ;)

VELO

[Jacob Wright]

I think there is no question about whether metadata is nicer to use. The only question is whether it is worth it. I believe we've come to the conclusion that it is currently not worth it, if not for the performance issue for the Flash IDE compatibility.

In the spirit of open source with release early release often I think we should go without metadata right now until we are able to finalize a suitable alternative with a custom SDK or extensions to the existing SDK.

 

So I had to really sit down and be like "sigh, we're gonna have to
manually add and remove the event listeners in those 60 behaviors,
manually set up those [ModelContract]'s, etc.

The binding methods hide the complexity of adding and removing event listeners. See my post about building behaviors.

Jac

[Baz]

As Baz inadvertently pointed out, most projects with such a high focus on being light-weight become relegated to specific outside use cases. 

Glad I could help, haha. Just out of curiosity, is it because you consider TCL a fringe project?

[Ben Stucki]

Hey Baz. Sorry about that. I'm not that knowledgeable on the Linux community. This is the first time I've heard of TCL, but I've worked with Fedora & Ubuntu (if I'm even categorizing the project correctly). From that limited perspective and possibly because of poor education on the subject I do consider it a fringe project (although by comparison to Reflex I'm sure it's quite large). My point is exactly that though. We can't expect people to be thoroughly self-educated on Reflex when they encounter it, but we are responsible for how they view it. For us, making our code both elegant and easy to understand is a big part of that. If we don't use metadata I think 90% of people will see their first bindProperty call before reading any documentation or tutorials, but it's not going to be as immediately recognizable as the metadata equivalent (and digging into the call will only get worse). I think we're responsible for that experience as much as anything else in the framework, and I think it's important for adoption.

- Ben

On Mon, Mar 29, 2010 at 11:34 AM, Baz <b...@thinkloop.com> wrote:

As Baz inadvertently pointed out, most projects with such a high focus on being light-weight become relegated to specific outside use cases. 

Glad I could help, haha. Just out of curiosity, is it because you consider TCL a fringe project?

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Ben Stucki]

I haven't come to that conclusion. You've come to that conclusion and that's fine, but I don't want to be rolled into the we category. I'm not sure why we're sacrificing the best workflow right now for performance which we haven't tested or validated yet? Let's use the best workflow until we know what the trade off is - or until someone even has a use case where they're not happy with performance. We're not only optimizing too early here, but we've made it harder to use in the process.

I said I would wait to see what the inline code looks like, because I'm all for speed and performance. I saw it, and I think we should keep moving forward with metadata. I don't think we can afford to lose broad adoption now for Flash IDE people who aren't even using the framework yet! Is Grant using the framework? No. Will he ever use it if nobody else does? Probably not. Will we have support for use in the Flash IDE by the time he does? Yeah, probably.

I'm in favor of using metadata now to show ease of use and to not require code changes when the compiler modifications come in.

- Ben

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Jacob Wright]

Just to be clear, if metadata worked with the Flash IDE I would be all for it and work out performance later. I don't think we can make the assumption that 90% of people will not understand how to use bindProperty but will understand how to use the metadata. But I do think we can make the assumption that 100% of the people using the Flash IDE will not be able to use Reflex if it relies on metadata.

I appreciate your ferver, but we need a solution that works. We need to come up with a solution to the problem, not just ignore it. If we decide that Reflex is going to be a Flash Builder only framework, then that's a different topic we should discuss, with metadata being a pro for it.

Jac

[Ben Stucki]

Alright, let's not assume then. Let's find people who use the Flash IDE solely and will not use FlashBuilder for this project. I don't. You don't. Most people on the list don't. That's where I'm basing my assumption, but I honestly would like to find these users and support them. Are they unhappy waiting for the compiler fix? Are they unhappy with using a swc? They need to be on the list and speak up.

The idea that bindProperty is more difficult to understand might also be an assumption, but then why do you prefer metadata if not because it's easier to understand? I would argue that it's more intuitive for wiring and magic to have explicit properties (type="pess", target="thumb" as opposed to just method("click", thumb)) and it's also less error prone to have the metadata annotated to the function/property involved (it's easier to recognize when you've missed something). I don't think this is purely personal preference (I think there is a quantifiable distinction), but how do we validate it? We'd have to do user studies or something.

- Ben

[Tyler Wright]

I haven't come to that conclusion. You've come to that conclusion and that's fine, but I don't want to be rolled into the we category.

These are good discussions to have and are important for the long term vision of the project. However I think there should be a clear distinction about now and finally. Right now it doesn't matter if we support metadata or not. Everyone on the project is of a sufficient level of understanding that neither method is going to lose or confuse them.

The argument to use metadata because we can't "afford to sacrifice ease of use and ultimately reflex adoption" when combined with the need for compiler hooks doesn't really stand up either.

an aside:

Just to be clear, is it a decision to require compiler modifications, or are we still pushing for a default workflow for the unmodified FlexSDK? This may need to be a new thread, but if the decision is to have a dependency on compiler hooks then we're wasting time with monkey patching solutions.

 

I'm not sure why we're sacrificing the best workflow right now for performance which we haven't tested or validated yet?

Lance already cited real performance issues using OpenFlux. We have already admitted to the added file-size as well.

 

Let's use the best workflow until we know what the trade off is - or until someone even has a use case where they're not happy with performance. We're not only optimizing too early here, but we've made it harder to use in the process.

I'm against using metadata because it forces my event listeners to be public, and having a public onThumbDrag in my published API is more of a usability problem than teaching a developer how to use binding. When we resolve this with hooks and generated AS3 and completely avoid describeType then I can be happy with metadata.

 

I said I would wait to see what the inline code looks like, because I'm all for speed and performance. I saw it, and I think we should keep moving forward with metadata. I don't think we can afford to lose broad adoption now for Flash IDE people who aren't even using the framework yet! Is Grant using the framework? No. Will he ever use it if nobody else does? Probably not. Will we have support for use in the Flash IDE by the time he does? Yeah, probably.

You are alone in the believe that the use of metadata directly effects the broad adoption of Reflex. I hope it can be a nice enhancement and a feature that makes some specific workflows nicer.

 

I'm in favor of using metadata now to show ease of use and to not require code changes when the compiler modifications come in.

I'm all for figuring out a metadata inclusive workflow. I don't care if it's in right now or not. My problem with public listeners can be solved later. But in the end I don't want describeType being used as the solution.

Tyler

[Jacob Wright]

> Alright, let's not assume then. Let's find people who use the Flash
> IDE solely and will not use FlashBuilder for this project. I don't.
> You don't. Most people on the list don't. That's where I'm basing my
> assumption, but I honestly would like to find these users and
> support them. Are they unhappy waiting for the compiler fix? Are
> they unhappy with using a swc? They need to be on the list and speak
> up.

True. Most of these people probably don't attend 360Flex where most of
the awareness of Reflex started. We need to get to FITC or similar
things. We will also need to be a little more filled out since they
would likely use it but not as likely code on the core.

If you think about it, the Flash IDE users have no alternatives for
robust components with layout and all that. We have Flex at least. I
would speculate a bigger splash with that group than with Flex devs.

> The idea that bindProperty is more difficult to understand might
> also be an assumption, but then why do you prefer metadata if not
> because it's easier to understand? I would argue that it's more
> intuitive for wiring and magic to have explicit properties
> (type="pess", target="thumb" as opposed to just method("click",
> thumb)) and it's also less error prone to have the metadata
> annotated to the function/property involved (it's easier to
> recognize when you've missed something). I don't think this is
> purely personal preference (I think there is a quantifiable
> distinction), but how do we validate it? We'd have to do user
> studies or something.

I meant they'll need to look at tutorials to build a behavior in
either case. I don't think one or the other helps to teach behavior
building without docs of some sort. But yes, metadata does look nicer.

Personally I would like to be able to use Reflex in Flash IDE
projects. We can make a case against it if we feel metadata is more
important.

Jac

[Paul Taylor]

Let me clarify my earlier statements about metadata magic and API. For
now I'm going to ignore the issues of no metadata support in Flash
Pro.
If I were writing a framework for myself, I would choose metadata over
explicitly binding properties any day of the week. I hate writing
unnecessary code.

My comment about magic was really this: The bindings and listeners are
generated through reflection, which happens in the constructor of
Behavior. Therefore a developer must know about and extend from the
base Behavior class. If a developer tries to write an IBehavior
without extending Behavior, all their previous knowledge about
supported metadata is useless. If that's the case, why have an
IBehavior interface in the at all? If the choices are Metadata that is
processed in the constructor, or no metadata and we force developers
to learn the inner workings of the binding API, I'd to choose the
latter because I love polymorphism.

I see at least two solutions to the issues I have w/ metadata. One, a
custom compiler which generates AS3 on any class that declares this
metadata. Only problem with this is I don't know if we can guarantee
everyone using Reflex will be using this custom compiler.

The second solution is Injector-like functionality in
CompositeBehavior. I know it's not perfect. For one, it would add one
more step between adding a Sprite as the target for behaviors. But if
CompositeBehavior behaved like the Injector in RL, you could support
metadata and still keep things kosher w/ polymorphism.

Paul

> > On Mon, Mar 29, 2010 at 10:46 AM, Ben Stucki <benstu...@gmail.com> wrote:
>
> >> I haven't come to that conclusion. You've come to that conclusion and
> >> that's fine, but I don't want to be rolled into the we category. I'm not
> >> sure why we're sacrificing the best workflow right now for performance which
> >> we haven't tested or validated yet? Let's use the best workflow until we
> >> know what the trade off is - or until someone even has a use case where
> >> they're not happy with performance. We're not only optimizing too early
> >> here, but we've made it harder to use in the process.
>
> >> I said I would wait to see what the inline code looks like, because I'm
> >> all for speed and performance. I saw it, and I think we should keep moving
> >> forward with metadata. I don't think we can afford to lose broad adoption
> >> now for Flash IDE people who aren't even using the framework yet! Is Grant
> >> using the framework? No. Will he ever use it if nobody else does? Probably
> >> not. Will we have support for use in the Flash IDE by the time he does?
> >> Yeah, probably.
>
> >> I'm in favor of using metadata now to show ease of use and to not require
> >> code changes when the compiler modifications come in.
>
> >> - Ben
>

> >> On Mon, Mar 29, 2010 at 11:20 AM, Jacob Wright <jacwri...@gmail.com>wrote:
>
> >>> I think there is no question about whether metadata is nicer to use. The
> >>> only question is whether it is worth it. I believe we've come to the
> >>> conclusion that it is currently not worth it, if not for the performance
> >>> issue for the Flash IDE compatibility.
>

> >>> In the spirit of open source with release early release often<http://en.wikipedia.org/wiki/Release_early,_release_often> I

> >>> think we should go without metadata right now until we are able to finalize
> >>> a suitable alternative with a custom SDK or extensions to the existing SDK.
>
> >>>> So I had to really sit down and be like "sigh, we're gonna have to
> >>>> manually add and remove the event listeners in those 60 behaviors,
> >>>> manually set up those [ModelContract]'s, etc.
>
> >>> The binding methods hide the complexity of adding and removing event

> >>> listeners. See my post about building behaviors<http://jacwright.com/blog/407/how-to-build-a-behavior-in-reflex/>

[Baz]

Hey Baz. Sorry about that.

No worries my man! Nothing to be sorry about I was just curious what exactly you were referring to.

[Ben Stucki]

| You are alone in the believe that the use of metadata directly effects the broad adoption of Reflex.

You are alone in the omniscience to make such a statement, but I'll continue to stand by my belief. Thanks.

| However I think there should be a clear distinction about now and finally.

The problem with now and finally is that we are pushing for adoption now. When people look up Reflex they see examples from now. When they look it up in two years they get the same examples from now (even if there are new ones). I've been down this road a few times, and honestly I'm just trying to protect the project from the assumptions people make of it.

| Lance already cited real performance issues using OpenFlux. We have already admitted to the added file-size as well.

True and I certainly don't doubt there is impact, but what is it? Are we assuming nothing else impacted Lance's project? What are the numbers? We're making broad decisions here! + this is a now issue and can be resolved with the compiler. Is this performance issue going to effect people before we can modify the compiler?

| if the decision is to have a dependency on compiler hooks then we're wasting time with monkey patching solutions.

I think we should distribute with a modified compiler as a fully self contained sdk. I thought we already made that decision, yes. I think the monkey patching work is important as a first step to understanding our flex & compiler touch points.

| I'm against using metadata because it forces my event listeners to be public

We can use a custom namespace purely to protect the functions, and I'm all for that. It's not my favorite either, but it's simply lower than ease of use (and yes, adoption) on my list. If we eventually decide not to use runtime metadata (only compile time injection), then this might become a non-issue.

[Jacob Wright]

I'd like to sum up the discussion and focus on answering specific questions for the group to decide.

We'd all like to use metadata it seems if it worked the way we wanted it to in the situations we wanted it to. Let's decide whether metadata is worth sacrificing xyz for. Here are some of the problems presented.

• Affecting API: is having public event handlers a reason to abandon metadata? If not, is a custom namespace an acceptable work-around?
• Performance or custom compiler: is startup performance (for larger projects? and mobile apps) a reason to abandon metadata, or is requiring a custom compiler to counter startup performance a reason to abandon metadata?
• Flash IDE support: is support for using Reflex components/behaviors in the Flash IDE a reason to abandon metadata?

Note that we will probably end up with a custom SDK. The questions center around requiring using the custom SDK. This would preclude Flash IDE use as well as I understand it.

If we can decide on these 3 questions I think we can decide on metadata. Feel free to respond to each item. If there is a work-around we haven't discussed that needs to be included please add it.

Jac

[Tyler Wright]

| You are alone in the believe that the use of metadata directly effects the broad adoption of Reflex.

You are alone in the omniscience to make such a statement, but I'll continue to stand by my belief. Thanks.

You're welcome, and thank you for the high compliment! :)

| However I think there should be a clear distinction about now and finally.

The problem with now and finally is that we are pushing for adoption now. When people look up Reflex they see examples from now. When they look it up in two years they get the same examples from now (even if there are new ones). I've been down this road a few times, and honestly I'm just trying to protect the project from the assumptions people make of it.

Yes, I realize what you're trying to do.

| Lance already cited real performance issues using OpenFlux. We have already admitted to the added file-size as well.

True and I certainly don't doubt there is impact, but what is it? Are we assuming nothing else impacted Lance's project? What are the numbers? We're making broad decisions here! + this is a now issue and can be resolved with the compiler. Is this performance issue going to effect people before we can modify the compiler?

 

Again, I don't care what happens now. I just hope we don't end up using describeType as our solution for performance and API reasons. We are making a broad decision to support mobile and any performance gains are necessary there, unless the argument is that we don't know if there is a performance loss.

| if the decision is to have a dependency on compiler hooks then we're wasting time with monkey patching solutions.

I think we should distribute with a modified compiler as a fully self contained sdk. I thought we already made that decision, yes. I think the monkey patching work is important as a first step to understanding our flex & compiler touch points.

If that decision has been made then I missed it. It would be nice to discuss the project deliverable in more depth, probably in a new thread. We've talked broadly about Flash Pro, Flex and custom compiler workflows, but as these are starting to affect other discussions it should be clear what everyone wants/expects.

 

| I'm against using metadata because it forces my event listeners to be public

We can use a custom namespace purely to protect the functions, and I'm all for that. It's not my favorite either, but it's simply lower than ease of use (and yes, adoption) on my list. If we eventually decide not to use runtime metadata (only compile time injection), then this might become a non-issue.

I think using a custom namespace is less approachable than coded bindings. But compiler hooks should allow us to have private listeners if we're doing the coded binding generation.

[Andrew Westberg]

To clarify one point... If our compiler hooks get accepted into the 4.1 SDK, there is NO NEED to distribute a custom SDK with reflex.  All we'd have to ship is a single JAR file that is specified on the cmd line to mxmlc as follows:

-compiler.extensions.extension=ReflexExtension.jar

I'd also like to submit a separate patch to Adobe that will add extension support to their ANT tasks so that they can be specified directly in your build.xml.  Velo has already added this type of capability to Flex-Mojos for the Maven kids.

We WOULD have to ship a custom sdk UNTIL Flex 4.1 is released.  So this is a temporary thing.

-Andrew

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Marvin Froeder]

And we can start using our (Andrew and mine) tamped flex compiler right now.

So, turning [Metadata] into as3 code is available today.  Swiz guys wanna it to validade if their metadatas are valid, like compile time check.


VELO

[Jacob Wright]

Voting on the questions I asked:

• Affecting API: is having public event handlers a reason to abandon metadata? If not, is a custom namespace an acceptable work-around?

No, not a reason. Not such a big deal for me. The API docs might look weird with public clickHandlers etc, but whatever. 

• Performance or custom compiler: is startup performance (for larger projects? and mobile apps) a reason to abandon metadata, or is requiring a custom compiler to counter startup performance a reason to abandon metadata?

Yes. I think the performance is a concern especially for mobile apps. I would like to have a custom Reflex compiler to build an optimized swc, rewrite [Bindable], and do the monkey-patched solutions the right way, but I think it should be optional, not required. For easily getting into Reflex and for supporting Flash IDE.

• Flash IDE support: is support for using Reflex components/behaviors in the Flash IDE a reason to abandon metadata?

Yes. We are precluding a large group of people from using Reflex if we use metadata. And we are only making the contents of a behavior file a little less nice for the others. I feel we should support those people at the expense of metadata. Even if they happen to be a minority. Those who never used metadata won't know what their missing.

That's my vote.

[Jacob Wright]

To clarify one point... If our compiler hooks get accepted into the 4.1 SDK, there is NO NEED to distribute a custom SDK with reflex.  All we'd have to ship is a single JAR file that is specified on the cmd line to mxmlc as follows:

-compiler.extensions.extension=ReflexExtension.jar

I'd also like to submit a separate patch to Adobe that will add extension support to their ANT tasks so that they can be specified directly in your build.xml.  Velo has already added this type of capability to Flex-Mojos for the Maven kids.

We WOULD have to ship a custom sdk UNTIL Flex 4.1 is released.  So this is a temporary thing.

I think that will be great. Adding a jar or using a customized SDK is more about limiting our maintenance efforts with SDK releases. We would still require a person to download something extra (other than the swc) to compile a reflex project. And we would still be precluding Flash IDE users/projects.

In other words, the questions are still valid and still need to be decided on by the group. But for a Flash Builder workflow with styling etc. I think a custom complier would rock.

Jac

[Marvin Froeder]

Voting on the questions I asked:

• Affecting API: is having public event handlers a reason to abandon metadata? If not, is a custom namespace an acceptable work-around?

No, but I won't use event handlers if I can use Metadata

• Performance or custom compiler: is startup performance (for larger projects? and mobile apps) a reason to abandon metadata, or is requiring a custom compiler to counter startup performance a reason to abandon metadata?

I think all can be supported, so you can use API, or compile time metadata or runtime metadata.....  

• Flash IDE support: is support for using Reflex components/behaviors in the Flash IDE a reason to abandon metadata?

Nop.

[Marvin Froeder]

On Mon, Mar 29, 2010 at 4:01 PM, Marvin Froeder <velo.br@gmail.com> wrote:

• Performance or custom compiler: is startup performance (for larger projects? and mobile apps) a reason to abandon metadata, or is requiring a custom compiler to counter startup performance a reason to abandon metadata?

I think all can be supported, so you can use API, or compile time metadata or runtime metadata.....  

Just to clarify, to use compile time metadatas, you do need a an API, compiler time will just drop the metadatas of and put the code in place.

So API is a must to compiled metadata.


VELO

[Ben Stucki]

I'm a little afraid of a false choice in there. Sorry, really not meaning to drag it on. I think we all agree on the big points. We all want Flash Pro workflow support. We all want it to be easy to use. I think we're disagreeing a lot on what we do about it right now, but let's firgure out what the long term solution is, then figure out the short term plan.

Should we use a compiler extension/mod with metadata as the long term solution? This means users would have to download an extra jar or custom compiler to use the source, AND Flash Pro users would have to use compiled swcs for the framework and most 3rd party code.

Yes, I think this is our best option as it lets us use metadata AND support Flash Pro users. All remaining alternatives are Flash Pro vs. Metadata (and I'm not sure I'm willing to sacrifice either one).

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Baz]

We can't use the term "metadata" alone anymore... to be sure the options are:

1. Metadata through describeType 

2. Metadata through custom compiler

3. No Metadata

Right?

[viatropos]

Some of this discussion is about newcomers and how they feel, so I
thought I might express how I felt when I started with Openflux and
more advanced Actionscript say a year ago.

When I started using Openflux, I had already spent a few months using
Mate, and studying the DocumentBased example source code (http://
mate.asfusion.com/assets/content/examples/baseDocument). In there I
saw BindingUtils everywhere and it took me probably a solid two weeks
to figure out what was going on with that. After I realized how to
use it, it opened up a whole new realm of possibilities, I could do
programmatic binding! Then I checked into Mate's source and saw that
their entire library was built around basically that one method. It
took about 2 weeks to understand how that method worked (and I had to
start digging into the Flex SDK), but the experience was very
exciting. Same with Flight a while later. I saw the programmatic
binding and I was like "yeah! this is sick". But when it got down to
it, I always had the urge to try to abstract out the direct method
calls into metadata annotations. And the rest of the people I work
with who don't dig into the source code of these projects still don't
understand BindingUtils. But they understand and love metadata.

As a side note, that DocumentBased example is about the most complex
example project I've seen in Flex. I think it alone paved the way for
Mate's initial popularity of the "framework" market (http://
oreillynet.com/pub/pq/196). Check out the Mate forums and see how
many questions people asked about it and how thankful they were to
have such a thorough and advanced project to start from as they
experimented with a new framework.

But back to Openflux, when I first saw the metadata, I was like "no
way! this is soo easy!". Then I ran the sample applications and I had
3D layouts with hardly any code. I was stoked. Then I tried to
implement my own controllers: transformation controllers that work
just like Jack's TransformManager (http://www.greensock.com/
transformmanageras3/). I started coding but there was instantly a
huge barrier, "so [ModelContract], what is that?". And
[EventHandler], how does that work, does it do everything I want it
to? Why isn't this working? how does metadata work anyway?" Those
were my first questions. There not being any group or real
documentation, I just started digging into the code. And let me tell
you, it was tough. First I had to figure out all the keywords I
needed to know to learn things in this new field of metadata
(directive, annotation, reflection, dynamic programming...), then I
had to follow the flow in the code a hundred times until it finally
clicked. And there was nothing out there on "Actionscript Reflection"
that popped up in google. But now it's like second nature and I'd
never go back to no metadata. But it probably took a month to get a
solid grasp of how metadata worked on the inside.

So for newcomers to the project, my feeling is as long as there's
thorough documentation, a ton of examples, and lots of support, any
path will be fine (BindingUtils, Bind, [Bindable]), because all of
them are equally complex from a newcomers perspective, especially if
they want to work on the source code. I'd say though that if you
never want to learn the source of the code base you're using, most
people I've interacted with prefer metadata.

>    - Affecting API: is having public event handlers a reason to abandon

>    metadata? If not, is a custom namespace an acceptable work-around?

If there is a page on the site that says "Reflex has chosen to build
event handlers like X, and the pros and cons are Y", then the average
Actionscript person wouldn't think twice. The hardcore guys that
stick to best-practices and don't use public handlers I think would be
fine in writing the few extra lines of `use namespace metadata` or
whatever, for a custom namespace. I love doing that, it makes the
code more semantic in my opinion.

My vote: Opt-in Custom Namespace, public by default.

>    - Performance or custom compiler: is startup performance (for larger
>    projects? and mobile apps) a reason to abandon metadata, or is *requiring
>    * a custom compiler to counter startup performance a reason to abandon
>    metadata?

I think all metadata should be converted into pure Actionscript with a
custom compiler. I think the idea of a custom compiler sounds scary
(at least to a newcomer), is because there's no one blogging about it
in the Flex world, except like the Flex Mojos guys but that's so
disconnected from what I do. If people like you guys and Doug McCune
and Lee Brimelow started blogging about it as if it were just one of
those things you needed like TextMate or Github, I think it would be
just a normal part of the initial setup. It only takes like a minute
to install, and if there were video tutorials, it'd be fun. But only
if the custom compiler allows me to write custom metadata
processors :D without learning the whole of Java.

My Vote: Custom Required Compiler and lots of inspirational bloggers
using it.

>    - Flash IDE support: is support for using Reflex components/behaviors in

>    the Flash IDE a reason to abandon metadata?

I haven't known anybody that uses this, it'd be interesting to know
the stats. I think a custom SWC is way better than abandoning
metadata. If metadata were cut out, I know I would be discouraged
from contributing. I'd probably fork your guys' project and add
metadata :p.

My Vote: Custom Required Compiler and Custom SWCs

I most enjoy using metadata while coding and would do whatever it took
to make metadata be converted into something that worked universally
rather than cutting it out for compatibility.

Best,
Lance

[viatropos]

> 1. Metadata through describeType
> 2. Metadata through custom compiler
> 3. No Metadata
>
> Right?

Metadata through custom compiler! Wooo!

[Baz]

Custom compiler seems to solve all problems except for the biggy: Flash IDE support. I don't know much about Flash IDE, but is there no way to influence or change that compiler too?

[Jacob Wright]

Yes, I think this is our best option as it lets us use metadata AND support Flash Pro users. All remaining alternatives are Flash Pro vs. Metadata (and I'm not sure I'm willing to sacrifice either one).

Excellent! If this works then I vote for metadata. It seems to my memory that Tyler tried this and all the metadata was stripped from the swc when Flash IDE compiled it. So we need to double check and see if Tyler was smoking something or if it does indeed get stripped out.

I would think most IDE projects won't be involved in building up behaviors, just using them. So I think this is an acceptable approach. If it turns out that the metadata is stripped out, then I still vote against metadata.

Oh, and the reason why I don't vote for "no-metadata in the core but allow it for behavior builders" is that when we have our behavior library most of the behaviors submitted would use the metadata if we supported it.

Unless someone beats me to it, I'll try and test metadata in a swc that Flash CS4 uses. Or CS5 if it doesn't work in CS4.

Jac

[Marvin Froeder]

To use custom compiler metadatas you do need a an API, compiler time will just drop the metadatas of and put the code in place.

So w/o a solid API you can't use custom compiler metadatas.

Then Flash IDE person can go for this solid API.

On Mon, Mar 29, 2010 at 4:51 PM, Baz <b...@thinkloop.com> wrote:

Custom compiler seems to solve all problems except for the biggy: Flash IDE support. I don't know much about Flash IDE, but is there no way to influence or change that compiler too?

[Marvin Froeder]

  But only

if the custom compiler allows me to write custom metadata
processors :D without learning the whole of Java.

No donuts for you.  Flex SDK is written in Java, so the extensions are Java.

But it is not rocket science, if you can code as3 you can code an extension.  Just need to do that w/ zero documentation.


VELO

[Tyler Wright]

Then Flash IDE person can go for this solid API.

Jacob's point is that the Flash IDE person won't be able to use the many community contributions because of this limitation, they have to build everything themselves.

Ben suggested the Flash IDE person's use SWC's for community resources. This would work as long as the community (3rd parties) kept this in mind and released SWC's with their source.

I like Baz's line of thinking the most. Flash IDE users have had the short-end long enough, is there any way to customize the compiler for Flash Pro without running into legal problems? Who knows that system, Penner? :)

Tyler

[Marvin Froeder]

If the community SWC used [Metadata] they where already processed and turned into as3 code, so not a big deal here.

If the community SWC used the API, well, need less to say.

No matter which way you choose, you will end up with API....  face [Metadata] as an alternative way to as3 code.... but in the end it will be turned into code.  There will be no [Metadata] processing at runtime.


VELO

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Ben Stucki]

Jac, we're on different pages here. My belief (from Tyler) is also that Flash Pro will not keep metadata from swcs (though it's worth testing again). However, the swc from the custom compiler would have no metadata in it, as any metadata would have been used only for code generation in the custom compiler/extension (injecting the bindProperty, etc, during the process). That's what makes the swcs usable in Flash Pro. It's obviously not 100% perfect for Flash Pro people as their stuck using swcs (+ no metadata in their own code), but I think it's a worthwhile trade-off.

... Yeah, what VELO said.

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Jacob Wright]

Ohhhh, got it. So we would rewrite the metadata into the ActionScript version of the binding calls in the constructor. Ok, I think that will work out just fine.

Next question, what's the timeline? VELO? I can work with you on what the AS code should be for each piece of metadata. And could we throw errors if the metadata params aren't correct? That would help out a lot with simple typos and similar mistakes.

Jac 

[Tyler Wright]

I'm interested in trying out SourceMate, a FlashBuilder extension. They support metadata code-complete in FlashBuilder, which is really cool. Check out the demo:

http://cloudfront.elementriver.com/elementriver/sourcemate/v1/metadata/metadata.html?iframe=true&width=640&height=500

[Marvin Froeder]

Well, usually we can do anything, how much effort it takes is another matter.  But yes, validating the Metadata is piece of cake. At least validating if the arguments aren't misspelled. 

I beg we can validate even more...

[Jacob Wright]

So we're planning on distributing a Reflex SDK 4.0.x in order to build reflex projects? And a swc for those who don't want that? Is this what the group wants? (just want to verify, seems like a bigger decision in the product's future than whether to use metadata in behaviors or not)

Jac

[Marvin Froeder]

No, at least not at long term.... if you wanna it today, yes, you need a custom flex SDK,  but once adobe put this [1] in, reflex would only need to share a jar containing the extension.

If you don't wanna the extra jar, got the API way.  No body is pointing an weapon onto user head to use metadata...


VELO

[1] http://bugs.adobe.com/jira/browse/SDK-26041

On Mon, Mar 29, 2010 at 6:06 PM, Jacob Wright <jacw...@gmail.com> wrote:

So we're planning on distributing a Reflex SDK 4.0.x in order to build reflex projects? And a swc for those who don't want that? Is this what the group wants? (just want to verify, seems like a bigger decision in the product's future than whether to use metadata in behaviors or not)

Jac

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Teoti Graphix, LLC]

I’m using SourceMate, it does validate metadata and any custom metadata you want. I also uses code completion.

 

It will also put error marks in the Problems view if the metadata is not correct.

 

Mike

 

---

[Ben Stucki]

Yeah, that's my vote. If we just use an extension we only have to distribute the jar, but I think we should go ahead and commit to a full sdk download. I think the instructions are actually easier for this as they just have to add a new Flex sdk, plus I'm sure we get to add more stuff like using rx:Application as the default for New > MXML Application, and keeping all the Flex classes out of the code hinting, etc. - and I think it'll make more sense as a "Flex Alternative" that way.

On Mon, Mar 29, 2010 at 4:06 PM, Jacob Wright <jacw...@gmail.com> wrote:

So we're planning on distributing a Reflex SDK 4.0.x in order to build reflex projects? And a swc for those who don't want that? Is this what the group wants? (just want to verify, seems like a bigger decision in the product's future than whether to use metadata in behaviors or not)

Jac

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Tyler Wright]

So we're planning on distributing a Reflex SDK 4.0.x in order to build reflex projects? And a swc for those who don't want that? Is this what the group wants? (just want to verify, seems like a bigger decision in the product's future than whether to use metadata in behaviors or not)

We are investigating doing hooks for the whole list of customizations we've talked about:

• styling
• MXML states
• MXML binding
• [Bindable]
• other metadata tags (in Behaviors)

The hooks will at least be a nice alternative to monkey-patching and no-meta. Some of us are convinced that this is the best approach and some are not unsure of the consequences. I'm on the fence, and even though I don't think we have to decide on everything up front I'm beginning to be convinced that we should make a decision and put it to bed.

Tyler

Still thinking...

[Jacob Wright]

If you don't wanna the extra jar, got the API way.  No body is pointing an weapon onto user head to use metadata...

True, but they wouldn't be able to compile the Reflex behaviors themselves without it. I feel like this is a big decision and I'm not sure if it is the right way to go for user adoption. It seems like a custom SDK might be a bigger deterrent to using Reflex than no metadata. And even though OpenFlux had lots of nice metadata, it never exactly became mainstream (not saying because of it's metadata, just saying that didn't make/break the project).

If we have to wait around for Adobe to implement a patch before we feel comfortable with this, I would vote for refactoring to metadata in the future once we have that compiler. VELO told me "custom SDK it is not the way to go" and is hoping for the patch sooner rather than later. I would definitely rather refactor behaviors later than hold up development now. And it would be a shame to not be able to show any Flash IDE workflow demos until Adobe releases the patch in a general 4.1 release (they just came out with 4.0).

Thoughts on what we should do now while we wait? I want the project to continue forward whether it's a custom SDK now or whatever. I still don't feel great about it, but I'm willing to go with the community of course. I'll shout-out to everyone who isn't following the thread too.

Jac

[Marvin Froeder]

For today a custom SDK is the unique alternative.  I just think it is not the way to go on the long term.

Today, no alternative.


VELO

To unsubscribe from this group, send email to reflex-platform+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Tyler Wright]

Thoughts on what we should do now while we wait? I want the project to continue forward whether it's a custom SDK now or whatever. I still don't feel great about it, but I'm willing to go with the community of course. I'll shout-out to everyone who isn't following the thread too.

I say leave it for now, we can refactor either direction later. We'll continue using the metadata on public listeners and keep describeType and focus on building the components. Changes will be easy. There are pros/cons on both sides and we really ought to let CS5 come out first before we get too excited about any solutions. I have a feeling there will be some significant changes to the way we see things today.

Tyler

[Jacob Wright]

Thoughts on what we should do now while we wait? I want the project to continue forward whether it's a custom SDK now or whatever. I still don't feel great about it, but I'm willing to go with the community of course. I'll shout-out to everyone who isn't following the thread too.

I say leave it for now, we can refactor either direction later. We'll continue using the metadata on public listeners and keep describeType and focus on building the components. Changes will be easy. There are pros/cons on both sides and we really ought to let CS5 come out first before we get too excited about any solutions. I have a feeling there will be some significant changes to the way we see things today.

Ok. And CS5 is out on the 12th!

[gskinner]

I was invited to add my thoughts here by Ben. I will admit almost
complete ignorance of Reflex, and the underlying architecture, so
please feel free to completely disregard my contribution. This is also
written quite hastily, so forgive any typos or incomprehensible
statements.

I have worked on my fair share of components, framework, and open
source libraries, so I very much understand the current crisis.
Developing public code is about trade-offs: Simplicity or robustness?
Performance or abstraction? Familiarity or innovation?

I would start by asking, "what makes Reflex valuable and unique?".
Flex provides a robust, widely adopted UI framework with decent
tooling support - with framework caching, it's even fairly small.
Minimal offers an extremely lightweight, extensible component set for
Flash and ActionScript projects. Simply targeting the gap between them
isn't very compelling.

In watching Reflex, the potential that interested me was in an
approachable, cross-IDE UI Framework with a balanced feature-set and
footprint, and a lot of transparency / extensibility.

In my opinion, relying on meta data and compiler extensions eliminates
most of those value propositions. It makes Reflex IDE specific. It
raises the barrier to entry (I would be unlikely to install a compiler
extension to use Reflex). It makes the framework more opaque, and
therefor harder to extend.

My proposal to you, would be to focus on a strong pure AS
implementation, then decorate it for each environment. Layer on Flash
Pro component support, MXML support, and metadata shortcuts. Take
advantage of the strengths of each environment, but don't create
dependencies on them. Ensure that when you document these IDE specific
approaches, that you always provide a code snippet demonstrating how
to achieve the same thing with AS. Magic is great, so long as it comes
with a manual.

Being able to move UI from Flash Pro to FlashBuilder and vice versa is
a huge value proposition, and should help you drive adoption. It's
also worth noting that supporting both IDEs quadruples (at least) your
potential user base versus just supporting FlashBuilder.

This approach provides you with a strong philosophy for Reflex: "One
UI framework, everywhere." It maintains a completely transparent (and
portable) core of pure ActionScript, while leaving you free to provide
IDE specific workflow enhancements.

It also helps guide discussions around proposals like compiler
extensions. If part of your group wants to pursue that avenue,
encourage them to do so. So long as they don't alter the ActionScript
core, you risk nothing (except their time). If they are successful in
convincing Adobe to incorporate their changes, you may have a great
workflow story for FlashBuilder. If not, then your users are free to
choose whether they want to install a custom compiler extension, or
simply work with your ActionScript / MXML layer.

I'd write more, but I don't have a lot of free time at the moment.
Hopefully this has been helpful.

Reflex is looking great, and I wish you all the best with it.

Cheers,
Grant Skinner
gskinner.com

[Ben Stucki]

Hi all. I just wanted to be sure I responded to this since I asked Grant to comment - and since it looks like we'll probably move ahead with the custom compiler plan for now. I took a lot of time to weigh this because I don't take Grant's input lightly. So my apologies on waiting so long to get a response out.

| I would start by asking, "what makes Reflex valuable and unique?"

Reflex is, primarily, a Flex framework replacement. What makes Reflex valuable is that it provides a much better workflow for building Flash/RIA components. Everyone who works with Flex loves it at times and wants to throw it out a window at others. Some of these pain points are fundamental to Flex's architecture, and so we are building a community driven alternative that makes it easier to do the types of customizations required in real-world projects.


| ... Simply targeting the gap between them isn't very compelling.

I agree, but I don't think that's what we're doing. We intend to offer components fairly close to the size of Keith's that offer features comparable to Flex. So in that line of thinking we're really not in-between them. We're encompassing a lot of common ground on both sides. We're doing this using a pay-as-you-go model, so some features may add weight but only if you use them in your project.

In addition to fixing the light-weight vs. features debate, we feel like this project can bridge the gap between purely Flash devs and Flex devs. I think a lot of what caused this divide is the abstraction that Flex builds around the Flash APIs and the fact that it's an all-in system (you're forced to cope with every aspect of Flex to use almost any part of it). In contrast Reflex is staying very close to the Flash APIs, and many pieces of Reflex can be used independently of the whole. It feels a lot more like a Flash library.

| My proposal to you, would be to focus on a strong pure AS implementation, then decorate it for each environment.

I'm scared of this approach only because we hope to create a work-flow where even custom built pieces are reusable across all environments. The meta-data does cause a hiccup in this, because for items to be used in Flash they would have to be provided as a swc. However, using custom decorations for each environment would further enforce the segmentation we're trying to bridge.

| Being able to move UI from Flash Pro to FlashBuilder and vice versa is a huge value proposition, and should help you drive adoption.

I agree, and I think it is a primary goal. I'm not convinced it's time to give up on the meta-data just yet though. It's also important for us to preserve the improved work-flow we offer over Flex, and meta-data is a big part of making that approachable.

The way I think of the custom compiler is as an inconvenience to FlashBuilder users for the benefit of getting to use meta-data. If we force FlashBuilder (and FDT, etc) users to have the custom compiler, then any swc would be usable in Flash Pro. We can even output the interim AS3 for use in Flash Pro. I feel like this is pretty close to your goal of having an AS3 core with custom work-flows for separate tools, but I may be entirely off base.

| Reflex is looking great, and I wish you all the best with it.

Thanks. :)

[Jacob Wright]

| I would start by asking, "what makes Reflex valuable and unique?"

Reflex is, primarily, a Flex framework replacement. What makes Reflex valuable is that it provides a much better workflow for building Flash/RIA components. Everyone who works with Flex loves it at times and wants to throw it out a window at others. Some of these pain points are fundamental to Flex's architecture, and so we are building a community driven alternative that makes it easier to do the types of customizations required in real-world projects.

I would add, Reflex aims to be as small and light-weight as possible with the features used. You mention this below too.

 

| ... Simply targeting the gap between them isn't very compelling.

I agree, but I don't think that's what we're doing. We intend to offer components fairly close to the size of Keith's that offer features comparable to Flex. So in that line of thinking we're really not in-between them. We're encompassing a lot of common ground on both sides. We're doing this using a pay-as-you-go model, so some features may add weight but only if you use them in your project.

In addition to fixing the light-weight vs. features debate, we feel like this project can bridge the gap between purely Flash devs and Flex devs. I think a lot of what caused this divide is the abstraction that Flex builds around the Flash APIs and the fact that it's an all-in system (you're forced to cope with every aspect of Flex to use almost any part of it). In contrast Reflex is staying very close to the Flash APIs, and many pieces of Reflex can be used independently of the whole. It feels a lot more like a Flash library.

Yeah, exactly. Except now one particular piece (behaviors) won't be able to be used independently without using a custom Flex compiler. And importing a swc if you're in Flash Pro. Unfortunate, but necessary if we want to keep metadata.

 

| My proposal to you, would be to focus on a strong pure AS implementation, then decorate it for each environment.

I'm scared of this approach only because we hope to create a work-flow where even custom built pieces are reusable across all environments. The meta-data does cause a hiccup in this, because for items to be used in Flash they would have to be provided as a swc. However, using custom decorations for each environment would further enforce the segmentation we're trying to bridge.

I think he might have ment decorating for actual use, not when building up the components. This could be best if the same AS files worked in each environment, but there were decorators for when you built an application in each environment. The core would be the same everywhere, and you'd use pay-as-you-go extras when building apps in this environment or that environment. Such as using styling in Flash Builder apps, but not in Flash Pro apps. And maybe a nice utility in Flash Pro for working with it's skins.

 

| Being able to move UI from Flash Pro to FlashBuilder and vice versa is a huge value proposition, and should help you drive adoption.

I agree, and I think it is a primary goal. I'm not convinced it's time to give up on the meta-data just yet though. It's also important for us to preserve the improved work-flow we offer over Flex, and meta-data is a big part of making that approachable.

The way I think of the custom compiler is as an inconvenience to FlashBuilder users for the benefit of getting to use meta-data. If we force FlashBuilder (and FDT, etc) users to have the custom compiler, then any swc would be usable in Flash Pro. We can even output the interim AS3 for use in Flash Pro. I feel like this is pretty close to your goal of having an AS3 core with custom work-flows for separate tools, but I may be entirely off base.

It will be interesting to see how well a custom compiler is embraced by the community at large. This is a very Flex-user-centric list right now, and we're Flex users making allowances for Flash Pro users right now. I'm curious how a Flash Pro following will affect discussions.

Jac

[David Knape]

As a flash dev, I think the idea of using a framework that requires a custom compiler would be a show-stopper for me.  Getting what I needed from a SWC in Flash Pro might be alright.  As a flex dev and FDT user, a custom SDK or monkey patches would not be a huge hurdle.  As a potential contributor to the framework, I'm not enthusiastic about anything that requires a compiler hack. I understand why you want to do it, but I agree with Grant in that it raises the barrier to entry in a significant way.

-dk

--
David Knape
Programmer / Consultant

[Tyler Wright]

I understand why you want to do it, but I agree with Grant in that it raises the barrier to entry in a significant way.

Does having a custom SDK raise the barrier of entry more than requiring bindEventListener(...) over the metadata equivalent [EventListener(...)] in Behaviors?

This is the crux of the conversation.

[Jacob Wright]

As a flash dev, I think the idea of using a framework that requires a custom compiler would be a show-stopper for me.  Getting what I needed from a SWC in Flash Pro might be alright.  As a flex dev and FDT user, a custom SDK or monkey patches would not be a huge hurdle.  As a potential contributor to the framework, I'm not enthusiastic about anything that requires a compiler hack. I understand why you want to do it, but I agree with Grant in that it raises the barrier to entry in a significant way.

Though we've worked around the major issues of using metadata with Flash Pro by this custom compiler, I agree with David. I think we've come up with a solution that eliminates any show-stoppers for using metadata, but I feel it still is a higher barrier than going without metadata. I'll conceded with what the group decides to do, but I feel going without metadata is better than requiring a custom SDK.

That said, if we have an optional custom SDK that increases performance or does other things for us, I'll use it. My concern is for the broader adoption. Maybe most on the list are comfortable with a custom SDK, but we're also all early adopters. Will we ever be mainstream with a custom compiler?

Jac

[Jacob Wright]

Yeah.

My opinion is yes. People won't know what they're missing if they don't have metadata. The bindEventListener() method does some great wiring for them for free, much easier than wiring things up manually in code (overriding the target setter etc.). They won't know that metadata makes it even easier and more readable. Most have read documentation to learn how to use a framework. But most haven't installed a custom SDK.

But that's just my opinion.

[Andrew Westberg]

I think we still have a misunderstanding with regards to what we're planning for with the compiler.  We're NOT going to have a custom compiler.  Maybe for the first few alpha releases where it's just the uber-coders working with it, but definitely not beyond that.  

You'll specify an extra compiler option that will point to a .JAR file.  I don't see how this is really raising the bar of entry any more than someone who needs to specify a flex app background color for the compiler... -default-background-color=0x666666

And you'd have to download a .swc _and_ a .jar file, so maybe you'd be raising the bar an inch or so.  I don't see this as any more difficult than people who at one time had to specify -keep-as3-metadata to use certain frameworks.  They seemed to manage just fine.

-Andrew Westberg

[Jacob Wright]

I think we still have a misunderstanding with regards to what we're planning for with the compiler.  We're NOT going to have a custom compiler.  Maybe for the first few alpha releases where it's just the uber-coders working with it, but definitely not beyond that.  

You'll specify an extra compiler option that will point to a .JAR file.  I don't see how this is really raising the bar of entry any more than someone who needs to specify a flex app background color for the compiler... -default-background-color=0x666666

And you'd have to download a .swc _and_ a .jar file, so maybe you'd be raising the bar an inch or so.  I don't see this as any more difficult than people who at one time had to specify -keep-as3-metadata to use certain frameworks.  They seemed to manage just fine.

Well, even with a custom complier, it's just an extra download and a little dialog in the project preferences. The .jar file will be a much smaller download. You can't always please everyone, and I'm willing to try out this custom compiler and .jar approach even if I don't like it. I hope for the best.

[Paul Taylor]

> People won't know what they're missing if they don't have
> metadata. The bindEventListener() method does some great wiring for them for
> free, much easier than wiring things up manually in code (overriding the
> target setter etc.). They won't know that metadata makes it even easier and
> more readable. Most have read documentation to learn how to use a framework.

^^I agree with this statement.

I also think this unnecessarily segregates behaviors into those that
can be used by source and those which have to be used from a SWC. If I
write and release the source of a behavior (that uses metadata), Flash
Pro devs won't be able to copy and paste the code from my blog into
their project, they'll be forced to download and include another
library. Which means I'll be forced to actually compile a library.
Which is probably a pain in the ass, because I probably developed that
behavior to work for one of my projects and not because I'm writing an
awesome behavior library.

Paul

[Ben Stucki]

It does segregate behavior sharing. I think where we differ is to what extent that is more important than providing meta-data for a better workflow, and that's largely a matter of opinion. To me, the blog post might not exist without meta-data in the first place because behaviors would become much less trivial to write - but that is an opinion. I wanted to note though, that this segregation already exists for MXML which is how people may share a large number of Reflex skins, complex components, and assets. So, it will not be a new issue. The advantage here is that people have a workflow to share items at all. MXML skins shared as a swc should be usable in Flash, and Flash assets in FlashBuilder etc - just like behaviors.

--

To unsubscribe, reply using "remove me" as the subject.

[Jacob Wright]

To me, the blog post might not exist without meta-data in the first place because behaviors would become much less trivial to write

I'm guessing you're talking about my blog post(?). That was for documentation so people can know how a behavior should be built and can start contributing behaviors now while we fill out the core. Even with metadata we need documentation. The section about wiring up should now be explaining what metadata to use and how to use it instead of what methods to use. I'll try and get to that. There's also explaining about what a behavior is, how it fits into the framework, what its responsibilities are, and good practices. We need good documentation no matter how we end up coding things. I was going to write one for skins too, though it will be more about how the skinning fits in rather than concrete how-tos since we will have several skinning options and aren't settled on them yet.

We don't have everything solidified, but we can document those things that we do. I'll try and contribute to more documentation as I have the time. And we should be having something come online soon (I think, is that right Ben?) so you don't have to find docs across people's blogs.

Jac

[Ben Stucki]

Ha, oh man. I think talking on the list just confuses everything. No, I meant the theoretical blog post that a "Flex developer" might post and that a "Flash developer" would want to copy code from - in reference to this sentence from Paul:

| If I write and release the source of a behavior (that uses metadata), Flash Pro devs won't be able to copy and paste the code from my blog into their project...

I didn't mean to infer your actual blog post or anything. I agree with you 100% on documenting everything, and some official docs and a few other resources should come online soon.

- Ben

[David Knape]

>> xtyler: Does having a custom SDK raise the barrier of entry more than requiring bindEventListener(...) over the metadata equivalent ...?
> jacwright: People won't know what they're missing if they don't have metadata.

Exactly right. Flash devs don't even know about metadata (for the
most part). Metadata is a cool trick, but it really isn't my
favorite. There is something to be said for the IDE functions that
auto-complete event types and auto-generate event handlers. When
using FDT, this is a no-brainer, and meta-data actually feels clumsy
by comparison.

[David Knape]

My vote is to not use metadata in the distributable framework if that
means I can't use it in Flash. And, by that I mean I want to be able
to make use of a Behavior class without having it live in a SWC.
Provide some cool metadata tricks in Flight, and feel free to use it
in your own apps, but keep the Reflex framework clean and compiler
agnostic.

[Ben Stucki]

I think I'm going to ask that you try it before you bash it. I think we at least need to try it out, and it's going to take a little time to get it in place. I do have a few bullet points on your feedback though.

1. I totally get that some people might favor the inline code, and that's awesome. It will still exist, and you can still use it. We're not taking it away from you. Just understand that there are others with the opposite opinion and they favor meta-data quite strongly. We want them to use the framework too.

2. I'm not sure the auto-completion argument holds up that well for behaviors since the target is generically typed. Most of the wiring revolves around this, so we might not see a lot of language intelligence there. We might actually have to use HostComponent metadata for the tooling to give us better auto-completion, but it's yet to be seen. Also, I thought someone said FDT had excellent auto-complete for meta-data - maybe that was a different tool though?

3. Are you planning to checkout Reflex from version control and use it purely in Flash Pro? You've already said you prefer FDT, and we have a solution for compiling source on that.

- Ben

[Jacob Wright]

1. I totally get that some people might favor the inline code, and that's awesome. It will still exist, and you can still use it. We're not taking it away from you. Just understand that there are others with the opposite opinion and they favor meta-data quite strongly. We want them to use the framework too.

Another way of putting it, if we don't use metadata Ben will divorce us! ;)

 

2. I'm not sure the auto-completion argument holds up that well for behaviors since the target is generically typed. Most of the wiring revolves around this, so we might not see a lot of language intelligence there. We might actually have to use HostComponent metadata for the tooling to give us better auto-completion, but it's yet to be seen. Also, I thought someone said FDT had excellent auto-complete for meta-data - maybe that was a different tool though?

Autocompletion of the binding methods I think. And FDT does allow adding metadata to the preferences for auto-complete. Someday I'm sure Flash Builder will get there as well.

 

3. Are you planning to checkout Reflex from version control and use it purely in Flash Pro? You've already said you prefer FDT, and we have a solution for compiling source on that.

Um... [insert something clever and witty here]. There's also the behavior store we'll most likely put together. Store, database, repo, whatever, not the commerce definition. I'm looking forward to that. I think it will be way cool.

[David Knape]

> Another way of putting it, if we don't use metadata Ben will divorce us! ;)

Ha. Fair enough. I see why ben tried to kill this thread now.

> Also, I thought someone said FDT had excellent auto-complete for meta-data

There are custom templates (like snippets), but I haven't seen any
real FDT intelligence with meta-data.

>> 3. Are you planning to checkout Reflex from version control and use it
>> purely in Flash Pro? You've already said you prefer FDT, and we have a
>> solution for compiling source on that.

Whether or not I compile in Flash should not be a factor. That's
basically my point. But, we have another thread for this discussion
now.

-dk


--
Subscription settings: http://groups.google.com/group/reflex-platform/subscribe?hl=en

[Jacob Wright]

1. I totally get that some people might favor the inline code, and that's awesome. It will still exist, and you can still use it. We're not taking it away from you. Just understand that there are others with the opposite opinion and they favor meta-data quite strongly. We want them to use the framework too.

Another way of putting it, if we don't use metadata Ben will divorce us! ;)

Giving you a hard time here Ben, but meant in a good natured way. I was just re-reading it and wanted to be sure you knew no offense was meant. You are metadata's best advocate and young Flashers will praise your name for years to come for the legacy of readable code you have left behind.

Jac

[Ben Stucki]

No worries. That's how I took it. I laughed when I read it, but I still prefer to think of it as a "trial separation". :)

[Baz]

Please don't forget to also try counselling - it could be revealed that a suppressed metadata-related memory from childhood could be playing a part...

[Jacob Wright]

Please don't forget to also try counselling - it could be revealed that a suppressed metadata-related memory from childhood could be playing a part...

It's true. There's this one time, I had a pet and... and... sorry, it's too difficult to talk about. But anyway, it involved a mean next-door neighbor with a nasty compiler. It was awful. 

[Shaun Smith]

Apologies if this has already been brought up:

It seems that it is indeed possible to use metadata with the Flash IDE
after all (tested with CS4 and CS5, but probably works with CS3 too).
Selecting "Export SWC" in the publish settings for your document seems
to force the Flash Pro compiler to keep all metadata (for the
resulting SWF as well as the SWC). Not sure why nobody from Adobe
thought to tell us this, but it's pretty exciting.

[Tyler Wright]

Ben just shared this link with me a couple of days ago: http://www.patrickmowrer.com/2010/03/03/compiling-custom-as3-metadata-flash-professional

It sounds like you've verified metadata working in Flash, that's great! And it's so easy for devs to do, especially compared to XML configurations and such.

thanks Shaun!

[Shaun Smith]

Yup, that's the link that saved the day!