flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FalconJx] progress update
Date Thu, 28 Mar 2013 19:08:58 GMT
FlexJS doesn’t work on IE yet.  On my list of things to do.

On 3/28/13 11:55 AM, "Sugan Naicker" <Sugan@Dev-X.co.za> wrote:


Ran the following tests :

1) Firefox (V14.0.1) - works         (see pic below)

Issues :
1)      I found is that when you ‘rapidly’ click on the radio box ‘text’ in quick
succession, ‘sometimes’ the correct radio box does not get selected.
Example below - GREEN selected (and highlighted), but radio box not activated.

2)      Clicking on the OK button takes some time before a value appears in the text box.
Note sure what is coded behind the OK button (if it is fetching a value from web and returning

2) IE (V9.0.8112) - does not work  (see pic below)

                - Get “undefined” above OK button and in Text box
                - Radio and Check box are selectable
                - Button’s are unresponsive
                - Clicking on AAPL, etc does not push value to text box


Sugan Naicker
South Africa

-----Original Message-----
From: Erik de Bruin [mailto:erik@ixsoftware.nl]
Sent: 28 March 2013 06:24 PM
To: dev@flex.apache.org
Subject: Re: [FalconJx] progress update

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/ <http://people.apache.org/~erikdebruin/flexjs/>

Onwards and upwards ;-)


On Wed, Mar 27, 2013 at 9:58 PM, Erik de Bruin <erik@ixsoftware.nl <mailto:erik@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 <aharui@adobe.com <mailto:aharui@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" <erik@ixsoftware.nl <mailto:erik@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" <apache@teotigraphix.com <mailto:apache@teotigraphix.com>
> wrote:
>>>>> Quoting Erik de Bruin <erik@ixsoftware.nl <mailto:erik@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
>>>>>> <erik@ixsoftware.nl <mailto:erik@ixsoftware.nl> >
>>>> wrote:
>>>>>>> Mike,
>>>>>>> Just kidding ;-)
>>>>>>> I'm really happy with FalconJx, once you get to know it it's
>>>>>>> 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
>>>>>>> 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
>>>>>>> <apache@teotigraphix.com <mailto:apache@teotigraphix.com>
> wrote:
>>>>>>>> No thats not what I meant.
>>>>>>>> I am saying with the Randori project compiler, I have not
>>>>>>>> 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
>>>>>>>> having to chase them right now.
>>>>>>>> Mike
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui <http://blogs.adobe.com/aharui>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui <http://blogs.adobe.com/aharui>
> --
> Ix Multimedia Software
> Jan Luykenstraat 27
> 3521 VB Utrecht
> T. 06-51952295
> I. www.ixsoftware.nl <http://www.ixsoftware.nl>

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl <http://www.ixsoftware.nl>

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message