Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with existing JS libraries and components

> Peace? There was never anything else, as far as I'm concerned. Like you say, questioning and challenging are part of the process. Your ideas and questions forced me to take a second (and third) look at my solution and convinced me that I'm on the right path to achieve what I set out to do. Don'

Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with existing JS libraries and components

On Mon, Jan 28, 2013 at 10:44 AM, Erik de Bruin wrote: > Mike, > > I was aleady afraid we were boring, or worse, bothering the community. > I apologize for my part in it. Like you I'm more of a tool maker, as > you know well. I do get distracted when I get the impression that my > efforts (non-tr

Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with existing JS libraries and components

Frank, My comments below only were to echo the understanding of your experience in the AS->JS. When I said Job it is the emitter, the emitter is the Job, meaning the tool(FalconJx) is used to do the Job(emit javascript). When I design frameworks, I make sure there are clear dividing lines

Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with existing JS libraries and components

On Mon, Jan 28, 2013 at 10:36 AM, Michael Schmalle wrote: > > Quoting Frank Wienberg : > > Hi Alain, >> >> for Jangaroo, I answered this question here: >> http://markmail.org/message/**bwjwc7sxfbertu7f >> For Flex / FalconJx, it seems nobody was extre

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

I think this a relevant and new discussion, so I moved it to a new thread: "[ASJS] debugging output JS?" EdB On Mon, Jan 28, 2013 at 10:33 AM, Roland Zwaga wrote: > On 28 January 2013 10:29, Erik de Bruin wrote: > >> > This won't work for us (Jangaroo/Ext AS users). In our development >> > wo

Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with existing JS libraries and components

Mike, I was aleady afraid we were boring, or worse, bothering the community. I apologize for my part in it. Like you I'm more of a tool maker, as you know well. I do get distracted when I get the impression that my efforts (non-trivial, let me assure you!) are questioned and belittled. So I get on

Tools vs Impl - Don't mix the two was [ASJS] Integration with existing JS libraries and components

Quoting Frank Wienberg : Hi Alain, for Jangaroo, I answered this question here: http://markmail.org/message/bwjwc7sxfbertu7f For Flex / FalconJx, it seems nobody was extremely fond of the idea to have to keep all the white-space and take care of generating JS code in the exact line of the sour

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

On 28 January 2013 10:29, Erik de Bruin wrote: > > This won't work for us (Jangaroo/Ext AS users). In our development > > workflow, JS/HTML5 is the one and only target platform. And I think this > is > > the future for Flex. If Flex will not support the full development > > lifecycle for HTML5 pr

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

> This won't work for us (Jangaroo/Ext AS users). In our development > workflow, JS/HTML5 is the one and only target platform. And I think this is > the future for Flex. If Flex will not support the full development > lifecycle for HTML5 projects, it is of no interest for us and I guess for > many

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

On Mon, Jan 28, 2013 at 10:04 AM, Erik de Bruin wrote: > Alain, > > In my view all development, including debugging, is done in AS. The JS > output, like bytecode, should "just work". > > EdB > > This won't work for us (Jangaroo/Ext AS users). In our development workflow, JS/HTML5 is the one and

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

Hi Alain, for Jangaroo, I answered this question here: http://markmail.org/message/bwjwc7sxfbertu7f For Flex / FalconJx, it seems nobody was extremely fond of the idea to have to keep all the white-space and take care of generating JS code in the exact line of the source AS code. So we have to fin

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

Alain, In my view all development, including debugging, is done in AS. The JS output, like bytecode, should "just work". EdB On Mon, Jan 28, 2013 at 9:20 AM, Alain Ekambi wrote: > One thing I was thinking about. How would debugging work ? Let's say I set > a break point in my as3 code how wil

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

Hi, >> We're talking AS -> JS cross compilation. So changing one file would >> be changing one AS file. To turn that AS file into a JS file needs a >> compilation step. The generation of 'deps.js' is part of the >> compilation step. So, in the scenario we're discussing, the >> regeneration is of n

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

On Mon, Jan 28, 2013 at 8:36 AM, Erik de Bruin wrote: > Hi, > > > 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 > > We're talkin

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

One thing I was thinking about. How would debugging work ? Let's say I set a break point in my as3 code how will debugging the js output look like Greets Alain On Jan 28, 2013 8:37 AM, "Erik de Bruin" wrote: > Hi, > > > entire library + application". My example was that you change a single > >

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

Hi, > 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 We're talking AS -> JS cross compilation. So changing one file would be changing

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

On Sun, Jan 27, 2013 at 5:52 PM, Erik de Bruin 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 nece

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

Really. On Sun, Jan 27, 2013 at 10:11 AM, Erik de Bruin 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

> 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

Not really sure what's offensive about what I said. I was just pointing out the PMC doesn't veto commits. Take a chill pill. ;) -omar On Sunday, January 27, 2013, Erik de Bruin wrote: > No a very constructive comment, if you don't mind me saying. > > But while we're on the subject: you can only

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

No a very constructive comment, if you don't mind me saying. But while we're on the subject: you can only include something in the SDK if it's actually coded and contributed to the project. Just to be clear. EdB On Sun, Jan 27, 2013 at 6:00 PM, Omar Gonzalez wrote: > Well the PMC would not v

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

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 Wa

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

> 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

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

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 wrote: > Is Example.js a generated cross compile? > > Mike > > > Quoting Erik de Bruin : > Please take a look

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

On 27 January 2013 16:14, Frank Wienberg wrote: > 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

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 dec

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

Mike, no harm done. I don't mind you being sarcastic, I always find it refreshing! :-)

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! :) E

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

On Sun, Jan 27, 2013 at 2:51 PM, Michael Schmalle wrote: > > Quoting Frank Wienberg : > > > >> >>> 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 th

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

Quoting Frank Wienberg : 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 Mic

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

On Sun, Jan 27, 2013 at 1:03 PM, Erik de Bruin 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

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

Is Example.js a generated cross compile? Mike Quoting Erik de Bruin : 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

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 runnin

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

These are a lot of the reasons why I chose RequireJS over Google Closure for my JavaScript work. Just saying. -omar On Sunday, January 27, 2013, Frank Wienberg wrote: > On Sat, Jan 26, 2013 at 7:55 AM, Erik de Bruin > > > wrote: > > > > code and vice versa. I still think that RequireJS is the

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

On Fri, Jan 25, 2013 at 11:56 PM, Alain Ekambi wrote: > @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

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

On Sat, Jan 26, 2013 at 7:55 AM, Erik de Bruin wrote: > > code and vice versa. I still think that RequireJS is the better choice, > as > > Closure implements *synchronous* require() which does not work > dynamically > > in the browser, and the Closure Library comes with many many more > features,

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

Hey Erik, comments inline as usual: On 26 January 2013 08:28, Erik de Bruin wrote: > Hi, > > > My main problem with using Closure is that it introduces a second parsing > > and manipulation > > pass while, IMHO, all of the necessary work can be done inside Falcon > since > > all necessary > > i

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

Hi, > My main problem with using Closure is that it introduces a second parsing > and manipulation > pass while, IMHO, all of the necessary work can be done inside Falcon since > all necessary > information is contained within the AST. Therefore implementing the whole > shebang inside > Falcon wil

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

> code and vice versa. I still think that RequireJS is the better choice, as > Closure implements *synchronous* require() which does not work dynamically > in the browser, and the Closure Library comes with many many more features, I really wish you would stop saying this. It is simply not true. P

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

@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) 20

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

Hi Alain, I'm not sure if the license really comes into play here, all we're doing is integrate with an API, we don't fork or use their code in any way. We might have to look into the implications for crating an AS3 shim for their API's though, so you do make a valid point. Roland On 25 January

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

Hey Frank, thanks a lot for your elaborate answer (as usual). Basically everything I had in mind you pretty much described. So I'm pretty stoked that this could be implemented rather quickly. Between your and Erik's approach I already prefered yours to be honest (Erik, this is no stab under water

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

Before going further with ExtJS make sure licensing is clear. Cuz ExtJS is GPL/Commercial. 2013/1/25 Frank Wienberg > Hi Roland, > > thank you for bringing up this point, I think it is crucial for the success > of Apache Flex / JS! > I Erik's latest thread, we just discussed the different appro

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

Hi Roland, thank you for bringing up this point, I think it is crucial for the success of Apache Flex / JS! I Erik's latest thread, we just discussed the different approaches to come up with a JS-enabled component library for Flex. I mentioned that we already have an ActionScript-API for Ext JS fr

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

On 25 January 2013 22:03, Erik de Bruin wrote: > > We most certainly will, once we get our misunderstandings out of the way > :) > > I think we both aim for the same things, we just need to find the same > > wavelengths :) > > Your followup mails -- and me re-reading the original one, I know I >

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

> We most certainly will, once we get our misunderstandings out of the way :) > I think we both aim for the same things, we just need to find the same > wavelengths :) Your followup mails -- and me re-reading the original one, I know I was lazy reading it the first time :-) -- cleared things up a

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

Hi Alex, I think you got my drift, comments are inline again: On 25 January 2013 21:33, Alex Harui wrote: > While both Erik and I are using Goog, I think Roland is asking why we > aren't > use Jquery or ExtJS UI components. > Exactly, and I'm certainly NOT claiming that you and Erik should NOT

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

Hey Erik, comments are inline: > The way that TypeScript and Randori/SharpKit integrate with JS is by > > declaring some sort of interface which has exactly > > the same signatures of their JS counterparts. I think this will quite > > probably make the most sense for Apache Flex as well. > > That

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

While both Erik and I are using Goog, I think Roland is asking why we aren't use Jquery or ExtJS UI components. In my framework, I'm not right now because I had trouble getting my head around them and the ones I looked at seemed to come with application framework infrastructure, and I want to star

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

> The title of this message says exactly what I mean. Right now we're talking > about cross compiling the Flex SDK > itself, along with all of its components. No, neither Alex nor I are taking that approach. > The way that TypeScript and Randori/SharpKit integrate with JS is by > declaring some s

[ASJS] Integration with existing JS libraries and components

Hi there, to continue the discussion about AS->JS cross compilation, I'd like to add another option which, I think, could lead to better acceptance of Apache Flex in the HTML5/JS sphere. The title of this message says exactly what I mean. Right now we're talking about cross compiling the Flex SDK