incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Frishberg <fri...@gmail.com>
Subject Re: s:Spacer (was Re: Missing Spark components)
Date Thu, 01 Mar 2012 23:38:32 GMT
Thanks for (re)pointing that out Carol.  Looks like it was done with
http://bugs.adobe.com/jira/browse/SDK-28369

-Ryan

On Thu, Mar 1, 2012 at 11:28 PM, Carol Frampton <cframpto@adobe.com> wrote:

> Someone said this several messages back but I don't think everybody saw
> that since people are talking about when there is a s:Spacer.
>
> There is an entry in the spark manifest that points to mx:Spacer so
> s:Spacer is mx:Spacer.
>
> It has already shipped so you can't/shouldn't turn it into something else.
>
> Carol
>
>
> On 3/1/12 6 :05PM, "Om" <bigosmallm@gmail.com> wrote:
>
> >On Thu, Mar 1, 2012 at 2:05 PM, Michael A. Labriola <
> >labriola@digitalprimates.net> wrote:
> >
> >> >See, I have a problem with this.  Why would we not want to do that?
> >>The
> >> ideal scenario is keep the interface same/similar but support
> >>everything.
> >> >Internally, we can do things efficiently.
> >>
> >> That assumes that the way it did work was ideal or even good in some
> >> cases. I have no desire to make transitions harder for people but you
> >>also
> >> don't want to couple all future development to the interface of the
> >>past.
> >> To me having to replicate every property for border and layout out to a
> >> component only to delegate it down to different pieces was a bad idea. I
> >> would hate to have to always support it because we once did.
> >>
> >
> >But mx is not the 'past' and spark is not the 'future'.  If it were the
> >past, mx components that have spark equivalents will not ship in the same
> >SDK version.  You cannot have two different sets of classes with the same
> >names but different behaviors.  This is a real problem with dev teams that
> >are trying to upgrade from Flex 3 to 4+ I am sure I am not the only one
> >that finds this mix-in highly confusing.  Either we kill mx:Spacer when we
> >introduce s:Spacer *or* we have both follow the same interface *or* we
> >name
> >them something different.
> >What is the message we are sending to users of the SDK when there is so
> >much inconsistency flying around?
> >
> >Maybe, I am completely off base here, but exactly what is the motivation
> >of
> >the spark component set?  Is it the new skinning paradigm, or is it better
> >performing versions of existing components or is it a completely different
> >set of components that happen to have similar names?  If this is a
> >separate
> >conversation, please reply in a new thread.
> >
> >Thanks,
> >Om
> >
> >
> >>
> >> Mike
> >>
> >>
>
>

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