Probably not related to what you guys are discussing, but Erik's latest changes send to have caused the list to look more like a drop down list. This used to work fine in both versions a couple of days ago.
Thanks, Om On Mar 30, 2013 9:34 AM, "Alex Harui" <aha...@adobe.com> wrote: > 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 > >
