You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2013/11/13 16:47:05 UTC
[FLEXJS] CSS value handling can't work in release code
Hi,
Alex, I hope I'm wrong, but...
I was looking at the DataGridExample example and I couldn't get it to
run from the release code. It runs fine from the debug code, just not
the release code. I did a lot of digging and stepping through the code
until I finally hit the 'init' method on the SimpleCSSValueImpl class.
This stores the namespace string from the CSS property in the
subsequent namespace objects in JS, if I understand the code
correctly. This works fine in debug mode, where all the namespaces
live unaltered in the window object.
In release mode, however, things work differently. The Closure
Compiler minifies the code, so the namespace
'org.apache.flex.core.UIBase' will get renamed to 'ae' (or something).
This causes the 'getQualifiedClassName' methods to fail, as it will
try to recreate 'org.apache.flex.core.UIBase' from something that has
been optimised into nothing...
I'm looking for a solution, but I don't think there is going to be a simple one.
For future reference: don't debug FlexJS with the debug code, rather
use the release code and the source map. That way you won't be too
committed to a certain approach before someone notices if likely won't
work as advertised.
Thanks,
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Alex Harui <ah...@adobe.com>.
Actually, it was these two:
as/src/org/apache/flex/html/staticControls/TitleBar.as: _titleLabel.class
Name = className;
as/src/org/apache/flex/html/staticControls/TitleBar.as: _closeButton.clas
sName = className;
But popup might be an issue as well.
But you reminded me that on the JS side, "element.className" is "ok". It
is used to assign a class selector of options to an HTMLElement.
-Alex
On 11/15/13 10:46 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>popup.className = 'popup' and this.titleLabel.element.className =
>'TitleBarLabel'?
>
>EdB
>
>
>
>On Fri, Nov 15, 2013 at 7:33 PM, Alex Harui <ah...@adobe.com> wrote:
>> Hopefully, although I grep'd and think I saw two places where there was
>> some cheating going on.
>>
>> -Alex
>>
>> On 11/15/13 10:27 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>>Or, since that has gone the way of the dodo, I can just feed it
>>>'this.FLEXJS_CLASS_INFO.names[0].name' ;-)
>>>
>>>EdB
>>>
>>>
>>>
>>>On Fri, Nov 15, 2013 at 7:12 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> Looks like it should be ok to replace with getQualifiedClassName().
>>>>
>>>> -Alex
>>>>
>>>> On 11/15/13 9:56 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>>Is there a particular reason there is a 'className' property which is
>>>>>set on some, but not all classes and even has 'getter/setter' methods?
>>>>>
>>>>>Unless the property is seriously misnamed, why would you want to be
>>>>>able to SET a class' name? If anything is constant, it should be the
>>>>>name of the class, shouldn't it?
>>>>>
>>>>>It looks like a legacy thing. Would it be alright to remove it? The
>>>>>information is now available in the metadata.
>>>>>
>>>>>EdB
>>>>>
>>>>>
>>>>>
>>>>>On Fri, Nov 15, 2013 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>> Awesome! Definitely looked like a lot of work. Thanks for doing
>>>>>>it.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> On 11/15/13 8:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>>
>>>>>>>Big update: fixed!
>>>>>>>
>>>>>>>If you really want to know what needed to happen to make this work,
>>>>>>>please read the commit messages. It wasn't a simple fix.
>>>>>>>
>>>>>>>Note: the metadata property is now required on each class in the
>>>>>>>framework. I've added it to all the classes in the FlexJS framework
>>>>>>>that are under active development. Please read the source for
>>>>>>>examples, and I've added a small section to the wiki for reference:
>>>>>>>
>>>>>>>https://cwiki.apache.org/confluence/x/W5sTAg
>>>>>>>
>>>>>>>This was fun, but has taken way too much time, so I'll have to catch
>>>>>>>up on my regular work in the coming week(s) ;-)
>>>>>>>
>>>>>>>EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>>>wrote:
>>>>>>>> Ah, small update: a lot of the warnings remaining in 'strict' mode
>>>>>>>>are
>>>>>>>> for the classes the compiler misses... That at least combines the
>>>>>>>> issues, two birds with one stone and all ;-)
>>>>>>>>
>>>>>>>> EdB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin
>>>>>>>><er...@ixsoftware.nl>
>>>>>>>>wrote:
>>>>>>>>> This may be worse than we thought...
>>>>>>>>>
>>>>>>>>> When I fixed the storage and retrieval of the CSS properties, it
>>>>>>>>>still
>>>>>>>>> didn't work properly in release mode. Some classes are found and
>>>>>>>>> bound, others are not. Turns out that the Closure Compiler
>>>>>>>>>doesn't
>>>>>>>>> resolve all dependencies accurately, the classes it misses are
>>>>>>>>>never
>>>>>>>>> 'considered' during compilation :-(
>>>>>>>>>
>>>>>>>>> I will look into the custom dependency algorithm in the Publisher
>>>>>>>>> next. Wish me luck ;-)
>>>>>>>>>
>>>>>>>>> Also, the fix will literally affect all JS classes, so prepare
>>>>>>>>>for
>>>>>>>>> some interesting merges. If I find a solution, I'll publish it
>>>>>>>>>first
>>>>>>>>> in a branch, so we can look at it together before we "commit".
>>>>>>>>>
>>>>>>>>> EdB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin
>>>>>>>>><er...@ixsoftware.nl>
>>>>>>>>>wrote:
>>>>>>>>>>>>One thought is that we might store both the 'name' and the
>>>>>>>>>>>>'qName'
>>>>>>>>>>>>in
>>>>>>>>>>>>the class metadata (where currently only the interfaces - if
>>>>>>>>>>>>any
>>>>>>>>>>>>-
>>>>>>>>>>>>live) and adopt the 'getValue' routines to search that instead
>>>>>>>>>>>>of
>>>>>>>>>>>>the
>>>>>>>>>>>>entire namespace chain. This would get rid of the need for the
>>>>>>>>>>>>dreaded
>>>>>>>>>>>>'__proto__' as well...
>>>>>>>>>>> Sounds good. We need to find the superclass somehow as well.
>>>>>>>>>>
>>>>>>>>>> Alex, can you please create a JIRA issue for this and assign it
>>>>>>>>>>to
>>>>>>>>>>me.
>>>>>>>>>> I don't think I'll have time in the next few days to work on
>>>>>>>>>>this,
>>>>>>>>>>and
>>>>>>>>>> I don't want any details to get lost in the avalanche of emails
>>>>>>>>>>on
>>>>>>>>>>the
>>>>>>>>>> list.
>>>>>>>>>>
>>>>>>>>>> EdB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
popup.className = 'popup' and this.titleLabel.element.className =
'TitleBarLabel'?
EdB
On Fri, Nov 15, 2013 at 7:33 PM, Alex Harui <ah...@adobe.com> wrote:
> Hopefully, although I grep'd and think I saw two places where there was
> some cheating going on.
>
> -Alex
>
> On 11/15/13 10:27 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>Or, since that has gone the way of the dodo, I can just feed it
>>'this.FLEXJS_CLASS_INFO.names[0].name' ;-)
>>
>>EdB
>>
>>
>>
>>On Fri, Nov 15, 2013 at 7:12 PM, Alex Harui <ah...@adobe.com> wrote:
>>> Looks like it should be ok to replace with getQualifiedClassName().
>>>
>>> -Alex
>>>
>>> On 11/15/13 9:56 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>>Is there a particular reason there is a 'className' property which is
>>>>set on some, but not all classes and even has 'getter/setter' methods?
>>>>
>>>>Unless the property is seriously misnamed, why would you want to be
>>>>able to SET a class' name? If anything is constant, it should be the
>>>>name of the class, shouldn't it?
>>>>
>>>>It looks like a legacy thing. Would it be alright to remove it? The
>>>>information is now available in the metadata.
>>>>
>>>>EdB
>>>>
>>>>
>>>>
>>>>On Fri, Nov 15, 2013 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> Awesome! Definitely looked like a lot of work. Thanks for doing it.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 11/15/13 8:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>
>>>>>>Big update: fixed!
>>>>>>
>>>>>>If you really want to know what needed to happen to make this work,
>>>>>>please read the commit messages. It wasn't a simple fix.
>>>>>>
>>>>>>Note: the metadata property is now required on each class in the
>>>>>>framework. I've added it to all the classes in the FlexJS framework
>>>>>>that are under active development. Please read the source for
>>>>>>examples, and I've added a small section to the wiki for reference:
>>>>>>
>>>>>>https://cwiki.apache.org/confluence/x/W5sTAg
>>>>>>
>>>>>>This was fun, but has taken way too much time, so I'll have to catch
>>>>>>up on my regular work in the coming week(s) ;-)
>>>>>>
>>>>>>EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>>wrote:
>>>>>>> Ah, small update: a lot of the warnings remaining in 'strict' mode
>>>>>>>are
>>>>>>> for the classes the compiler misses... That at least combines the
>>>>>>> issues, two birds with one stone and all ;-)
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>>>wrote:
>>>>>>>> This may be worse than we thought...
>>>>>>>>
>>>>>>>> When I fixed the storage and retrieval of the CSS properties, it
>>>>>>>>still
>>>>>>>> didn't work properly in release mode. Some classes are found and
>>>>>>>> bound, others are not. Turns out that the Closure Compiler doesn't
>>>>>>>> resolve all dependencies accurately, the classes it misses are
>>>>>>>>never
>>>>>>>> 'considered' during compilation :-(
>>>>>>>>
>>>>>>>> I will look into the custom dependency algorithm in the Publisher
>>>>>>>> next. Wish me luck ;-)
>>>>>>>>
>>>>>>>> Also, the fix will literally affect all JS classes, so prepare for
>>>>>>>> some interesting merges. If I find a solution, I'll publish it
>>>>>>>>first
>>>>>>>> in a branch, so we can look at it together before we "commit".
>>>>>>>>
>>>>>>>> EdB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>>>>wrote:
>>>>>>>>>>>One thought is that we might store both the 'name' and the
>>>>>>>>>>>'qName'
>>>>>>>>>>>in
>>>>>>>>>>>the class metadata (where currently only the interfaces - if any
>>>>>>>>>>>-
>>>>>>>>>>>live) and adopt the 'getValue' routines to search that instead of
>>>>>>>>>>>the
>>>>>>>>>>>entire namespace chain. This would get rid of the need for the
>>>>>>>>>>>dreaded
>>>>>>>>>>>'__proto__' as well...
>>>>>>>>>> Sounds good. We need to find the superclass somehow as well.
>>>>>>>>>
>>>>>>>>> Alex, can you please create a JIRA issue for this and assign it to
>>>>>>>>>me.
>>>>>>>>> I don't think I'll have time in the next few days to work on this,
>>>>>>>>>and
>>>>>>>>> I don't want any details to get lost in the avalanche of emails on
>>>>>>>>>the
>>>>>>>>> list.
>>>>>>>>>
>>>>>>>>> EdB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Alex Harui <ah...@adobe.com>.
Hopefully, although I grep'd and think I saw two places where there was
some cheating going on.
-Alex
On 11/15/13 10:27 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Or, since that has gone the way of the dodo, I can just feed it
>'this.FLEXJS_CLASS_INFO.names[0].name' ;-)
>
>EdB
>
>
>
>On Fri, Nov 15, 2013 at 7:12 PM, Alex Harui <ah...@adobe.com> wrote:
>> Looks like it should be ok to replace with getQualifiedClassName().
>>
>> -Alex
>>
>> On 11/15/13 9:56 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>>Is there a particular reason there is a 'className' property which is
>>>set on some, but not all classes and even has 'getter/setter' methods?
>>>
>>>Unless the property is seriously misnamed, why would you want to be
>>>able to SET a class' name? If anything is constant, it should be the
>>>name of the class, shouldn't it?
>>>
>>>It looks like a legacy thing. Would it be alright to remove it? The
>>>information is now available in the metadata.
>>>
>>>EdB
>>>
>>>
>>>
>>>On Fri, Nov 15, 2013 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> Awesome! Definitely looked like a lot of work. Thanks for doing it.
>>>>
>>>> -Alex
>>>>
>>>> On 11/15/13 8:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>>Big update: fixed!
>>>>>
>>>>>If you really want to know what needed to happen to make this work,
>>>>>please read the commit messages. It wasn't a simple fix.
>>>>>
>>>>>Note: the metadata property is now required on each class in the
>>>>>framework. I've added it to all the classes in the FlexJS framework
>>>>>that are under active development. Please read the source for
>>>>>examples, and I've added a small section to the wiki for reference:
>>>>>
>>>>>https://cwiki.apache.org/confluence/x/W5sTAg
>>>>>
>>>>>This was fun, but has taken way too much time, so I'll have to catch
>>>>>up on my regular work in the coming week(s) ;-)
>>>>>
>>>>>EdB
>>>>>
>>>>>
>>>>>
>>>>>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>wrote:
>>>>>> Ah, small update: a lot of the warnings remaining in 'strict' mode
>>>>>>are
>>>>>> for the classes the compiler misses... That at least combines the
>>>>>> issues, two birds with one stone and all ;-)
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>>wrote:
>>>>>>> This may be worse than we thought...
>>>>>>>
>>>>>>> When I fixed the storage and retrieval of the CSS properties, it
>>>>>>>still
>>>>>>> didn't work properly in release mode. Some classes are found and
>>>>>>> bound, others are not. Turns out that the Closure Compiler doesn't
>>>>>>> resolve all dependencies accurately, the classes it misses are
>>>>>>>never
>>>>>>> 'considered' during compilation :-(
>>>>>>>
>>>>>>> I will look into the custom dependency algorithm in the Publisher
>>>>>>> next. Wish me luck ;-)
>>>>>>>
>>>>>>> Also, the fix will literally affect all JS classes, so prepare for
>>>>>>> some interesting merges. If I find a solution, I'll publish it
>>>>>>>first
>>>>>>> in a branch, so we can look at it together before we "commit".
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>>>wrote:
>>>>>>>>>>One thought is that we might store both the 'name' and the
>>>>>>>>>>'qName'
>>>>>>>>>>in
>>>>>>>>>>the class metadata (where currently only the interfaces - if any
>>>>>>>>>>-
>>>>>>>>>>live) and adopt the 'getValue' routines to search that instead of
>>>>>>>>>>the
>>>>>>>>>>entire namespace chain. This would get rid of the need for the
>>>>>>>>>>dreaded
>>>>>>>>>>'__proto__' as well...
>>>>>>>>> Sounds good. We need to find the superclass somehow as well.
>>>>>>>>
>>>>>>>> Alex, can you please create a JIRA issue for this and assign it to
>>>>>>>>me.
>>>>>>>> I don't think I'll have time in the next few days to work on this,
>>>>>>>>and
>>>>>>>> I don't want any details to get lost in the avalanche of emails on
>>>>>>>>the
>>>>>>>> list.
>>>>>>>>
>>>>>>>> EdB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>
>>>
>>>
>>>
>>>--
>>>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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Or, since that has gone the way of the dodo, I can just feed it
'this.FLEXJS_CLASS_INFO.names[0].name' ;-)
EdB
On Fri, Nov 15, 2013 at 7:12 PM, Alex Harui <ah...@adobe.com> wrote:
> Looks like it should be ok to replace with getQualifiedClassName().
>
> -Alex
>
> On 11/15/13 9:56 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>Is there a particular reason there is a 'className' property which is
>>set on some, but not all classes and even has 'getter/setter' methods?
>>
>>Unless the property is seriously misnamed, why would you want to be
>>able to SET a class' name? If anything is constant, it should be the
>>name of the class, shouldn't it?
>>
>>It looks like a legacy thing. Would it be alright to remove it? The
>>information is now available in the metadata.
>>
>>EdB
>>
>>
>>
>>On Fri, Nov 15, 2013 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
>>> Awesome! Definitely looked like a lot of work. Thanks for doing it.
>>>
>>> -Alex
>>>
>>> On 11/15/13 8:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>>Big update: fixed!
>>>>
>>>>If you really want to know what needed to happen to make this work,
>>>>please read the commit messages. It wasn't a simple fix.
>>>>
>>>>Note: the metadata property is now required on each class in the
>>>>framework. I've added it to all the classes in the FlexJS framework
>>>>that are under active development. Please read the source for
>>>>examples, and I've added a small section to the wiki for reference:
>>>>
>>>>https://cwiki.apache.org/confluence/x/W5sTAg
>>>>
>>>>This was fun, but has taken way too much time, so I'll have to catch
>>>>up on my regular work in the coming week(s) ;-)
>>>>
>>>>EdB
>>>>
>>>>
>>>>
>>>>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>>wrote:
>>>>> Ah, small update: a lot of the warnings remaining in 'strict' mode are
>>>>> for the classes the compiler misses... That at least combines the
>>>>> issues, two birds with one stone and all ;-)
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>wrote:
>>>>>> This may be worse than we thought...
>>>>>>
>>>>>> When I fixed the storage and retrieval of the CSS properties, it
>>>>>>still
>>>>>> didn't work properly in release mode. Some classes are found and
>>>>>> bound, others are not. Turns out that the Closure Compiler doesn't
>>>>>> resolve all dependencies accurately, the classes it misses are never
>>>>>> 'considered' during compilation :-(
>>>>>>
>>>>>> I will look into the custom dependency algorithm in the Publisher
>>>>>> next. Wish me luck ;-)
>>>>>>
>>>>>> Also, the fix will literally affect all JS classes, so prepare for
>>>>>> some interesting merges. If I find a solution, I'll publish it first
>>>>>> in a branch, so we can look at it together before we "commit".
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>>wrote:
>>>>>>>>>One thought is that we might store both the 'name' and the 'qName'
>>>>>>>>>in
>>>>>>>>>the class metadata (where currently only the interfaces - if any -
>>>>>>>>>live) and adopt the 'getValue' routines to search that instead of
>>>>>>>>>the
>>>>>>>>>entire namespace chain. This would get rid of the need for the
>>>>>>>>>dreaded
>>>>>>>>>'__proto__' as well...
>>>>>>>> Sounds good. We need to find the superclass somehow as well.
>>>>>>>
>>>>>>> Alex, can you please create a JIRA issue for this and assign it to
>>>>>>>me.
>>>>>>> I don't think I'll have time in the next few days to work on this,
>>>>>>>and
>>>>>>> I don't want any details to get lost in the avalanche of emails on
>>>>>>>the
>>>>>>> list.
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>
>>
>>
>>
>>--
>>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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Alex Harui <ah...@adobe.com>.
Looks like it should be ok to replace with getQualifiedClassName().
-Alex
On 11/15/13 9:56 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Is there a particular reason there is a 'className' property which is
>set on some, but not all classes and even has 'getter/setter' methods?
>
>Unless the property is seriously misnamed, why would you want to be
>able to SET a class' name? If anything is constant, it should be the
>name of the class, shouldn't it?
>
>It looks like a legacy thing. Would it be alright to remove it? The
>information is now available in the metadata.
>
>EdB
>
>
>
>On Fri, Nov 15, 2013 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
>> Awesome! Definitely looked like a lot of work. Thanks for doing it.
>>
>> -Alex
>>
>> On 11/15/13 8:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>>Big update: fixed!
>>>
>>>If you really want to know what needed to happen to make this work,
>>>please read the commit messages. It wasn't a simple fix.
>>>
>>>Note: the metadata property is now required on each class in the
>>>framework. I've added it to all the classes in the FlexJS framework
>>>that are under active development. Please read the source for
>>>examples, and I've added a small section to the wiki for reference:
>>>
>>>https://cwiki.apache.org/confluence/x/W5sTAg
>>>
>>>This was fun, but has taken way too much time, so I'll have to catch
>>>up on my regular work in the coming week(s) ;-)
>>>
>>>EdB
>>>
>>>
>>>
>>>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>wrote:
>>>> Ah, small update: a lot of the warnings remaining in 'strict' mode are
>>>> for the classes the compiler misses... That at least combines the
>>>> issues, two birds with one stone and all ;-)
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>wrote:
>>>>> This may be worse than we thought...
>>>>>
>>>>> When I fixed the storage and retrieval of the CSS properties, it
>>>>>still
>>>>> didn't work properly in release mode. Some classes are found and
>>>>> bound, others are not. Turns out that the Closure Compiler doesn't
>>>>> resolve all dependencies accurately, the classes it misses are never
>>>>> 'considered' during compilation :-(
>>>>>
>>>>> I will look into the custom dependency algorithm in the Publisher
>>>>> next. Wish me luck ;-)
>>>>>
>>>>> Also, the fix will literally affect all JS classes, so prepare for
>>>>> some interesting merges. If I find a solution, I'll publish it first
>>>>> in a branch, so we can look at it together before we "commit".
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>wrote:
>>>>>>>>One thought is that we might store both the 'name' and the 'qName'
>>>>>>>>in
>>>>>>>>the class metadata (where currently only the interfaces - if any -
>>>>>>>>live) and adopt the 'getValue' routines to search that instead of
>>>>>>>>the
>>>>>>>>entire namespace chain. This would get rid of the need for the
>>>>>>>>dreaded
>>>>>>>>'__proto__' as well...
>>>>>>> Sounds good. We need to find the superclass somehow as well.
>>>>>>
>>>>>> Alex, can you please create a JIRA issue for this and assign it to
>>>>>>me.
>>>>>> I don't think I'll have time in the next few days to work on this,
>>>>>>and
>>>>>> I don't want any details to get lost in the avalanche of emails on
>>>>>>the
>>>>>> list.
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Is there a particular reason there is a 'className' property which is
set on some, but not all classes and even has 'getter/setter' methods?
Unless the property is seriously misnamed, why would you want to be
able to SET a class' name? If anything is constant, it should be the
name of the class, shouldn't it?
It looks like a legacy thing. Would it be alright to remove it? The
information is now available in the metadata.
EdB
On Fri, Nov 15, 2013 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
> Awesome! Definitely looked like a lot of work. Thanks for doing it.
>
> -Alex
>
> On 11/15/13 8:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>Big update: fixed!
>>
>>If you really want to know what needed to happen to make this work,
>>please read the commit messages. It wasn't a simple fix.
>>
>>Note: the metadata property is now required on each class in the
>>framework. I've added it to all the classes in the FlexJS framework
>>that are under active development. Please read the source for
>>examples, and I've added a small section to the wiki for reference:
>>
>>https://cwiki.apache.org/confluence/x/W5sTAg
>>
>>This was fun, but has taken way too much time, so I'll have to catch
>>up on my regular work in the coming week(s) ;-)
>>
>>EdB
>>
>>
>>
>>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>> Ah, small update: a lot of the warnings remaining in 'strict' mode are
>>> for the classes the compiler misses... That at least combines the
>>> issues, two birds with one stone and all ;-)
>>>
>>> EdB
>>>
>>>
>>>
>>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>wrote:
>>>> This may be worse than we thought...
>>>>
>>>> When I fixed the storage and retrieval of the CSS properties, it still
>>>> didn't work properly in release mode. Some classes are found and
>>>> bound, others are not. Turns out that the Closure Compiler doesn't
>>>> resolve all dependencies accurately, the classes it misses are never
>>>> 'considered' during compilation :-(
>>>>
>>>> I will look into the custom dependency algorithm in the Publisher
>>>> next. Wish me luck ;-)
>>>>
>>>> Also, the fix will literally affect all JS classes, so prepare for
>>>> some interesting merges. If I find a solution, I'll publish it first
>>>> in a branch, so we can look at it together before we "commit".
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>wrote:
>>>>>>>One thought is that we might store both the 'name' and the 'qName' in
>>>>>>>the class metadata (where currently only the interfaces - if any -
>>>>>>>live) and adopt the 'getValue' routines to search that instead of the
>>>>>>>entire namespace chain. This would get rid of the need for the
>>>>>>>dreaded
>>>>>>>'__proto__' as well...
>>>>>> Sounds good. We need to find the superclass somehow as well.
>>>>>
>>>>> Alex, can you please create a JIRA issue for this and assign it to me.
>>>>> I don't think I'll have time in the next few days to work on this, and
>>>>> I don't want any details to get lost in the avalanche of emails on the
>>>>> list.
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Alex Harui <ah...@adobe.com>.
Awesome! Definitely looked like a lot of work. Thanks for doing it.
-Alex
On 11/15/13 8:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Big update: fixed!
>
>If you really want to know what needed to happen to make this work,
>please read the commit messages. It wasn't a simple fix.
>
>Note: the metadata property is now required on each class in the
>framework. I've added it to all the classes in the FlexJS framework
>that are under active development. Please read the source for
>examples, and I've added a small section to the wiki for reference:
>
>https://cwiki.apache.org/confluence/x/W5sTAg
>
>This was fun, but has taken way too much time, so I'll have to catch
>up on my regular work in the coming week(s) ;-)
>
>EdB
>
>
>
>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> Ah, small update: a lot of the warnings remaining in 'strict' mode are
>> for the classes the compiler misses... That at least combines the
>> issues, two birds with one stone and all ;-)
>>
>> EdB
>>
>>
>>
>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl>
>>wrote:
>>> This may be worse than we thought...
>>>
>>> When I fixed the storage and retrieval of the CSS properties, it still
>>> didn't work properly in release mode. Some classes are found and
>>> bound, others are not. Turns out that the Closure Compiler doesn't
>>> resolve all dependencies accurately, the classes it misses are never
>>> 'considered' during compilation :-(
>>>
>>> I will look into the custom dependency algorithm in the Publisher
>>> next. Wish me luck ;-)
>>>
>>> Also, the fix will literally affect all JS classes, so prepare for
>>> some interesting merges. If I find a solution, I'll publish it first
>>> in a branch, so we can look at it together before we "commit".
>>>
>>> EdB
>>>
>>>
>>>
>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>wrote:
>>>>>>One thought is that we might store both the 'name' and the 'qName' in
>>>>>>the class metadata (where currently only the interfaces - if any -
>>>>>>live) and adopt the 'getValue' routines to search that instead of the
>>>>>>entire namespace chain. This would get rid of the need for the
>>>>>>dreaded
>>>>>>'__proto__' as well...
>>>>> Sounds good. We need to find the superclass somehow as well.
>>>>
>>>> Alex, can you please create a JIRA issue for this and assign it to me.
>>>> I don't think I'll have time in the next few days to work on this, and
>>>> I don't want any details to get lost in the avalanche of emails on the
>>>> list.
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> --
>>>> 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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Big update: fixed!
If you really want to know what needed to happen to make this work,
please read the commit messages. It wasn't a simple fix.
Note: the metadata property is now required on each class in the
framework. I've added it to all the classes in the FlexJS framework
that are under active development. Please read the source for
examples, and I've added a small section to the wiki for reference:
https://cwiki.apache.org/confluence/x/W5sTAg
This was fun, but has taken way too much time, so I'll have to catch
up on my regular work in the coming week(s) ;-)
EdB
On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Ah, small update: a lot of the warnings remaining in 'strict' mode are
> for the classes the compiler misses... That at least combines the
> issues, two birds with one stone and all ;-)
>
> EdB
>
>
>
> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> This may be worse than we thought...
>>
>> When I fixed the storage and retrieval of the CSS properties, it still
>> didn't work properly in release mode. Some classes are found and
>> bound, others are not. Turns out that the Closure Compiler doesn't
>> resolve all dependencies accurately, the classes it misses are never
>> 'considered' during compilation :-(
>>
>> I will look into the custom dependency algorithm in the Publisher
>> next. Wish me luck ;-)
>>
>> Also, the fix will literally affect all JS classes, so prepare for
>> some interesting merges. If I find a solution, I'll publish it first
>> in a branch, so we can look at it together before we "commit".
>>
>> EdB
>>
>>
>>
>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>>One thought is that we might store both the 'name' and the 'qName' in
>>>>>the class metadata (where currently only the interfaces - if any -
>>>>>live) and adopt the 'getValue' routines to search that instead of the
>>>>>entire namespace chain. This would get rid of the need for the dreaded
>>>>>'__proto__' as well...
>>>> Sounds good. We need to find the superclass somehow as well.
>>>
>>> Alex, can you please create a JIRA issue for this and assign it to me.
>>> I don't think I'll have time in the next few days to work on this, and
>>> I don't want any details to get lost in the avalanche of emails on the
>>> list.
>>>
>>> EdB
>>>
>>>
>>>
>>> --
>>> 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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ah, small update: a lot of the warnings remaining in 'strict' mode are
for the classes the compiler misses... That at least combines the
issues, two birds with one stone and all ;-)
EdB
On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> This may be worse than we thought...
>
> When I fixed the storage and retrieval of the CSS properties, it still
> didn't work properly in release mode. Some classes are found and
> bound, others are not. Turns out that the Closure Compiler doesn't
> resolve all dependencies accurately, the classes it misses are never
> 'considered' during compilation :-(
>
> I will look into the custom dependency algorithm in the Publisher
> next. Wish me luck ;-)
>
> Also, the fix will literally affect all JS classes, so prepare for
> some interesting merges. If I find a solution, I'll publish it first
> in a branch, so we can look at it together before we "commit".
>
> EdB
>
>
>
> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>One thought is that we might store both the 'name' and the 'qName' in
>>>>the class metadata (where currently only the interfaces - if any -
>>>>live) and adopt the 'getValue' routines to search that instead of the
>>>>entire namespace chain. This would get rid of the need for the dreaded
>>>>'__proto__' as well...
>>> Sounds good. We need to find the superclass somehow as well.
>>
>> Alex, can you please create a JIRA issue for this and assign it to me.
>> I don't think I'll have time in the next few days to work on this, and
>> I don't want any details to get lost in the avalanche of emails on the
>> list.
>>
>> EdB
>>
>>
>>
>> --
>> 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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
This may be worse than we thought...
When I fixed the storage and retrieval of the CSS properties, it still
didn't work properly in release mode. Some classes are found and
bound, others are not. Turns out that the Closure Compiler doesn't
resolve all dependencies accurately, the classes it misses are never
'considered' during compilation :-(
I will look into the custom dependency algorithm in the Publisher
next. Wish me luck ;-)
Also, the fix will literally affect all JS classes, so prepare for
some interesting merges. If I find a solution, I'll publish it first
in a branch, so we can look at it together before we "commit".
EdB
On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>One thought is that we might store both the 'name' and the 'qName' in
>>>the class metadata (where currently only the interfaces - if any -
>>>live) and adopt the 'getValue' routines to search that instead of the
>>>entire namespace chain. This would get rid of the need for the dreaded
>>>'__proto__' as well...
>> Sounds good. We need to find the superclass somehow as well.
>
> Alex, can you please create a JIRA issue for this and assign it to me.
> I don't think I'll have time in the next few days to work on this, and
> I don't want any details to get lost in the avalanche of emails on the
> list.
>
> EdB
>
>
>
> --
> 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
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>>One thought is that we might store both the 'name' and the 'qName' in
>>the class metadata (where currently only the interfaces - if any -
>>live) and adopt the 'getValue' routines to search that instead of the
>>entire namespace chain. This would get rid of the need for the dreaded
>>'__proto__' as well...
> Sounds good. We need to find the superclass somehow as well.
Alex, can you please create a JIRA issue for this and assign it to me.
I don't think I'll have time in the next few days to work on this, and
I don't want any details to get lost in the avalanche of emails on the
list.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> That sounds like a good place to start. Ideally the test would be a
>> project we all work on, or a project we all extend and use as a
>> reference, next to our own projects.
> I have been thinking of creating a 'kitchen sink' app for FlexJS that would
> double as a public example as well. I am looking for areas to help out.
> If you all think that this is a good thing for me to be working on, let me
> know.
That sounds like an great idea! If we can make a 'demo' that looks
great and also doubles as a test case for us, we should be in good
shape to really show off the alpha version of FalconJx/FlexJS.
Thanks,
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Alex Harui <ah...@adobe.com>.
On 11/13/13 10:23 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Wed, Nov 13, 2013 at 10:16 AM, Erik de Bruin <er...@ixsoftware.nl>
>wrote:
>
>> That sounds like a good place to start. Ideally the test would be a
>> project we all work on, or a project we all extend and use as a
>> reference, next to our own projects.
>>
>> EdB
>>
>>
>I have been thinking of creating a 'kitchen sink' app for FlexJS that
>would
>double as a public example as well. I am looking for areas to help out.
>If you all think that this is a good thing for me to be working on, let me
>know.
Feel free to take it on. The BasicTests port is for checkintests and
won't be a good public example.
-Alex
Re: [FLEXJS] CSS value handling can't work in release code
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Nov 13, 2013 at 10:16 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> That sounds like a good place to start. Ideally the test would be a
> project we all work on, or a project we all extend and use as a
> reference, next to our own projects.
>
> EdB
>
>
I have been thinking of creating a 'kitchen sink' app for FlexJS that would
double as a public example as well. I am looking for areas to help out.
If you all think that this is a good thing for me to be working on, let me
know.
Thanks,
Om
>
>
> On Wed, Nov 13, 2013 at 7:06 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >
> > On 11/13/13 9:39 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >
> >>I'll look what I can come up with... but before we continue and this
> >>framework becomes too big too "easily" refactor, we really, really
> >>need to get some functional tests in place. Otherwise we'll all only
> >>look at our private little example projects and only notice we broke
> >>something when someone else check theirs...
> > Near the top of my list is a port of BasicTests to FlexJS. Is that the
> > kind of test you are thinking of?
> >
> > -Alex
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
That sounds like a good place to start. Ideally the test would be a
project we all work on, or a project we all extend and use as a
reference, next to our own projects.
EdB
On Wed, Nov 13, 2013 at 7:06 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/13/13 9:39 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>I'll look what I can come up with... but before we continue and this
>>framework becomes too big too "easily" refactor, we really, really
>>need to get some functional tests in place. Otherwise we'll all only
>>look at our private little example projects and only notice we broke
>>something when someone else check theirs...
> Near the top of my list is a port of BasicTests to FlexJS. Is that the
> kind of test you are thinking of?
>
> -Alex
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Alex Harui <ah...@adobe.com>.
On 11/13/13 9:39 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>I'll look what I can come up with... but before we continue and this
>framework becomes too big too "easily" refactor, we really, really
>need to get some functional tests in place. Otherwise we'll all only
>look at our private little example projects and only notice we broke
>something when someone else check theirs...
Near the top of my list is a port of BasicTests to FlexJS. Is that the
kind of test you are thinking of?
-Alex
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I'll look what I can come up with... but before we continue and this
framework becomes too big too "easily" refactor, we really, really
need to get some functional tests in place. Otherwise we'll all only
look at our private little example projects and only notice we broke
something when someone else check theirs...
EdB
On Wed, Nov 13, 2013 at 6:28 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/13/13 8:25 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>One thought is that we might store both the 'name' and the 'qName' in
>>the class metadata (where currently only the interfaces - if any -
>>live) and adopt the 'getValue' routines to search that instead of the
>>entire namespace chain. This would get rid of the need for the dreaded
>>'__proto__' as well...
> Sounds good. We need to find the superclass somehow as well.
>>>
>>> For future reference: don't debug FlexJS with the debug code, rather
>>> use the release code and the source map. That way you won't be too
>>> committed to a certain approach before someone notices if likely won't
>>> work as advertised.
> DataBindingTest is working so I guess it didn't have any dependencies on
> that code. I hadn't tried DataGridExample in release mode.
> I only debug use sourcemaps when release mode doesn't run but debug mode
> does. Debugging with source maps is still quite inefficient for me
> compared to debugging in debug mode.
>
> -Alex
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Alex Harui <ah...@adobe.com>.
On 11/13/13 8:25 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>One thought is that we might store both the 'name' and the 'qName' in
>the class metadata (where currently only the interfaces - if any -
>live) and adopt the 'getValue' routines to search that instead of the
>entire namespace chain. This would get rid of the need for the dreaded
>'__proto__' as well...
Sounds good. We need to find the superclass somehow as well.
>>
>> For future reference: don't debug FlexJS with the debug code, rather
>> use the release code and the source map. That way you won't be too
>> committed to a certain approach before someone notices if likely won't
>> work as advertised.
DataBindingTest is working so I guess it didn't have any dependencies on
that code. I hadn't tried DataGridExample in release mode.
I only debug use sourcemaps when release mode doesn't run but debug mode
does. Debugging with source maps is still quite inefficient for me
compared to debugging in debug mode.
-Alex
Re: [FLEXJS] CSS value handling can't work in release code
Posted by Erik de Bruin <er...@ixsoftware.nl>.
One thought is that we might store both the 'name' and the 'qName' in
the class metadata (where currently only the interfaces - if any -
live) and adopt the 'getValue' routines to search that instead of the
entire namespace chain. This would get rid of the need for the dreaded
'__proto__' as well...
Thoughts?
EdB
On Wed, Nov 13, 2013 at 4:47 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Hi,
>
> Alex, I hope I'm wrong, but...
>
> I was looking at the DataGridExample example and I couldn't get it to
> run from the release code. It runs fine from the debug code, just not
> the release code. I did a lot of digging and stepping through the code
> until I finally hit the 'init' method on the SimpleCSSValueImpl class.
> This stores the namespace string from the CSS property in the
> subsequent namespace objects in JS, if I understand the code
> correctly. This works fine in debug mode, where all the namespaces
> live unaltered in the window object.
>
> In release mode, however, things work differently. The Closure
> Compiler minifies the code, so the namespace
> 'org.apache.flex.core.UIBase' will get renamed to 'ae' (or something).
> This causes the 'getQualifiedClassName' methods to fail, as it will
> try to recreate 'org.apache.flex.core.UIBase' from something that has
> been optimised into nothing...
>
> I'm looking for a solution, but I don't think there is going to be a simple one.
>
> For future reference: don't debug FlexJS with the debug code, rather
> use the release code and the source map. That way you won't be too
> committed to a certain approach before someone notices if likely won't
> work as advertised.
>
> Thanks,
>
> EdB
>
>
>
> --
> 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