Hi Alex, >> FlexJS doesn't work on IE yet. On my list of things to do.
Great thanks for the feedback. I tested your version on Firefox (V14.0.1) and it works, except for the TRANSER button does not work. (Text typed into the Text Input box does not transfer to text box above) Regards, Sugan Naicker South Africa -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: 28 March 2013 09:09 PM To: dev@flex.apache.org Subject: Re: [FalconJx] progress update FlexJS doesn't work on IE yet. On my list of things to do. On 3/28/13 11:55 AM, "Sugan Naicker" <su...@dev-x.co.za> wrote: Hi, Ran the following tests : 1) Firefox (V14.0.1) - works (see pic below) Issues : 1) I found is that when you 'rapidly' click on the radio box 'text' in quick succession, 'sometimes' the correct radio box does not get selected. Example below - GREEN selected (and highlighted), but radio box not activated. 2) Clicking on the OK button takes some time before a value appears in the text box. Note sure what is coded behind the OK button (if it is fetching a value from web and returning value) 2) IE (V9.0.8112) - does not work (see pic below) - Get "undefined" above OK button and in Text box - Radio and Check box are selectable - Button's are unresponsive - Clicking on AAPL, etc does not push value to text box Regards, Sugan Naicker South Africa -----Original Message----- From: Erik de Bruin [mailto:e...@ixsoftware.nl] Sent: 28 March 2013 06:24 PM To: dev@flex.apache.org Subject: Re: [FalconJx] progress update And another update (things are going much better than I expected): FalconJx can now emit a fully functional version of the FlexJSTest_again demo application. You can see it in action here (provided you use Chrome or Firefox, I just noticed): http://people.apache.org/~erikdebruin/flexjs/ <http://people.apache.org/~erikdebruin/flexjs/> Onwards and upwards ;-) EdB On Wed, Mar 27, 2013 at 9:58 PM, Erik de Bruin <e...@ixsoftware.nl <mailto:e...@ixsoftware.nl> > wrote: > I'd have to look into it for specifics, but of the top of my head it > seems that this most depends on the implementation in the FlexJS JS > framework. Emitting the strings required by that framework should > really be easy enough. If needed we can "look forward" into AST to > look for binding information. I do this in several other places > already. Even the binding expressions shouldn't be too much of a > problem, again depending on how this will be handled by the JS > framework. > > EdB > > > > On Wed, Mar 27, 2013 at 9:36 PM, Alex Harui <aha...@adobe.com <mailto:aha...@adobe.com> > wrote: >> [Bindable] results in extra codegen. Binding expressions with {} is >> a whole other ball of work. >> >> I think in FalconJX you might have to modify the node tree in several >> places when you hit a [Bindable] node. >> >> It isn't working correctly in FalconJS either, but my "customer" >> needs it so I'm hacking a fix. >> >> >> On 3/27/13 1:28 PM, "Erik de Bruin" <e...@ixsoftware.nl <mailto:e...@ixsoftware.nl> > wrote: >> >>> No, not yet. How is this set up in FlexJS? I'm sure I can read >>> Metadata and Databinding information, so I guess it depends on the >>> requirements for the emitted JS if I can easily implement this ;-) >>> >>> EdB >>> >>> >>> >>> On Wednesday, March 27, 2013, Alex Harui wrote: >>> >>>> Does FalconJX handle [Bindable]? My "customer" is using it. >>>> >>>> >>>> On 3/27/13 11:56 AM, "Michael Schmalle" <apa...@teotigraphix.com <mailto:apa...@teotigraphix.com> > wrote: >>>> >>>>> >>>>> Quoting Erik de Bruin <e...@ixsoftware.nl <mailto:e...@ixsoftware.nl> >: >>>>> >>>>>> Another one popped into my head just now: I have a gut feeling >>>>>> there is a bit of circular logic going on in the whole 'backend', >>>>>> 'blockwalker' and 'emitter' construct. More specifically in the >>>>>> way the references to them are passed around as arguments in the >>>>>> constructors for the various classes. But I can't wrap around it >>>>>> well enough to figure out whether it's wrong and if so, what >>>>>> might be done about it. Don't get me wrong, it works well, it's >>>>>> just that it somehow isn't "elegant". And that's in no way a >>>>>> comment on the effectiveness or quality of your code, just >>>>>> something I thought I'd share and see what you think. >>>>> >>>>> Actually I think it works fine. The problem you are facing is with >>>>> the MXML emitter I am sure. This adds complexity to what you are >>>>> trying to accomplish and it is circular from the perspective of >>>>> using AS within MXML. >>>>> >>>>> There is a buffer writer(output stream), a writer, a visitor and emitter. >>>>> >>>>> Each one takes a dependency of its parent. Trust me, if there is a >>>>> child that knows about its parent I am blind. Like I said, the >>>>> block walker is a visitor and the emitter is a visitor. You cannot >>>>> escape the fact there is recursion. >>>>> >>>>> If you can think of a more elegant way to set it up, by all means >>>>> write a prototype. Remember, I wrote this with an atom bomb under >>>>> me and lighting in the sky, there may be parts that could be logicalized. >>>>> >>>>> I have another full compiler in Randori that I am going to use as >>>>> a proof of concept with compiler plugins and my ASDoc compiler I wrote. >>>>> So I guess we both can experiment, we can agree to leave the core >>>>> alone for the time being. >>>>> >>>>> >>>>>> EdB >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 27, 2013 at 7:41 PM, Erik de Bruin >>>>>> <e...@ixsoftware.nl <mailto:e...@ixsoftware.nl> > >>>> wrote: >>>>>>> Mike, >>>>>>> >>>>>>> Just kidding ;-) >>>>>>> >>>>>>> I'm really happy with FalconJx, once you get to know it it's a >>>>>>> pleasure to work with. I hope my last commits didn't give you >>>>>>> any additional work in your other projects? I did my best to >>>>>>> leave all the APIs alone. >>>>>>> >>>>>>> There are plenty of TODOs in the code, and I would also like to >>>>>>> suggest some kind of code review or something (I'm not used to >>>>>>> working in groups, but that seems like a nice thing to do), >>>>>>> since I've been piling on stuff. I did my best to keep >>>>>>> everything clean and in line with the spirit of the rest of the >>>>>>> code, but there are some areas where I'd like to have a second >>>>>>> opinion. Like with the code that is copied between the DOC and >>>>>>> JS emitters, seems there might be room for improvement there. >>>>>>> Also of note is the way I've implemented the AS emitting within >>>>>>> the MXML emitter, not really sure if I did the right thing >>>>>>> there. And finally (not really, but this is all I can think of >>>>>>> for now, after the marathon hacking I did today) there is the >>>>>>> whole "programming to interfaces, not implementations" part that we nearly adhere to, but not quite, we might have another look at that as well. >>>>>>> >>>>>>> EdB >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 27, 2013 at 7:33 PM, Michael Schmalle >>>>>>> <apa...@teotigraphix.com <mailto:apa...@teotigraphix.com> > wrote: >>>>>>>> No thats not what I meant. >>>>>>>> >>>>>>>> I am saying with the Randori project compiler, I have not had >>>>>>>> to >>>> touch the >>>>>>>> core framework for weeks and it is compiling 1000's of lines of code. >>>> And >>>>>>>> application code now. >>>>>>>> >>>>>>>> What I meant to say was, the design keeps people in the correct >>>> spaces. :) >>>>>>>> >>>>>>>> Note; I AM SURE there are as3 bugs coming, its just nice not >>>>>>>> having to chase them right now. >>>>>>>> >>>>>>>> Mike >>>> Alex Harui >>>> Flex SDK Team >>>> Adobe Systems, Inc. >>>> http://blogs.adobe.com/aharui <http://blogs.adobe.com/aharui> >>>> >>>> >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui <http://blogs.adobe.com/aharui> >> > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl <http://www.ixsoftware.nl> -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl <http://www.ixsoftware.nl> -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
