FlexJS doesn’t work on IE yet. On my list of things to do.
On 3/28/13 11:55 AM, "Sugan Naicker" <su...@dev-x.co.za> wrote:
Hi,
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 value)
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
Regards,
Sugan Naicker
South Africa
-----Original Message-----
From: Erik de Bruin [mailto:e...@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 ;-)
EdB
On Wed, Mar 27, 2013 at 9:58 PM, Erik de Bruin <e...@ixsoftware.nl
<mailto: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
> <mailto: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
>> <mailto: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
>>>> <mailto:apa...@teotigraphix.com> > wrote:
>>>>
>>>>>
>>>>> Quoting Erik de Bruin <e...@ixsoftware.nl <mailto: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 <mailto: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 <mailto: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 <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.
http://blogs.adobe.com/aharui
