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
