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
