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 <[email protected]> wrote: > Awesome! Definitely looked like a lot of work. Thanks for doing it. > > -Alex > > On 11/15/13 8:24 AM, "Erik de Bruin" <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>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 <[email protected]> >>>>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
