Custom Compiler Feedback

[Ben Stucki]

Hey David. This type of feedback is great. I'm starting a new thread so we can gather more.

Let me pick your brain a little bit...

| As a flash dev, I think the idea of using a framework that requires a custom compiler would be a show-stopper for me.

To be clear, you will not have to use the custom compiler to use the framework swc in Flash Pro. It will just be a normal downloadable swc like any other library. You can even create custom behaviors in Flash Pro using the binding AS3 APIs and all features will be intact. The only distinction here is that in Flash Pro meta-data will not be available, but inline code alternatives will be provided. I know this is confusing here on the list because we're hashing it all out in public, but I think with appropriate positioning and documentation it will be more approachable.

Again, the custom compiler is not required to use the swc, and all features are intact. Pure AS3 alternatives for metadata will be provided. So, is this still a deal breaker? Is it because you can't use the framework source directly in Flash Pro? What if we provided an alternate download of the source for Flash Pro users that didn't use meta-data (and could compile directly in Flash Pro)?

| As a potential contributor to the framework, I'm not enthusiastic about anything that requires a compiler hack.

I think there's no difference here in using the library vs. contributing to it. You really won't be required to build the compiler from source or anything like that to make AS3 contributions. Can you elaborate on this hesitancy a little bit? Does it just make you feel iffy about the framework in general because we're tweaking the compiler?

- Ben

---------- Forwarded message ----------
From: David Knape <tkd...@gmail.com>
Date: Wed, Apr 7, 2010 at 10:06 PM
Subject: Re: Metadata, use it or lose it?
To: reflex-...@googlegroups.com


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

On Tue, Apr 6, 2010 at 2:30 PM, Jacob Wright <jacw...@gmail.com> wrote:

| 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

[Marvin Froeder]

People, keep in mind.

REFLEX WILL ONLY support AS3 natively. Yes, only progrmatically. No metadata.

The ideia was to use a custom compiler that would convert the metadatas into AS3 code.  It is like what happen with Bindable or Embed.

Sent from DROID

[Jesse Freeman]

Why not use code gen over a custom compiler? I think that is a bad road to go down.

Sent from my iPhone

[Marvin Froeder]

Hrmmmm, and how do you plan to generate this code?  Using an independent application? 

That would be the same as using a compiler extenstion
https://bugs.adobe.com/jira/browse/SDK-26041

At least I don't see any advantage of using an independent extra application over a compiler extension.  Is quite easy to forget to run the extra app, then run the compiler and only see the problem at runtime.  Also, how you you get this extra app integrated with Flexbuilder?

I like the independent application because it allow the project to move freely.  With or without Adobe applying patches to Flex Compiler. Give you independence and freedom, I even prefer that.  But, it can be hard to get it integrated on flex environment.


VELO

[Randy Troppmann]

As a Flash dev who built applications in Flash ... moving to Flex was
sweet. Made life so much better ... if you buy into the fact that it
is not a blank slate and there is pushback to trying to make it look
un-flex-like. SWF size was and still is a big issue, however. Some
projects it matters, some it doesn't. Going the route of Pure AS3 you
lose all of the advantages of Flex. I see Reflex as going the PURE AS3
route but bringing along the databinding, mxml, (what else? layout
control?) in a lightweight pay-as-you-go fashion.

But when I think about a Flash Pro workflow, I have a hard time
understanding how Reflex fits in? Mxml? Databinding? What the heck is
a timeline doing here? I am used to the idea of library assets that
bind to a class and in some way get instantiated in a Main class (or
child thereof).

So to recap.
- Add a swc to the classpath. Great.
- Lightweight components. Great!
- Databinding. Yay!!!
- MXML ... uhh ... ok that's different.

- Randy

On Apr 8, 5:38 am, Marvin Froeder <velo...@gmail.com> wrote:
> Hrmmmm, and how do you plan to generate this code?  Using an independent
> application?
>

> That would be the same as using a compiler extenstionhttps://bugs.adobe.com/jira/browse/SDK-26041

>
> At least I don't see any advantage of using an independent extra application
> over a compiler extension.  Is quite easy to forget to run the extra app,
> then run the compiler and only see the problem at runtime.  Also, how you
> you get this extra app integrated with Flexbuilder?
>
> I like the independent application because it allow the project to move
> freely.  With or without Adobe applying patches to Flex Compiler. Give you
> independence and freedom, I even prefer that.  But, it can be hard to get it
> integrated on flex environment.
>
> VELO
>

> On Thu, Apr 8, 2010 at 8:15 AM, Jesse Freeman <jessefree...@gmail.com>wrote:
>
>
>
> > Why not use code gen over a custom compiler? I think that is a bad road to
> > go down.
>
> > Sent from my iPhone
>

> > On Apr 8, 2010, at 7:06 AM, Marvin Froeder <velo...@gmail.com> wrote:
>
> > People, keep in mind.
>
> > REFLEX WILL ONLY support AS3 natively. Yes, only progrmatically. No
> > metadata.
>
> > The ideia was to use a custom compiler that would convert the metadatas
> > into AS3 code.  It is like what happen with Bindable or Embed.
>
> > Sent from DROID
>

> > Em 08/04/2010 00:56, "Ben Stucki" < <benstu...@gmail.com>
> > benstu...@gmail.com>escreveu:

[Ben Stucki]

Not that we would have to, but I think it would be easy enough to use -keep-generated-actionscript

 with the compiler to provide Flash Pro compatible src along with the swc for Flash Pro users. This could be done pretty easily as part of the build process.

[Paul Taylor]

> - MXML ... uhh ... ok that's different.

MXML is Flex's answer to Flash's design capabilities... You get a
stage, timeline, and frames to do your business, we get declarative
markup :)
I think Reflex so far is fully compatible with Flash Pro and its
workflow.

Paul

[Jacob Wright]

> - MXML ... uhh ... ok that's different.

MXML is Flex's answer to Flash's design capabilities... You get a
stage, timeline, and frames to do your business, we get declarative
markup :)
I think Reflex so far is fully compatible with Flash Pro and its
workflow.

Right. And because everything is decoupled, it would be so sweet to just add a ScrollBehavior to a MovieClip in Flash Pro that had the pieces it needed and start using it. Or your own behaviors, which you'd have to build the non-metadata way. Also, think how sweet layout would be in Flash Pro! Anyway, point is, Reflex definitely has a home in Flash Pro. Though it could be through a SWC.

My question is, where is my custom compiler?! I want it now! ;) (sorry I haven't been helping out on it)

Jac

[Tyler Wright]

MXML is Flex's answer to Flash's design capabilities... You get a

stage, timeline, and frames to do your business, we get declarative
markup :)
I think Reflex so far is fully compatible with Flash Pro and its
workflow.

Reflex is only compatible with Flash Pro. But it isn't very useful yet on the stage and in the timeline. We have yet to explore the workflow and delivery of Reflex for Flash.

For example, should Reflex be a static set of components in the Flash components panel, allowing you to double-click in and modify the graphics like the Flash CS4 components? Or should it ship with a custom Flash panel that allows you to drop behaviors onto your timeline designs? Can you enter a mode that makes it easy to layout components inside of containers without having to double-click into each MovieClip and arrange it manually?

These are some great questions that will need to be answered eventually, before we can authoritatively declare full support for Flash IDE.

Tyler

[Randy Troppmann]

> These are some great questions that will need to be answered eventually,
> before we can authoritatively declare full support for Flash IDE.
>
> Tyler

Would a custom compiler for Flash Pro workflow enabling mxml classes
be a deal killer? I think not!

[Jacob Wright]

"You keep using that word. I do not think it means what you think it means." - guess the movie

For the record, MXML will not be supported in Flash Pro. MXML is a Flex/Flash Builder feature that is not necessary to use Reflex.

[David Knape]

> Again, the custom compiler is not required to use the swc, and all features
> are intact. Pure AS3 alternatives for metadata will be provided. So, is this
> still a deal breaker?

I understand that the 'custom compiler' is not quite as messy as it
sounds, but it still sounds messy, and that is really the biggest
barrier to entry. Not really a deal-breaker for me personally, but I
was speaking on behalf of all the flash devs I know that are still
squeamish about acronyms like SDK and MXML.

> Is it because you can't use the framework source directly in Flash Pro?
> What if we provided an alternate download of the source for Flash Pro users that didn't use
> meta-data (and could compile directly in Flash Pro)?

Yes, this would address my concerns. And, on that note, the custom
compiler extension suddenly makes a lot of sense when coupled with
--keep-generated-actionscript. That is a very good solution. Of
course, that generated AS3 is a bit messy. :) Maybe you guys can work
on that.

-dk

--
David Knape
Programmer / Consultant

On Wed, Apr 7, 2010 at 8:56 PM, Ben Stucki <bens...@gmail.com> wrote:
> Hey David. This type of feedback is great. I'm starting a new thread so we
> can gather more.
>
> Let me pick your brain a little bit...
>
> | As a flash dev, I think the idea of using a framework that requires a
> custom compiler would be a show-stopper for me.
>
> To be clear, you will not have to use the custom compiler to use the
> framework swc in Flash Pro. It will just be a normal downloadable swc like
> any other library. You can even create custom behaviors in Flash Pro using
> the binding AS3 APIs and all features will be intact. The only distinction
> here is that in Flash Pro meta-data will not be available, but inline code
> alternatives will be provided. I know this is confusing here on the list
> because we're hashing it all out in public, but I think with appropriate
> positioning and documentation it will be more approachable.
>
>
>

> | As a potential contributor to the framework, I'm not enthusiastic about
> anything that requires a compiler hack.
>
> I think there's no difference here in using the library vs. contributing to
> it. You really won't be required to build the compiler from source or
> anything like that to make AS3 contributions. Can you elaborate on this
> hesitancy a little bit? Does it just make you feel iffy about the framework
> in general because we're tweaking the compiler?

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

[Ben Stucki]

Hey David,

Sounds good. Thanks again for the feedback and representing the Flash perspective for a little bit.  I'm pretty sure most of us on the core team started as Flash developers in Flash Pro as well, so it's definitely something we're trying to keep in mind as we move ahead. Here are some more thoughts along those lines.

| speaking on behalf of all the flash devs I know that are still squeamish about acronyms like SDK and MXML.

I just wanted to mention that I don't discount this at all. We're probably going to position the downloads so that the compiler is an extra option Flex devs might want, but not something Flash devs really have to worry about. If we get a large amount of pushback after we've tried this route, I could be open to moving the master code base to not use metadata. Then the metadata compiler extensions would be very subsidiary (though I think it should still exist). As a matter of pure logic it doesn't make sense not to take advantage of the compiler for our own development, since I don't imagine many people that use only Flash Pro want to check out the master branch from git. However if it becomes a matter of perception that can't be resolved any other way we'll re-evaluate. :)

| Of course, that generated AS3 is a bit messy. :) Maybe you guys can work on that.

Yeah, keeping the generated code clean will be a high priority to make this work. We should be able to support our own custom binding and a few other items as well, so ideally all code generation will look like the AS3 alternatives people would have used anyways - and should therefore be more readable. I'm hoping for a "one line of code for one line of metadata" rule of thumb, but it's too early to know for sure.

- Ben

[David Knape]

BTW, I've been knee-deep in flex 4 the last 6 months, so it's hard to say whether or not I can truly represent all those gaia-lovin' flash devs, but I'm a huge advocate for Flex alternatives that make use of MXML and the flex compiler.  Maybe we should start the flag waving now and get flash devs to dump their flash compiler.  I'll do what I can.

-dk

--
David Knape
Programmer / Consultant