Ok, we're back in business! I think this time I have been working with the right version of FlexJS (the one with the timer and the drop down list?) and it looks to work as advertised:
http://people.apache.org/~erikdebruin/flexjs/ Time to get packing for the long flight ;-) EdB On Fri, Mar 29, 2013 at 3:15 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: > Ah, and there's plenty left for you to "learn" from :-) > > EdB > > > > On Fri, Mar 29, 2013 at 2:30 PM, Alex Harui <aha...@adobe.com> wrote: >> No worries. Might be a good way for me to learn how it works by getting it >> to work. >> >> >> On 3/29/13 12:31 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >>> Uh oh... Turns out I was testing against an outdated ASJS lib >>> (pre-fb614905ac), so FalconJx DOESN'T WORK against the current >>> iteration of FlexJS. Sorry about that. I will work on that today, but >>> I don't have a lot of time, so it might be a while before I can catch >>> up, due to next week's travel to the land of golden opportunity. >>> >>> EdB >>> >>> On Thu, Mar 28, 2013 at 5:24 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: >>>> 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/ >>>> >>>> Onwards and upwards ;-) >>>> >>>> EdB >>>> >>>> >>>> On Wed, Mar 27, 2013 at 9:58 PM, Erik de Bruin <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> 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> 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> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Quoting Erik de Bruin <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> >>>>>>>> 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> 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 >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Alex Harui >>>>>> Flex SDK Team >>>>>> Adobe Systems, Inc. >>>>>> http://blogs.adobe.com/aharui >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ix Multimedia Software >>>>> >>>>> Jan Luykenstraat 27 >>>>> 3521 VB Utrecht >>>>> >>>>> T. 06-51952295 >>>>> I. www.ixsoftware.nl >>>> >>>> >>>> >>>> -- >>>> Ix Multimedia Software >>>> >>>> Jan Luykenstraat 27 >>>> 3521 VB Utrecht >>>> >>>> T. 06-51952295 >>>> I. www.ixsoftware.nl >>> >>> >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
