RE: Web to Print solutions

I just realized what you meant by "scrolling renderers," and I can imagine that could get choppy. In my case, I only had to render once, and I could burry that one-time cost behind the "loading" delay for the page. -Original Message- From: Aaron Miller [mailto:amil

RE: Web to Print solutions

I actually had excellent performance in Android and iOS (only tested tablets) using TLF based text rendering. In fact performance is one of our selling points over competing products in our niche. I didn't even have any problems with scrolling (using a Scroller to scroll a parent container), bou

RE: Button question

Use the spark DropDownList. From: Brian Zaleski [br...@imprimissoft.com] Sent: Saturday, May 05, 2012 9:43 AM To: flex-dev@incubator.apache.org Subject: Re: Button ques

RE: Flex and names spaces in MXML

For what it's worth, I see nothing wrong with "excessive" use of names paces. I would actually argue this is a good thing. It makes the code more clear and concise in my opinion. I think it just comes down to a matter of preference, and probably has a lot to do with how Flex is used. Even for r

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> To me, that can't be true. If anything, while more verbose Spark > is infinitely friendlier to the little guy. In mx, as soon as > you wanted to do anything different, your only choice was to > hire a component developer to extend/copy/rewrite these classes. > Take for example a circular or carou

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Yeah, I get it now. The term describes a specific methodology, where I understood it to mean a general concept. Regardless, I still stand by my point. The way forward for Flex is in "providing" implementation details, rather than the more traditional approach of "sealing" them. Spark is a step

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Haha, yeah maybe you're right. I've always taken AOP as a loosely defined term (like OOP), to mean the "composition of objects with cross-cutting concerns," where DI would be a design pattern in which to achieve AOP. I didn't realize the term was specific to the methodology. I always use DI to c

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> One of the re-occurring discussions on this list has been the desire to break > down components into smaller parts. > > The spark architecture goes some way to achieving this. Take scrolling, if > you want it you wrap you group on a Scroller > and off you go. Same for layouts. In this way spar

RE: s:Spacer (was Re: Missing Spark components)

What about an extension to the framework (like TLF, OSMF, etc.), that provided additional "template" components and skins, the purpose of which would serve as a clear migration path for Halo based projects? This would allow projects to develop new functionality using Spark concepts, while preser