date:20130127

On Fri, Jan 25, 2013 at 11:56 PM, Alain Ekambi jazzmatad...@gmail.comwrote:

 @Roland
 For the SDK it s surely not a problem since it s all Apache.
 But anyone using the Apache Flex SDK to write an  ExtJS application will
 need a commercial license from Sencha or will have to open source the code.

 This is worth mentioning.
 (I wrote an SDK around EXTJS, so i know for sure)


Yes, Alain, I can second that.
So it is not the perfect choice for every project, but since Flex targets
enterprise software, I think it is still a valid choice.

-Frank-

Re: [ASJS] Integration with existing JS libraries and components

 Please take a look at the proof of concept (both the intermediate and
 release code) before making these kinds of statements.

 I'd like to, but you admitted yourself that it has quite an initial
 overhead to set up. Could you perhaps set up an online demo where one can
 observe a running system? Or a download of the compiled application? At
 least that's what I did for the AMD approach:

Excellent idea. Here is the full Flash version (+ view source) and
both the 'intermediate' and 'release' output of the proof of concept:

http://people.apache.org/~erikdebruin/vanillasdk/

A bit of view source will show you why I've been saying what I've been
saying. The 'getting started' page for the Closure Tools, as its name
implies, only covers the basics. There is, however, a bit more to the
story, as you can see ;-)

I'm looking forward to seeing the Falcon implementation of your
AMD/RequireJS ideas and it's output, so we can compare the various
suggested approaches on their technical merits as well as their
theoretical underpinnings.

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [ASJS] Integration with existing JS libraries and components


Is Example.js a generated cross compile?

Mike

Quoting Erik de Bruin e...@ixsoftware.nl:


Please take a look at the proof of concept (both the intermediate and
release code) before making these kinds of statements.

I'd like to, but you admitted yourself that it has quite an initial

overhead to set up. Could you perhaps set up an online demo where one can
observe a running system? Or a download of the compiled application? At
least that's what I did for the AMD approach:


Excellent idea. Here is the full Flash version (+ view source) and
both the 'intermediate' and 'release' output of the proof of concept:

http://people.apache.org/~erikdebruin/vanillasdk/

A bit of view source will show you why I've been saying what I've been
saying. The 'getting started' page for the Closure Tools, as its name
implies, only covers the basics. There is, however, a bit more to the
story, as you can see ;-)

I'm looking forward to seeing the Falcon implementation of your
AMD/RequireJS ideas and it's output, so we can compare the various
suggested approaches on their technical merits as well as their
theoretical underpinnings.

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl



--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [ASJS] Integration with existing JS libraries and components

On Sun, Jan 27, 2013 at 1:03 PM, Erik de Bruin e...@ixsoftware.nl wrote:

  Please take a look at the proof of concept (both the intermediate and
  release code) before making these kinds of statements.
 
  I'd like to, but you admitted yourself that it has quite an initial
  overhead to set up. Could you perhaps set up an online demo where one can
  observe a running system? Or a download of the compiled application? At
  least that's what I did for the AMD approach:

 Excellent idea. Here is the full Flash version (+ view source) and
 both the 'intermediate' and 'release' output of the proof of concept:

 http://people.apache.org/~erikdebruin/vanillasdk/

 A bit of view source will show you why I've been saying what I've been
 saying. The 'getting started' page for the Closure Tools, as its name
 implies, only covers the basics. There is, however, a bit more to the
 story, as you can see ;-)


Thank you Erik, for providing a running version so quickly. That really
helps!
I think I can now pinpoint the difference to RequireJS: It is in the
existence of deps.js.
deps.js says it's generated, and seems to be the extracted dependencies of
all the other JS files, right? Aha, so this is how the necessary scripts
get loaded in advance. And this is where you need the build tool: To
extract the dependencies and generate this additional file deps.js.
RequireJS has a similar mechanism, called shims. You can shim any
JavaScript library that was not made for AMD by specifying dependencies in
an additional configuration file. See
http://requirejs.org/docs/api.html#config-shim But for modules written in
the AMD style, a deps file is not necessary.
What I criticize is that dependencies have to be specified twice. Granted,
the second occurrence is generated by a tool, but that means you have to
use the tool. It just makes things more complicated and more dependent. Why
should this be necessary, when there is another solution that works without
this redundancy and build step?
Especially in development mode, when I change a single AS source file, it
would be great if it would suffice to re-generate only the corresponding JS
file. But when you add a dependency to your AS code, deps.js would have to
re-generated, too, and as it looks quite monolithic, this operation might
be expensive.
With the AMD approach, you can re-generate exactly one file and reload in
the browser, and everything will work.
I know that for some Flex folks, development turn-around to the browser is
not such an important issue, as they see the JS output more like an
alternative deployment format, so they'll test in Flash or AIR and only
deploy and QA in HTML5. I see a different scenario, where Flex is used to
develop primarily for HTML5, which makes fast development turn-around to
the browser a necessity.

One more thing, something I didn't find out is how deps.js gets loaded. It
has to be triggered by base.js somehow. Can you please explain?



 I'm looking forward to seeing the Falcon implementation of your
 AMD/RequireJS ideas and it's output, so we can compare the various
 suggested approaches on their technical merits as well as their
 theoretical underpinnings.


Okay, we can wait for that, but since Michael says what I did with Jangaroo
3 is easily re-implemented in Falcon, why not compare now? The output
will/should be very very similar to what the Jangaroo 3 output looks like
now, e.g. the one of the Open Flash Chart example.
Another idea would be I take your example code (or any other code you want)
and compile it with Jangaroo 3 and also deploy the output. What do you
think?

Greetings
-Frank-

[Falcon][Discuss] Modularity, extensibility and configurability of the Falcon compiler framework

2013-01-27 Thread Roland Zwaga

Good day to all of you :)

Hold on, I think this is going to be a long message...

Moving on from the latest discussion between Erik and Frank about the ideal
implementation of AS-JS cross-compilation,
I think its perhaps an interesting venture to talk a little bit about some
possible changes we could make to Falcon itself.

Let me preface this with giving my opinion about both Erik's and Frank's
proposed solution. I believe both gentlemen know
their business and are passionate about their respective solution. I'm not
going to abuse this thread by choosing sides.

I also believe the discussion actually shouldn't have to take place. I
believe there should be place for both solutions so that
potential users of Apache Flex can choose the output that best fits their
project.

For instance, Frank's solution might be interesting for folks who don't
want to go through the process of installing Closure, or
who simply don't like Closure (for whatever reason, valid or not). Whereas
Erik's implementation might even make sense in
a larger project where multiple parties are adding Javascript to a shared
codebase, but all of them use different technologies
to generate that Javascript. If all of them make sure that the JS they
provide is in the form that Closure expects it, all of their output
could be part of a larger build system that involves Closure at the end of
the line. (Just thinking out loud here)

So therefore I believe that both avenues need to be explored and quite
probably both avenues ought to find their place in a future
release of Apache Flex.

Right, using this introduction I'd like to start some sort of discussion
about the design of Falcon at the moment. (And what I understand
of it at the moment, so Michael, Alex, Gordon, if I start talking out of m
y a**, please correct me).

Currently there seem to be three compilers: MXMLC, COMPC and ASC. All three
(and now a fourth called 'ASJS' I guess) are a kind
of monolithic class that creates all of its dependencies internally. So, if
we want to compile mxml/as we invoke MXMLC and if we
want to compile pure as3 we invoke ASC, etc. Come to think of it, there's
even a fifth one, if we count Michael Schmalle's ASDoc
compiler implementation.

I think it might make more sense to create a single point of entry for all
types of compilation. Let's call this point of entry FLEXC (credit:
 Michael Schmalle). Wouldn't it be cleaner to use this FLEXC compiler as a
sort of factory for all the different types of compilers that
make up the Falcon framework? FLEXC could use an XML configuration file
that describes the various compilers and could create
a fully configured instance. (Essentially FLEXC would be a specialised DI
container for Falcon compilers).

The XML configuration for FLEXC could look like this (very simplified):

falcon default-target=swf
default-frontend=AS3Frontend-Plugin-Identifier
  target name=swf backend=SWFBackend-Plugin-Identifier/
  target name=js backend=JSBackend-Plugin-Identifier/
  target name=asdoc backend=ASDocBackend-Plugin-Identifier/
/falcon

This way FLEXC could invoked with a *-swf* parameter so that FLEXC knows it
has to return an instance of the swf target. All parameters
coming *after* the *-swf* param would be ignored by FLEXC and instead
passed on to the instance that it created.

This way the frontends and/or backends could receive additional
configuration:

falcon
default-target=swf  default-frontend=AS3Frontend-Plugin-Identifier
  plugin  id=AOP-AST-PostProcessor uri=PATH_TO_JAR_FILE
type=ast-postprocesser/
  plugin  id=Guice-AST-PostProcessor uri=PATH_TO_JAR_FILE
type=ast-postprocesser/
  plugin  id=Randori-Emit-PostProcessor uri=PATH_TO_JAR_FILE
type=emit-postprocesser/

  frontend id=AS3Frontend-Plugin-Identifier uri=PATH_TO_JAR_FILE
plugin id=AOPASTPostProcessor/
  /frontend

  backend id=SWFBackend-Plugin-Identifier uri=PATH_TO_JAR_FILE/
  backend id=JSBackend-Plugin-Identifier uri=PATH_TO_JAR_FILE
plugin id=Randori-Emit-PostProcessor
  /backend

  target name=swf backend=SWFBackend-Plugin-Identifier/
  target name=js backend=JSBackend-Plugin-Identifier/
  target name=asdoc backend=ASDocBackend-Plugin-Identifier/
/falcon

Obviously the configuration doesn't HAVE to be XML, I'm just using it as an
example.

So, by way of the configurability/modularity of Falcon and the examples
above, I come to the notion of extensibility.
Currently there is no plugin architecture in place in the Falcon framework
(at least, not that I'm aware, please correct me if I'm wrong).

Now, IMHO, things would become extremely interesting if we do identify a
number of hooks into the compiler process where a potential
plugin could add or manipulate functionality. In the best case, I even
believe that ALL functionality should basically be viewed as pluggable.
As the configuration example shows, in theory it ought to be possible to
override the entire frontend and plug your own custom AS3 parser.
(Not a lot of folks would choose to do so, but in

Re: [ASJS] Integration with existing JS libraries and components



Quoting Frank Wienberg fr...@jangaroo.net:






I'm looking forward to seeing the Falcon implementation of your
AMD/RequireJS ideas and it's output, so we can compare the various
suggested approaches on their technical merits as well as their
theoretical underpinnings.



Okay, we can wait for that, but since Michael says what I did with Jangaroo
3 is easily re-implemented in Falcon, why not compare now? The output
will/should be very very similar to what the Jangaroo 3 output looks like
now, e.g. the one of the Open Flash Chart example.
Another idea would be I take your example code (or any other code you want)
and compile it with Jangaroo 3 and also deploy the output. What do you
think?

Greetings
-Frank-



I am pretty sure he means, When Mike implements this in FalconJx, we  
con compare ;-)


BTW, just getting over the flu. This is on my list, believe me, so we  
can stop wasting time with these huge emails back and forth and just  
compare and performance test. :)


MXML is going to wait, I did a bit bit, put some hooks in but there is  
more pressing things I want to spend my time on, this is one and the  
other is what Roland just announced for discussion with the compiler.


Mike

--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [Falcon][Discuss] Modularity, extensibility and configurability of the Falcon compiler framework


+1 on this.

FYI, As the Apache way suggests, itch your scratch... This one is  
going to happen and I will be working on it with Roland. We are  
looking for constructive criticism, not a blessing. :)


I already have 2 compilers to work with and it's ridiculous one parse  
session can't be used for multiple targets, I think in a nut shell  
this is what Roland is getting at here.


Yes, FLEXC rhymes with sexy. ;-) And this compiler frontend-backend  
will be sexy for sure.


In the spirit of understanding, with a prototype we are going to  
develop it in a non intrusive way to the existing compilers. There is  
no plan to go hacking into the existing code if we don't have to at  
this point, plus that would be completely stupid IMHO.


I think the proof of concept will use the FlaconJx and ASDoc compilers  
to prove our configuration concept, which verifies we will not touch  
the existing MXMLC or COMPC code for now.


Mike


Quoting Roland Zwaga rol...@stackandheap.com:


Good day to all of you :)

Hold on, I think this is going to be a long message...

Moving on from the latest discussion between Erik and Frank about the ideal
implementation of AS-JS cross-compilation,
I think its perhaps an interesting venture to talk a little bit about some
possible changes we could make to Falcon itself.

Let me preface this with giving my opinion about both Erik's and Frank's
proposed solution. I believe both gentlemen know
their business and are passionate about their respective solution. I'm not
going to abuse this thread by choosing sides.

I also believe the discussion actually shouldn't have to take place. I
believe there should be place for both solutions so that
potential users of Apache Flex can choose the output that best fits their
project.

For instance, Frank's solution might be interesting for folks who don't
want to go through the process of installing Closure, or
who simply don't like Closure (for whatever reason, valid or not). Whereas
Erik's implementation might even make sense in
a larger project where multiple parties are adding Javascript to a shared
codebase, but all of them use different technologies
to generate that Javascript. If all of them make sure that the JS they
provide is in the form that Closure expects it, all of their output
could be part of a larger build system that involves Closure at the end of
the line. (Just thinking out loud here)

So therefore I believe that both avenues need to be explored and quite
probably both avenues ought to find their place in a future
release of Apache Flex.

Right, using this introduction I'd like to start some sort of discussion
about the design of Falcon at the moment. (And what I understand
of it at the moment, so Michael, Alex, Gordon, if I start talking out of m
y a**, please correct me).

Currently there seem to be three compilers: MXMLC, COMPC and ASC. All three
(and now a fourth called 'ASJS' I guess) are a kind
of monolithic class that creates all of its dependencies internally. So, if
we want to compile mxml/as we invoke MXMLC and if we
want to compile pure as3 we invoke ASC, etc. Come to think of it, there's
even a fifth one, if we count Michael Schmalle's ASDoc
compiler implementation.

I think it might make more sense to create a single point of entry for all
types of compilation. Let's call this point of entry FLEXC (credit:
 Michael Schmalle). Wouldn't it be cleaner to use this FLEXC compiler as a
sort of factory for all the different types of compilers that
make up the Falcon framework? FLEXC could use an XML configuration file
that describes the various compilers and could create
a fully configured instance. (Essentially FLEXC would be a specialised DI
container for Falcon compilers).

The XML configuration for FLEXC could look like this (very simplified):

falcon default-target=swf
default-frontend=AS3Frontend-Plugin-Identifier
  target name=swf backend=SWFBackend-Plugin-Identifier/
  target name=js backend=JSBackend-Plugin-Identifier/
  target name=asdoc backend=ASDocBackend-Plugin-Identifier/
/falcon

This way FLEXC could invoked with a *-swf* parameter so that FLEXC knows it
has to return an instance of the swf target. All parameters
coming *after* the *-swf* param would be ignored by FLEXC and instead
passed on to the instance that it created.

This way the frontends and/or backends could receive additional
configuration:

falcon
default-target=swf  default-frontend=AS3Frontend-Plugin-Identifier
  plugin  id=AOP-AST-PostProcessor uri=PATH_TO_JAR_FILE
type=ast-postprocesser/
  plugin  id=Guice-AST-PostProcessor uri=PATH_TO_JAR_FILE
type=ast-postprocesser/
  plugin  id=Randori-Emit-PostProcessor uri=PATH_TO_JAR_FILE
type=emit-postprocesser/

  frontend id=AS3Frontend-Plugin-Identifier uri=PATH_TO_JAR_FILE
plugin id=AOPASTPostProcessor/
  /frontend

  backend id=SWFBackend-Plugin-Identifier uri=PATH_TO_JAR_FILE/
  backend id=JSBackend-Plugin-Identifier uri=PATH_TO_JAR_FILE
plugin id=Randori-Emit-PostProcessor

Re: [ASJS] Integration with existing JS libraries and components

On Sun, Jan 27, 2013 at 2:51 PM, Michael Schmalle
apa...@teotigraphix.comwrote:


 Quoting Frank Wienberg fr...@jangaroo.net:




 I'm looking forward to seeing the Falcon implementation of your
 AMD/RequireJS ideas and it's output, so we can compare the various
 suggested approaches on their technical merits as well as their
 theoretical underpinnings.


  Okay, we can wait for that, but since Michael says what I did with
 Jangaroo
 3 is easily re-implemented in Falcon, why not compare now? The output
 will/should be very very similar to what the Jangaroo 3 output looks like
 now, e.g. the one of the Open Flash Chart example.
 Another idea would be I take your example code (or any other code you
 want)
 and compile it with Jangaroo 3 and also deploy the output. What do you
 think?

 Greetings
 -Frank-


 I am pretty sure he means, When Mike implements this in FalconJx, we con
 compare ;-)


Sorry if I missed a joke, but I was saying the opposite, why not compare
now? Why does it have to be implemented in FalconJx when we discuss/compare
the output format, not the compile process?


 MXML is going to wait, I did a bit bit, put some hooks in but there is
 more pressing things I want to spend my time on, this is one and the other
 is what Roland just announced for discussion with the compiler.


So do we really only compare the approaches by the resulting performance?
That would be sad.
There are many other factors:
* Code size
* Modularity (= do you have to re-compile class B if class A changed?)
* Development turn-around effort
* Complexity of solution
* ...

These should all be regarded before a final decision for one or the other.

Greetings
-Frank-

Re: [ASJS] Integration with existing JS libraries and components


Frank,

Definitely a cultural difference here with my writing below.

Basically, the point was, you CAN compare right now but, I think Erik  
was or just missed that fact you CAN compare right now.


As far as your comments about how things should be compared, my point  
was, start comparing! :) Enough of the emails, like you said, you have  
the two outputs, go to town.


Again, I guess I should have just kept my mouth shut here as I have  
previously stated, I will never have an opinion about this stuff,  
since I will never know enough to give an opinion. :)


Frank, a lot of what I said below was from a more sarcastic, lets just  
get the ball rolling point of view.


Mike


Quoting Frank Wienberg fr...@jangaroo.net:


On Sun, Jan 27, 2013 at 2:51 PM, Michael Schmalle
apa...@teotigraphix.comwrote:



Quoting Frank Wienberg fr...@jangaroo.net:






I'm looking forward to seeing the Falcon implementation of your
AMD/RequireJS ideas and it's output, so we can compare the various
suggested approaches on their technical merits as well as their
theoretical underpinnings.


 Okay, we can wait for that, but since Michael says what I did with

Jangaroo
3 is easily re-implemented in Falcon, why not compare now? The output
will/should be very very similar to what the Jangaroo 3 output looks like
now, e.g. the one of the Open Flash Chart example.
Another idea would be I take your example code (or any other code you
want)
and compile it with Jangaroo 3 and also deploy the output. What do you
think?

Greetings
-Frank-



I am pretty sure he means, When Mike implements this in FalconJx, we con
compare ;-)



Sorry if I missed a joke, but I was saying the opposite, why not compare
now? Why does it have to be implemented in FalconJx when we discuss/compare
the output format, not the compile process?



MXML is going to wait, I did a bit bit, put some hooks in but there is
more pressing things I want to spend my time on, this is one and the other
is what Roland just announced for discussion with the compiler.



So do we really only compare the approaches by the resulting performance?
That would be sad.
There are many other factors:
* Code size
* Modularity (= do you have to re-compile class B if class A changed?)
* Development turn-around effort
* Complexity of solution
* ...

These should all be regarded before a final decision for one or the other.

Greetings
-Frank-



--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [ASJS] Integration with existing JS libraries and components

That being said, I think both Erik and I got the ball rolling. It is not
as if we are just talking theory here. We both have a working demo
everybody can look at, and have both posted our arguments. Maybe we should
just start a new thread to get this to a decision.
But I don't want to force a decision right now; if you (Mike) are still
willing to implement the AMD approach in FalconJx, we can just continue in
parallel and see where it leads to. I have continued on the Wiki page,
renamed it and started with the compilation unit concept, which is
probably the other big difference between Erik's approach and mine:
https://cwiki.apache.org/confluence/display/FLEX/Simulating+AS3+language+features+in+JavaScript+using+AMD+and+ES5
The still empty headlines are all for minor topics which we can tackle
later. So from my side, you could start as soon as the flu's gone and MXML
is done... ;-)
Greetings
-Frank-

Re: [ASJS] Update

2013-01-27 Thread Alex Harui

Did you end up with a set of scripts as described in [1]?

https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Status

You will need to have the frameworks/js folder available to the html file,
as well as the goog and third_party folders from the google libraries. The
compiler does not generate these .js files, these are the parallel framework
files we have to code along with the as files.

-Alex

On 1/27/13 12:11 AM, Om bigosma...@gmail.com wrote:

 On Sat, Jan 26, 2013 at 11:51 PM, Alex Harui aha...@adobe.com wrote:
 
 
 
 
 On 1/26/13 11:22 PM, Om bigosma...@gmail.com wrote:
 
 !ClosureProblem!
 
 !ClosureProblem!
 
 !ClosureProblem!
 
 !ClosureProblem!
 
 !ClosureProblem!
 
 ==
 
 I do see the following .js files in the directory though:
 
 MyController.js
 MyInitialView.js
 MyModel.js
 MySimpleValuesImpl.js
 
 Thanks,
 Om
 OK, hopefully you can make progress.
 
 
 I managed to craft the html with the correct paths to the js files.  On
 running the html file, firebug shows these errors:
 Mostly because of the missing .js files.  I am guessing the
 !ClosureProblem! prevented these .js files from being created.
 
 goog.require could not find: org.apache.flex.binding.SimpleBinding
 require()base.js (line 349)
 name =
 
 org.apache.flex.binding.SimpleBinding
 
 MyInitialView.js()MyInitialView.js (line 3)
 
 goog.global.console['error'](errorMessage);
 
 base.js (line 349)
 
 goog.require could not find: flash.events.Event
 require()base.js (line 349)
 name =
 
 flash.events.Event
 
 MyController.js()MyController.js (line 3)
 
 goog.global.console['error'](errorMessage);
 
 base.js (line 349)
 
 goog.require could not find: org.apache.flex.core.SimpleValuesImpl
 require()base.js (line 349)
 name =
 
 org.apache.flex.core.SimpleValuesImpl
 
 MySimpleValuesImpl.js()MySimp...Impl.js (line 3)
 
 goog.global.console['error'](errorMessage);
 
 base.js (line 349)
 
 goog.require could not find: flash.events.Event
 require()base.js (line 349)
 name =
 
 flash.events.Event
 
 MyModel.js()MyModel.js (line 3)
 
 goog.global.console['error'](errorMessage);
 
 base.js (line 349)
 
 goog.require could not find: org.apache.flex.core.Application
 require()base.js (line 349)
 name =
 
 org.apache.flex.core.Application
 
 FlexJSTest.js()FlexJSTest.js (line 7)
 
 goog.global.console['error'](errorMessage);
 
 base.js (line 349)
 
 Error: goog.require could not find: org.apache.flex.binding.SimpleBinding
 [Break On This Error]
 
 var app = new FlexJSTest();
 
 FlexJSTest.html (line 28)
 
 Error: goog.require could not find: flash.events.Event
 [Break On This Error]
 
 throw Error(errorMessage);
 
 base.js (line 353)
 
 Error: goog.require could not find: org.apache.flex.core.SimpleValuesImpl
 [Break On This Error]
 
 throw Error(errorMessage);
 
 base.js (line 353)
 
 Error: goog.require could not find: flash.events.Event
 [Break On This Error]
 
 throw Error(errorMessage);
 
 base.js (line 353)
 
 Error: goog.require could not find: org.apache.flex.core.Application
 [Break On This Error]
 
 throw Error(errorMessage);
 
 base.js (line 353)
 
 TypeError: FlexJSTest is not a constructor
 [Break On This Error]
 
 var app = new FlexJSTest();
 
 FlexJSTest.html (line 28)
 
 TypeError: app is undefined
 [Break On This Error]
 
 app.start()

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [ASJS] Integration with existing JS libraries and components

Yes, the one in 'intermediate' is. The one in 'release' is the
'intermediate' version, but run through the Closure Compiler.

EdB



On Sun, Jan 27, 2013 at 1:48 PM, Michael Schmalle
apa...@teotigraphix.com wrote:
 Is Example.js a generated cross compile?

 Mike


 Quoting Erik de Bruin e...@ixsoftware.nl:

 Please take a look at the proof of concept (both the intermediate and
 release code) before making these kinds of statements.

 I'd like to, but you admitted yourself that it has quite an initial

 overhead to set up. Could you perhaps set up an online demo where one can
 observe a running system? Or a download of the compiled application? At
 least that's what I did for the AMD approach:


 Excellent idea. Here is the full Flash version (+ view source) and
 both the 'intermediate' and 'release' output of the proof of concept:

 http://people.apache.org/~erikdebruin/vanillasdk/

 A bit of view source will show you why I've been saying what I've been
 saying. The 'getting started' page for the Closure Tools, as its name
 implies, only covers the basics. There is, however, a bit more to the
 story, as you can see ;-)

 I'm looking forward to seeing the Falcon implementation of your
 AMD/RequireJS ideas and it's output, so we can compare the various
 suggested approaches on their technical merits as well as their
 theoretical underpinnings.

 EdB



 --
 Ix Multimedia Software

 Jan Luykenstraat 27
 3521 VB Utrecht

 T. 06-51952295
 I. www.ixsoftware.nl


 --
 Michael Schmalle - Teoti Graphix, LLC
 http://www.teotigraphix.com
 http://blog.teotigraphix.com




-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [ASJS] Integration with existing JS libraries and components

 I think I can now pinpoint the difference to RequireJS: It is in the
 existence of deps.js.
 deps.js says it's generated, and seems to be the extracted dependencies of
 all the other JS files, right? Aha, so this is how the necessary scripts
 get loaded in advance. And this is where you need the build tool: To
 extract the dependencies and generate this additional file deps.js.

No, the deps.js is just a list of ALL the require statements in the
entire library + application (indeed generate during the publish
process. However, ONLY the files listed that are ACTUALLY USED are
loaded dynamically by the code in 'base.js'. If you look in either
Chrome or FF you can see which script files are actually loaded and
compare that list agains the 'deps.js' list. You'll see that the only
file hard-coded into the HTML is 'base.js', which is the equivalent of
'require.js' in your approach. All the other script files are loaded
dynamically, in order, based on the dependencies as given in their
contents, much like with Require.js.

 With the AMD approach, you can re-generate exactly one file and reload in
 the browser, and everything will work.

Same with the 'goog' way.

 One more thing, something I didn't find out is how deps.js gets loaded. It
 has to be triggered by base.js somehow. Can you please explain?

It's a kind of magic :-) As I explain above, 'base.js' uses it,
together with the 'provide' and 'require' statements to figure out
which other project files to load. Let me press that point, since it
seems to be pivotal to the discussion: ONLY the files that are
ACTUALLY needed to run the application are loaded into the browser.
NOT all the files in 'deps.js' and certainly not all the files in the
Closure Library.

 Okay, we can wait for that, but since Michael says what I did with Jangaroo
 3 is easily re-implemented in Falcon, why not compare now? The output
 will/should be very very similar to what the Jangaroo 3 output looks like
 now, e.g. the one of the Open Flash Chart example.
 Another idea would be I take your example code (or any other code you want)
 and compile it with Jangaroo 3 and also deploy the output. What do you
 think?

I enabled View Source on the Flash output, so you can grab the AS
source and put it through Jangaroo if you please. You can also pick up
Alex's FlexJS source and do the same with that.Might be interesting to
see what comes out and compare the various approaches when using a
different compiler.

I think you're not going to convince me to throw away all the work I
did so far (and I strongly believe is at least as valid for our
purpose as what you are suggesting) and start the whole process again
based on your approach, only to do away with one step in the build
process of the intermediate output (the 'deps.js' you object to plays
no role in generating the 'release' code). I'll continue development
of my proof of concept and I hope to find other contributors willing
to help out.

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [ASJS] Integration with existing JS libraries and components

2013-01-27 Thread Omar Gonzalez

Well the PMC would not veto commits.

It would veto the notion o including something in the SDK that wasn't
agreed upon via consensus.

Just to be clear. :)

-omar

On Sunday, January 27, 2013, Erik de Bruin wrote:

  But I don't want to force a decision right now;

 The beauty of the Apache Way is that you are free to do whatever you
 feel is best for the project. As am I. So, short of the PMC voting and
 veto-ing each and every commit made to the code we contribute, there
 is no way you or anyone else can force a decision, now or ever.

 EdB



 --
 Ix Multimedia Software

 Jan Luykenstraat 27
 3521 VB Utrecht

 T. 06-51952295
 I. www.ixsoftware.nl

Re: [Falcon][Discuss] Modularity, extensibility and configurability of the Falcon compiler framework

Roland,

Me likey.

Some comments and suggestions inline:

 I think it might make more sense to create a single point of entry for all
 types of compilation. Let's call this point of entry FLEXC (credit:
  Michael Schmalle). Wouldn't it be cleaner to use this FLEXC compiler as a
 sort of factory for all the different types of compilers that
 make up the Falcon framework? FLEXC could use an XML configuration file
 that describes the various compilers and could create
 a fully configured instance. (Essentially FLEXC would be a specialised DI
 container for Falcon compilers).

Big +1 here.

 So, by way of the configurability/modularity of Falcon and the examples
 above, I come to the notion of extensibility.
 Currently there is no plugin architecture in place in the Falcon framework
 (at least, not that I'm aware, please correct me if I'm wrong).
 ...
 Coming back to the case of Erik's and Frank's proposal of Javascript
 emission. If the Falcon backends will be designed (and I believe Michael
 Schmalle has already done so in his ASJS implementation) then we don't need
 to fight over which implementation Apache Flex should officially
 choose. Folks can build both and offer them to the Apache Flex community as
 a configurable option.
 ...
 for a specific backend could be defined. (Because, if I recall correctly,
 currently Erik's and Frank's solutions are basically different
 implementations of
 an emitter, right?)

This is pretty much how Mike set it up. The code for the emitters is
really nicely compartmentalized and you can easily switch out the
backend for another. After Mike helped me set up the Goog emitters and
I got how it worked,  it was really easy for me to start an
AMD/RequireJS version, to help out Frank with his contribution. It's
not quite abstracted to the level of a plugin structure, and it's
beyond me to create that (I only started doing Java to help out Mike
and implement Goog), but it certainly should be possible, IMHO.

 I'd love to hear some opinions, so let the games begin :)

In my opinion you've hit the nail on the head. Now all we need to do
is to take it from theory to implementation, after we get all the
compiler factions on the same page... Good luck ;-)

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [ASJS] Integration with existing JS libraries and components

 Take a chill pill. ;)

Really? Nice!

I prefer contributing over chillin, thank you.

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

[jira] [Commented] (FLEX-33366) The candidate input method can not follow

2013-01-27 Thread zy (JIRA)

[
https://issues.apache.org/jira/browse/FLEX-33366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563863#comment-13563863
]

zy commented on FLEX-33366:
---

Thank you for your help.I do a test on another win7 use IE9。It is also this
problem.
I cut the two pictures：
spark is bad:http://img.my.csdn.net/uploads/201301/28/1359309823_2536.jpg
mx is good:http://img.my.csdn.net/uploads/201301/28/1359309824_3582.jpg

It is really affect user experience for chinese people.

I use TLF,so I must use spark.

I placed in the same position for a hidden mx to slove this problem.But I think
it is Stupid and not elegant.
if can repair in 5.0.I can not use any mx component.Swf can not include mx.swc.
I think it should affect SWF size that much

The candidate input method can not follow
-

Key: FLEX-33366
URL: https://issues.apache.org/jira/browse/FLEX-33366
Project: Apache Flex
Issue Type: Bug
Components: Spark: TextArea, Spark: TextInput
Affects Versions: Apache Flex 4.8 (parity release)
Environment: windows,IE8
Reporter: zy

The spark:TextArea and TextInput Chinese candidate input method can not
follow.
But mx:TextArea and TextInput not this issue.
I guess you only test the English input method, Chinese input methods all
have this problem, it is affecting the user experience.
you can test this Chinese input method.all chinese use this.
http://dl_dir.qq.com/invc/qqpinyin/QQPinyin_Setup_1.1.1224.400.exe
I made a picture to illustrate the problem.
http://img.my.csdn.net/uploads/201301/24/1359028348_2400.jpg
If you are unclear, please let me know. I don't know english.I am very sorry.
Thank you!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [ASJS] Integration with existing JS libraries and components

2013-01-27 Thread Omar Gonzalez

Really.


On Sun, Jan 27, 2013 at 10:11 AM, Erik de Bruin e...@ixsoftware.nl wrote:

  Take a chill pill. ;)

 Really? Nice!

 I prefer contributing over chillin, thank you.

 EdB



 --
 Ix Multimedia Software

 Jan Luykenstraat 27
 3521 VB Utrecht

 T. 06-51952295
 I. www.ixsoftware.nl

Re: [ASJS] Integration with existing JS libraries and components

On Sun, Jan 27, 2013 at 5:52 PM, Erik de Bruin e...@ixsoftware.nl wrote:

  I think I can now pinpoint the difference to RequireJS: It is in the
  existence of deps.js.
  deps.js says it's generated, and seems to be the extracted dependencies
 of
  all the other JS files, right? Aha, so this is how the necessary scripts
  get loaded in advance. And this is where you need the build tool: To
  extract the dependencies and generate this additional file deps.js.

 No, the deps.js is just a list of ALL the require statements in the
 entire library + application (indeed generate during the publish
 process. However, ONLY the files listed that are ACTUALLY USED are
 loaded dynamically by the code in 'base.js'. If you look in either
 Chrome or FF you can see which script files are actually loaded and
 compare that list agains the 'deps.js' list. You'll see that the only
 file hard-coded into the HTML is 'base.js', which is the equivalent of
 'require.js' in your approach. All the other script files are loaded
 dynamically, in order, based on the dependencies as given in their
 contents, much like with Require.js.

  With the AMD approach, you can re-generate exactly one file and reload in
  the browser, and everything will work.

 Same with the 'goog' way.


  One more thing, something I didn't find out is how deps.js gets loaded.
 It
  has to be triggered by base.js somehow. Can you please explain?

 It's a kind of magic :-) As I explain above, 'base.js' uses it,
 together with the 'provide' and 'require' statements to figure out
 which other project files to load. Let me press that point, since it
 seems to be pivotal to the discussion: ONLY the files that are
 ACTUALLY needed to run the application are loaded into the browser.
 NOT all the files in 'deps.js' and certainly not all the files in the
 Closure Library.


To get one misunderstanding out of the way, I never claimed base.js would
load more scripts than required.
I just wonder all the time how base.js can know *in advance* which scripts
to load. And deps.js seems to be the answer to that question.
Believe me, I'm just trying to understand how it works and where it is
substantially different from RequireJS.
So deps.js is not only the list of all require statements starting at the
main class, but as you say a list of ALL the require statements in the
entire library + application. My example was that you change a single
file, but change it in a way that you add a dependency. Without
re-generating deps.js, base.js could not know in advance that the newly
dependent module is needed, so just generating the class' own output file
would result in a non-working state. And (re-)generating deps.js is exactly
the pre-processing step AMD so elegantly avoids from the start.


  Okay, we can wait for that, but since Michael says what I did with
 Jangaroo
  3 is easily re-implemented in Falcon, why not compare now? The output
  will/should be very very similar to what the Jangaroo 3 output looks like
  now, e.g. the one of the Open Flash Chart example.
  Another idea would be I take your example code (or any other code you
 want)
  and compile it with Jangaroo 3 and also deploy the output. What do you
  think?

 I enabled View Source on the Flash output, so you can grab the AS
 source and put it through Jangaroo if you please. You can also pick up
 Alex's FlexJS source and do the same with that.Might be interesting to
 see what comes out and compare the various approaches when using a
 different compiler.


Yes, I'll try to do that, but except from the deps.js file discussed above
I expect the difference to be rather small.


 I think you're not going to convince me to throw away all the work I
 did so far (and I strongly believe is at least as valid for our
 purpose as what you are suggesting) and start the whole process again
 based on your approach, only to do away with one step in the build
 process of the intermediate output (the 'deps.js' you object to plays
 no role in generating the 'release' code). I'll continue development
 of my proof of concept and I hope to find other contributors willing
 to help out.


Nobody asks you to throw away your work. We are discussing which library /
tool better supports the JS target of Apache Flex. From a code-generation
point of view, our approaches are fairly similar, and there are suggestions
(see Roland's thread) that it should be easy to switch between such similar
code output patterns. So we'll probably have both of them.
However, I still think it is better to consolidate than to offer too much
to chose from (where it brings no benefit). And I'd still like to hear your
opinion on my warning that the input language for GCC is a dialect of
JavaScript (restrictions, extensions), not standard JavaScript.

-Frank-

[PR] Flex != Flash

2013-01-27 Thread Harbs

You guys might enjoy my blog post:
http://printui.com/blog/2013/01/flex-flash/

If you do, feel free to pass it on… ;-)

Harbs

Re: [PR] Flex != Flash


Where did you get 1992?

I think Gordon meant 2002 on his bio, someone correct me if I am wrong.

Mike

Quoting Harbs harbs.li...@gmail.com:


You guys might enjoy my blog post:
http://printui.com/blog/2013/01/flex-flash/

If you do, feel free to pass it on? ;-)

Harbs


--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [PR] Flex != Flash

2013-01-27 Thread Harbs

I copied it from his bio. If it was a typo, I'll correct it.

Yeah. 1992 sounds like a very long time ago…

On Jan 28, 2013, at 1:06 AM, Michael Schmalle wrote:

 Where did you get 1992?
 
 I think Gordon meant 2002 on his bio, someone correct me if I am wrong.
 
 Mike
 
 Quoting Harbs harbs.li...@gmail.com:
 
 You guys might enjoy my blog post:
 http://printui.com/blog/2013/01/flex-flash/
 
 If you do, feel free to pass it on? ;-)
 
 Harbs
 
 -- 
 Michael Schmalle - Teoti Graphix, LLC
 http://www.teotigraphix.com
 http://blog.teotigraphix.com

Re: [PR] Flex != Flash


I would change it now just to be safe so you don't flamed.

Very nice article Harbs, I think you caught exactly what I have been  
saying about what I envision the compiler turning into. My work on the  
compilers etc aims at taking the power of a language and pointing it  
in the direction we want.


Mike

Quoting Harbs harbs.li...@gmail.com:


I copied it from his bio. If it was a typo, I'll correct it.

Yeah. 1992 sounds like a very long time ago?

On Jan 28, 2013, at 1:06 AM, Michael Schmalle wrote:


Where did you get 1992?

I think Gordon meant 2002 on his bio, someone correct me if I am wrong.

Mike

Quoting Harbs harbs.li...@gmail.com:


You guys might enjoy my blog post:
http://printui.com/blog/2013/01/flex-flash/

If you do, feel free to pass it on? ;-)

Harbs


--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com






--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [PR] Flex != Flash

2013-01-27 Thread Harbs

Yeah. Changed already… ;-)

Thanks. I hope the article helps some more people get it. You guys have been 
doing awesome work!

On Jan 28, 2013, at 1:12 AM, Michael Schmalle wrote:

 I would change it now just to be safe so you don't flamed.
 
 Very nice article Harbs, I think you caught exactly what I have been saying 
 about what I envision the compiler turning into. My work on the compilers etc 
 aims at taking the power of a language and pointing it in the direction we 
 want.
 
 Mike
 
 Quoting Harbs harbs.li...@gmail.com:
 
 I copied it from his bio. If it was a typo, I'll correct it.
 
 Yeah. 1992 sounds like a very long time ago?
 
 On Jan 28, 2013, at 1:06 AM, Michael Schmalle wrote:
 
 Where did you get 1992?
 
 I think Gordon meant 2002 on his bio, someone correct me if I am wrong.
 
 Mike
 
 Quoting Harbs harbs.li...@gmail.com:
 
 You guys might enjoy my blog post:
 http://printui.com/blog/2013/01/flex-flash/
 
 If you do, feel free to pass it on? ;-)
 
 Harbs
 
 --
 Michael Schmalle - Teoti Graphix, LLC
 http://www.teotigraphix.com
 http://blog.teotigraphix.com
 
 
 
 
 -- 
 Michael Schmalle - Teoti Graphix, LLC
 http://www.teotigraphix.com
 http://blog.teotigraphix.com

RE: [PR] Flex != Flash

2013-01-27 Thread Flex

Nice Article!

-Oorspronkelijk bericht-
Van: Harbs [mailto:harbs.li...@gmail.com] 
Verzonden: zondag 27 januari 2013 23:16
Aan: dev@flex.apache.org
Onderwerp: Re: [PR] Flex != Flash

Yeah. Changed already. ;-)

Thanks. I hope the article helps some more people get it. You guys have
been doing awesome work!

On Jan 28, 2013, at 1:12 AM, Michael Schmalle wrote:

 I would change it now just to be safe so you don't flamed.
 
 Very nice article Harbs, I think you caught exactly what I have been
saying about what I envision the compiler turning into. My work on the
compilers etc aims at taking the power of a language and pointing it in the
direction we want.
 
 Mike
 
 Quoting Harbs harbs.li...@gmail.com:
 
 I copied it from his bio. If it was a typo, I'll correct it.
 
 Yeah. 1992 sounds like a very long time ago?
 
 On Jan 28, 2013, at 1:06 AM, Michael Schmalle wrote:
 
 Where did you get 1992?
 
 I think Gordon meant 2002 on his bio, someone correct me if I am wrong.
 
 Mike
 
 Quoting Harbs harbs.li...@gmail.com:
 
 You guys might enjoy my blog post:
 http://printui.com/blog/2013/01/flex-flash/
 
 If you do, feel free to pass it on? ;-)
 
 Harbs
 
 --
 Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com 
 http://blog.teotigraphix.com
 
 
 
 
 --
 Michael Schmalle - Teoti Graphix, LLC
 http://www.teotigraphix.com
 http://blog.teotigraphix.com

Re: ASJS question - MXML vs. AS

2013-01-27 Thread Alex Harui




On 1/27/13 7:18 PM, Om bigosma...@gmail.com wrote:

 Alex, I think you would be the best person to answer this.
 
 What would be the Actionscript equivalent of this mxml file:
 
 http://svn.apache.org/viewvc/flex/asjs/branches/develop/examples/FlexJSTest_ag
 ain/FlexJSTest.mxml?view=markup
 
 I was reading your older emails and I think this would be it:
 
 http://svn.apache.org/viewvc/flex/whiteboard/aharui/flexjs/example/FlexJSTest/
 FlexJSTest.as?view=markupor
 http://svn.apache.org/viewvc/flex/asjs/branches/develop/examples/FlexJSTest/Fl
 exJSTest.as?view=markup
 
 But they dont seem to match up.  Can you please respond with how the mxml
 would look when redone as a pure actionscript file?
 
There are two possible answers to this question.  One is for the question:
what would the generated AS for the MXML file look like?   It would look
somewhat like the FlexJSTest.as that you found, but it is a bit different
because when I finally got the compiler working it was easier to change some
of the 'generated' code a bit.  If you are really interested, I will try to
hand-code it.

The other answer is for the question: How would you write this app in
ActionScript?  If I were to do it, it would not use the data array at all,
it would call new Button and new Label and set properties and add event
handlers.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

[jira] [Commented] (FLEX-33366) The candidate input method can not follow

2013-01-27 Thread Alex Harui (JIRA)


[ 
https://issues.apache.org/jira/browse/FLEX-33366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13564058#comment-13564058
 ] 

Alex Harui commented on FLEX-33366:
---

I still cannot reproduce this problem.  Please go to 
http://flashplayerversion.com/ and tell me what it says.

Here is a test case for you to try:

?xml version=1.0 encoding=utf-8? 
s:Application xmlns:fx=http://ns.adobe.com/mxml/2009; 
   xmlns:s=library://ns.adobe.com/flex/spark 
   xmlns:mx=library://ns.adobe.com/flex/mx 
minWidth=955 minHeight=600 xmlns:local=* 
fx:Declarations 
!-- 将非可视元素（例如服务、值对象）放在此处 -- 
/fx:Declarations 
s:TextInput/ 
local:MySparkTextInput top=200 left=200 
skinClass=spark.skins.mobile.TextInputSkin/ 
mx:TextArea top=400 left=400/ 
/s:Application 

Where MySparkTextInput.as looks like this:

package
{
import spark.components.TextInput;

public class MySparkTextInput extends TextInput
{
public function MySparkTextInput()
{
super();
}

override public function get enableIME():Boolean
{
return true;
}
}
}

I had to add the mobile/mobilecomponents.swc to the project's library path and 
added frameworks/projects/mobiletheme/mobile/src to the project's source-path.


 The candidate input method can not follow
 -

 Key: FLEX-33366
 URL: https://issues.apache.org/jira/browse/FLEX-33366
 Project: Apache Flex
  Issue Type: Bug
  Components: Spark: TextArea, Spark: TextInput
Affects Versions: Apache Flex 4.8 (parity release)
 Environment: windows,IE8
Reporter: zy

 The spark:TextArea and TextInput  Chinese candidate input method can not 
 follow.
 But mx:TextArea and TextInput not this issue.
 I guess you only test the English input method, Chinese input methods all 
 have this problem, it is affecting the user experience.
 you can test this Chinese input method.all chinese use this.
 http://dl_dir.qq.com/invc/qqpinyin/QQPinyin_Setup_1.1.1224.400.exe
 I made a picture to illustrate the problem.
 http://img.my.csdn.net/uploads/201301/24/1359028348_2400.jpg
 If you are unclear, please let me know. I don't know english.I am very sorry.
 Thank you!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: ASJS question - MXML vs. AS

2013-01-27 Thread Om

On Sun, Jan 27, 2013 at 8:33 PM, Alex Harui aha...@adobe.com wrote:




 On 1/27/13 7:18 PM, Om bigosma...@gmail.com wrote:

  Alex, I think you would be the best person to answer this.
 
  What would be the Actionscript equivalent of this mxml file:
 
 
 http://svn.apache.org/viewvc/flex/asjs/branches/develop/examples/FlexJSTest_ag
  ain/FlexJSTest.mxml?view=markup
 
  I was reading your older emails and I think this would be it:
 
 
 http://svn.apache.org/viewvc/flex/whiteboard/aharui/flexjs/example/FlexJSTest/
  FlexJSTest.as?view=markupor
 
 http://svn.apache.org/viewvc/flex/asjs/branches/develop/examples/FlexJSTest/Fl
  exJSTest.as?view=markup
 
  But they dont seem to match up.  Can you please respond with how the mxml
  would look when redone as a pure actionscript file?
 
 There are two possible answers to this question.  One is for the question:
 what would the generated AS for the MXML file look like?   It would look
 somewhat like the FlexJSTest.as that you found, but it is a bit different
 because when I finally got the compiler working it was easier to change
 some
 of the 'generated' code a bit.  If you are really interested, I will try to
 hand-code it.


This would be good.  I played my hand around hand-coding based on this wiki
note [1]
But I would rather see your version.


 The other answer is for the question: How would you write this app in
 ActionScript?  If I were to do it, it would not use the data array at all,
 it would call new Button and new Label and set properties and add event
 handlers.

 --


I am curious how this would work behind the scenes.  But I am not in a
hurry to look at the implementation details.

A couple other questions while I have your attention:

Will the FlexJSTest_again app compile with the current mxmlc?  I saw your
note in the wiki that says that it wont.  Is there any way to make it work?

I have hooked up the falcon compiler to my flash builder (4.6) as an
external run tool.  The app compiles fine, but the IDE keeps showing
errors.  Any way I can jerry rig Flash Builder to use the Falcon mxmlc?

I do have Flash Builder 4.7 installed.  I am willing to switch if that
would make this process any simpler.

Sorry for so many questions.  I am trying to wrap my head around all this.
 My end goal here is to churn out Stage3D based Button and Label classes.
 I need to first set up everything so that I can work without having to
jump through hoops to compile every code change I make.

Thanks,
Om


[1]  https://cwiki.apache.org/confluence/display/FLEX/MXML+Data+Spec

RE: [PR] Flex != Flash

2013-01-27 Thread Sugan Naicker

Hi,

Excellent article! Thanks to the team for keeping the Flex flame burning.

Rgs,

Sugan Naicker
South Africa


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 28 January 2013 12:59 AM
To: dev@flex.apache.org
Subject: [PR] Flex != Flash

You guys might enjoy my blog post:
http://printui.com/blog/2013/01/flex-flash/

If you do, feel free to pass it on. ;-)

Harbs

Re: ASJS question - MXML vs. AS

2013-01-27 Thread Alex Harui




On 1/27/13 10:50 PM, Om bigosma...@gmail.com wrote:

 But they dont seem to match up.  Can you please respond with how the mxml
 would look when redone as a pure actionscript file?
 
 There are two possible answers to this question.  One is for the question:
 what would the generated AS for the MXML file look like?   It would look
 somewhat like the FlexJSTest.as that you found, but it is a bit different
 because when I finally got the compiler working it was easier to change
 some
 of the 'generated' code a bit.  If you are really interested, I will try to
 hand-code it.
 
 
 This would be good.  I played my hand around hand-coding based on this wiki
 note [1]
 But I would rather see your version.
I'm not sure why you want to be hand-coding AS versions of MXML files.

 
 
 The other answer is for the question: How would you write this app in
 ActionScript?  If I were to do it, it would not use the data array at all,
 it would call new Button and new Label and set properties and add event
 handlers.
 
 --
 
 
 I am curious how this would work behind the scenes.  But I am not in a
 hurry to look at the implementation details.
 
 A couple other questions while I have your attention:
 
 Will the FlexJSTest_again app compile with the current mxmlc?  I saw your
 note in the wiki that says that it wont.  Is there any way to make it work?
The status page supercedes the original wiki page.
FalconJS converts FlexJSTest.mxml to FlexJSTest.js.  Falcon (assuming you
set the mxml.children-as-data flag) will convert FlexJSTest.mxml to a
running SWF. 
 
 I have hooked up the falcon compiler to my flash builder (4.6) as an
 external run tool.  The app compiles fine, but the IDE keeps showing
 errors.  Any way I can jerry rig Flash Builder to use the Falcon mxmlc?
I haven't tried.  I assume you can swap out the original MXMLC compiler for
the Falcon JARs.

 
 I do have Flash Builder 4.7 installed.  I am willing to switch if that
 would make this process any simpler.
 
 Sorry for so many questions.  I am trying to wrap my head around all this.
  My end goal here is to churn out Stage3D based Button and Label classes.
  I need to first set up everything so that I can work without having to
 jump through hoops to compile every code change I make.
If that's your goal, I would skip the MXML part for now and build out a
simple test app in ActionScript.  Then you can do it all in either version
of FlashBuilder with the Apache Flex SDK and its MXMLC.

I think FlexJSTest.as would look something like this:

public class FlexJSTest extends Application
{
public function FlexJSTest()
{
model = new MyModel();
model.labelText = Hello World!;
valuesImpl = new MySimpleValuesImpl();
initialView = new MyInitialView();
controller = new MyController();
}

private var controller:MyController;
public var model:MyModel;
}

And MyInitialView.as would look something like this:

public class MyInitialView extends ViewBase
{
public function MyInitialView()
{
super();
}

override public function initUI(model:Object):void
{
super.initUI(model);
lbl = new Label();
lbl.addToParent(this);
...
}

public var lbl:Label;

private function clickHandler(event:Event):void
{
dispatchEvent(new Event(buttonClicked));
}

But I haven't tried it.  If you get stuck trying to figure it out, I will
take a look on Monday.  You might need to wait for the initialize event
before setting up the four instances in the Application's constructor.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [ASJS] Integration with existing JS libraries and components