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 remi
popup.className = 'popup' and this.titleLabel.element.className =
'TitleBarLabel'?
EdB
On Fri, Nov 15, 2013 at 7:33 PM, Alex Harui 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" wro
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" 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
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 wrote:
> Looks like it should be ok to replace with getQualifiedClassName().
>
> -Alex
>
> On 11/15/13 9:56 AM, "Erik de Bruin" wrote:
>
>
Looks like it should be ok to replace with getQualifiedClassName().
-Alex
On 11/15/13 9:56 AM, "Erik de Bruin" 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 seriousl
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, s
Awesome! Definitely looked like a lot of work. Thanks for doing it.
-Alex
On 11/15/13 8:24 AM, "Erik de Bruin" 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 prop
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 activ
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 wrote:
> This may be worse than we thought...
>
> When I fix
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
>>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__'
>> 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
On 11/13/13 10:23 AM, "OmPrakash Muppirala" wrote:
>On Wed, Nov 13, 2013 at 10:16 AM, Erik de Bruin
>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.
>>
>>
On Wed, Nov 13, 2013 at 10:16 AM, Erik de Bruin 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 f
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 wrote:
>
>
> On 11/13/13 9:39 AM, "Erik de Bruin" wrote:
>
>>I'll look what
On 11/13/13 9:39 AM, "Erik de Bruin" 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 project
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 el
On 11/13/13 8:25 AM, "Erik de Bruin" 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 r
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.
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 Simple
20 matches
Mail list logo
