Hi Alex, Thanks. I will assist with testing.
Rgs, Sugan Naicker South Africa -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: 28 March 2013 09:46 PM To: dev@flex.apache.org Subject: Re: [FalconJx] progress update OK, thanks. There's lots of bugs in this prototype. Once I get a few more things cleaned up, maybe we'll start tracking bugs in JIRA. On 3/28/13 12:40 PM, "Sugan Naicker" <su...@dev-x.co.za> wrote: > 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 > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
