flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cortlandt Winters <c...@cortwinters.net>
Subject Re: s:Spacer (was Re: Missing Spark components)
Date Thu, 01 Mar 2012 18:59:41 GMT
I'd say that this depends on workflow.

If you have a photoshop composite that you know you are going to stick to
like glue then you want to use the minimaly weighted set of components
necessary to make it look that way and get the potential performance gains.

But if you expect a lot of design changes based on client feedback and
multiple iterations, it's much nicer to have the fully skinable and
customizable ones like the mx components where there is a lot of built in
flexibility to quickly modify things based on client feedback.

Space is a perfect example. Space is seldom just space. It often can have a
color or texture and a very elegant ui may have subtle animated transitions
in the spaces to lead the viewers eye.

Unless you really know that that space is really just blank space the
argument could be made that having a visual characteristic that you can't
easily style or change is premature optimization.

I'd say that flex has two really good niches, even in the browser world for
years to come. Data heavy apps that utilize remoting performance and
Visually heavy apps that pay the utmost attention to every 10 pixels of

I think that a good goal would be to use the spark architecture to focus on
super performant minimally heavy components for data heavy apps and for
mobile apps with minimal skins, then to have a layer of optional skins that
emulate the mx functionality for the visually rich applications.

This kind of setup would also allow a company with a current mx based app
to first move to the spark architecture more easily and then strip out the
mx simulator skins and replace them with mobile skins to repurpose their
apps for tablets.

On Thu, Mar 1, 2012 at 10:47 AM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:

> >I agree the name could be misleading, could benamed SkiinnableSeparator
> but this is another component and could be contributed by interested
> developers.
> Or, in the Flex 4 model, you can but an empty rectangle in the 'space'
> that you need. It doesn't carry the weight of a whole component and is much
> more performant. I wouldn’t object if you wanted to have a graphical
> element which just was used for spacing. It's not ideal in my opinion but I
> get the reason. Having a whole component with all of that overhead and a
> lifecycle just to space something out though is really wasteful

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message