On 10/30/16, 9:12 AM, "Christofer Dutz" wrote:
>Hi Carlos,
>
>right now you can try it by switching the branch. I didn’t want to merge
>it back to develop untill I get some confirmation from the Ant fraction
>that it doesn’t break anything on their side.
I built the branch. The build passed.
On 10/30/16, 2:34 PM, "yishayw" wrote:
>Well, changing the className does actually change the DOM class in
>runtime,
>so it seems a bit arbitrary that that's reflected in DOM while changing
>style is not. Right now, I'm using this bug(?) as a way to make run-time
>style changes.
AFAICT, "cl
Well, there can be other IValuesImpl other than SimpleCSSValuesImpl and
those other implementations may not have a perInstanceStyles property, so
I don't know that we should add perInstanceStyles to IValuesImpl.
If we don't, you will have to know that the IValuesImpl is a
SimpleCSSValuesImpl, so I
A tutorial on this would be nice. I completely agree that the setup was a
pain, and that the work being done on maven is valuable, but now that the
setup is done I'm quite comfortable with ant.
So I was just wondering if my current workflow would somehow be enhanced if
I make the switch.
--
Vi
Well, changing the className does actually change the DOM class in runtime,
so it seems a bit arbitrary that that's reflected in DOM while changing
style is not. Right now, I'm using this bug(?) as a way to make run-time
style changes.
I don't really use binding that much but it's good to know
I’ll explain the scenario to make it more clear.
I wanted to add a new CSS property (overflow) which was not included in
SimpleCSSValueImpl. I noticed that valid CSS properties were specified in
SimpleCSSValuesImpl.perInstanceStyles. I suppose I could have done
Hi Yishay, I recommend you to go Maven, for various reasons. Once maven is
setup is so far more easy than ANT (the difficult part was what Chris did
preparing all this project to build with maven. The other thing is, we want
maven to be the main way to build this project. Maybe you could end with
s
Sounds great. I’m still using ANT but I’ve got some slight bottlenecks. The
main ones I’ve noticed are building core which can take around a minute, and
building the app from FlashBuilder, which can also take a long time (depends on
the app). If I make the switch to Maven, will I be able to impr
Just confirm that MDLExample now builds in 8 secs first time and 3'6
second. Awesome! :)
2016-10-30 17:16 GMT+01:00 Carlos Rovira :
> Ok Chris, I was just figuring it, thanks to confirm.
> Just notice that maybe It would be ok to rebase it on top of develop to
> get latest changes? (just figurin
Ok Chris, I was just figuring it, thanks to confirm.
Just notice that maybe It would be ok to rebase it on top of develop to get
latest changes? (just figuring)
thanks!
2016-10-30 17:12 GMT+01:00 Christofer Dutz :
> Hi Carlos,
>
> right now you can try it by switching the branch. I didn’t want to
Hi Carlos,
right now you can try it by switching the branch. I didn’t want to merge it
back to develop untill I get some confirmation from the Ant fraction that it
doesn’t break anything on their side.
One thing I noticed at the moment is that I can’t seem to be able to run the
release compilat
O_o
Awesome Chris!
Can't wait to try it! :)
2016-10-29 22:11 GMT+02:00 Josh Tynjala :
> Nice. Good work, Chris!
>
> - Josh
>
> On Oct 29, 2016 12:37 PM, "Christofer Dutz"
> wrote:
>
> > Hi,
> >
> > the last few days I invested quite some time in optimizing the
> compilation
> > for Maven.
> >
>
fingers crossed! :)
2016-10-28 17:33 GMT+02:00 Christofer Dutz :
> Hi,
>
>
> I just added a new branch "feature-autobuild/closure-classpath-sources"
> in which I am planning on refactoring the way we pass in sources to the
> closure compiler. Currently a lot of time is wasted by dumping the closu
I have a need for inflate and deflate (multiple needs actually).
There’s a number of javascript libraries which do this already. Probably the
most widely accepted one is pako[1]. Pako is robust, but its size is not
insignificant (45KB for inflate and deflate 27KB for deflate and 22KB for
inflat
On 10/30/16, 4:23 AM, "yishayw" wrote:
>Is there a reason why SimpleCSSValuesImpl.perInstanceStyles is static? It
>makes extending SimpleCSSValuesImpl difficult. Since there's typically
>just
>one such instance per app is there any harm in making it a dynamic
>property.
>That will allow derived
On 10/30/16, 4:01 AM, "yishayw" wrote:
>I noticed UIBase set style doesn't apply the new style to the HTML element
>while set className does. Is that on purpose?
>
Yes. Under pay-as-you-go, there is cost to supporting changing styles at
runtime, so the default implementation assumes no styles
Is there a reason why SimpleCSSValuesImpl.perInstanceStyles is static? It
makes extending SimpleCSSValuesImpl difficult. Since there's typically just
one such instance per app is there any harm in making it a dynamic property.
That will allow derived classes to simply push new values upon construct
I noticed UIBase set style doesn't apply the new style to the HTML element
while set className does. Is that on purpose?
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-Applying-styles-tp56104.html
Sent from the Apache Flex Development mailing list a
18 matches
Mail list logo
