incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <cfram...@adobe.com>
Subject Re: s:Spacer (was Re: Missing Spark components)
Date Thu, 01 Mar 2012 23:28:46 GMT
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
View raw message