No, because I ran the link to your app in the debugger in Safari and I get the exception. I don't think the flash.*.* thing is involved in your version right?
If you run http://people.apache.org/~erikdebruin/flexjs/ in the JS debugger it doesn't send exceptions to the console? And changing the selection in the dropdownlist changes the label and/or textarea? I'm offline for a bit. I'll look into it more tonight. On 3/30/13 9:16 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > Did you try to put the flash.*.* thing back (revert your latest commit)? > > EdB > > > > On Sat, Mar 30, 2013 at 4:20 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: >> Or, it might have something to do with your last ASJS commit... remove >> flash.*.* from implicit imports... If you revert that locally, does >> FalconJx work? It wasn't there yesterday, so that's the only >> difference in code between you and me. >> >> We need to set up functional testing for Falcon/FlexJS soon! >> >> EdB >> >> >> >> On Sat, Mar 30, 2013 at 4:15 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: >>> Nope, Safari works well for me, and there doesn't need to be the extra >>> method in the main HTML anymore, I remember. Weird. >>> >>> EdB >>> >>> >>> >>> On Sat, Mar 30, 2013 at 4:13 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: >>>> Maybe I'm doing something wrong... the example on my p.a.o works for you? >>>> >>>> http://people.apache.org/~erikdebruin/flexjs/ >>>> >>>> Maybe try Chrome? >>>> >>>> EdB >>>> >>>> >>>> >>>> On Sat, Mar 30, 2013 at 4:01 PM, Alex Harui <aha...@adobe.com> wrote: >>>>> I'm not seeing anything like that in the HTML wrapper. Safari is >>>>> definitely >>>>> throwing on exception on "new Event". Any idea what I'm doing wrong? >>>>> >>>>> >>>>> On 3/30/13 7:54 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >>>>> >>>>>> I left out FlexGlobals on purpose, I plan to bring the Google Closure >>>>>> way of dealing with events to FlexJS. The GC way is not dependent on >>>>>> DOM based events and fits very snugly with the way Flex handles >>>>>> events. >>>>>> >>>>>> In the mean time I've a method in the "main" HTML that is called Event >>>>>> and that passes the event through to FlexGlobals for now. >>>>>> >>>>>> EdB >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Mar 30, 2013 at 3:47 PM, Alex Harui <aha...@adobe.com> wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> I finally got time to try to switch over to FalconJX. It produces js >>>>>>> files >>>>>>> and the app shows up, but the console shows an exception and the >>>>>>> interactivity of the application is mostly broken because the generated >>>>>>> js >>>>>>> code has snippets like this: >>>>>>> >>>>>>> models.MyModel.prototype.set_labelText = function(value) { >>>>>>> var self = this; >>>>>>> if (value != self._labelText) { >>>>>>> self._labelText = value; >>>>>>> self.dispatchEvent(new Event("labelTextChanged")); >>>>>>> } >>>>>>> }; >>>>>>> >>>>>>> In the FalconJS output, we are calling FlexGlobals.newObject because >>>>>>> Event >>>>>>> is a special class in the browser that can't be instantiated via "new" >>>>>>> and >>>>>>> FlexJS is using these DOM Events. >>>>>>> >>>>>>> Did I miss a flag, or can I go about trying to intercept these calls and >>>>>>> have them call FlexGlobals.newObject instead? >>>>>>> >>>>>>> -Alex >>>>>>> >>>>>>> >>>>>>> On 3/29/13 11:58 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >> >> >> >> -- >> 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
