From flex-dev-return-5991-apmail-incubator-flex-dev-archive=incubator.apache.org@incubator.apache.org  Fri Mar  2 09:42:38 2012
Return-Path: <flex-dev-return-5991-apmail-incubator-flex-dev-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E59DE9E57
	for <apmail-incubator-flex-dev-archive@minotaur.apache.org>; Fri,  2 Mar 2012 09:42:38 +0000 (UTC)
Received: (qmail 97017 invoked by uid 500); 2 Mar 2012 09:42:37 -0000
Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org
Received: (qmail 96905 invoked by uid 500); 2 Mar 2012 09:42:37 -0000
Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:flex-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:flex-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:flex-dev@incubator.apache.org>
List-Id: <flex-dev.incubator.apache.org>
Reply-To: flex-dev@incubator.apache.org
Delivered-To: mailing list flex-dev@incubator.apache.org
Received: (qmail 96889 invoked by uid 99); 2 Mar 2012 09:42:36 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 09:42:36 +0000
X-ASF-Spam-Status: No, hits=0.8 required=5.0
	tests=FH_FROMEML_NOTLD,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [64.13.192.21] (HELO cl12.gs01.gridserver.com) (64.13.192.21)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 09:42:30 +0000
Received: from cpc2-dals8-0-0-cust400.hari.cable.virginmedia.com ([77.101.169.145]:34236 helo=[10.0.1.3])
	by cl12.gs01.gridserver.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16)
	(Exim 4.69)
	(envelope-from <flex@tink.ws>)
	id 1S3P05-0005Gu-CM
	for flex-dev@incubator.apache.org; Fri, 02 Mar 2012 01:42:10 -0800
Message-Id: <3870D9A3-C95C-441E-8F12-C68FA5249A36@tink.ws>
From: Tink <flex@tink.ws >
To: flex-dev@incubator.apache.org
In-Reply-To: <CAEFz_vtMDVC84oNE=SQON7+NJ1v70V8yhu8cgdLA5HydbZqdVA@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Missing Spark Components List
Date: Fri, 2 Mar 2012 09:42:06 +0000
References: <CAEFz_vuFcYXgJzPsHn1Ka+S+Tmdqc9b0JY8+65DWgCimco-n4g@mail.gmail.com> <CAAd0WrbBwCL0JOhRqxB0J9aKtiXSi-GuB+AX35Q+8x2n7Fk=Nw@mail.gmail.com> <CAEFz_vtMDVC84oNE=SQON7+NJ1v70V8yhu8cgdLA5HydbZqdVA@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
X-Authenticated-User: 2993 flex@tink.ws
X-Spam-Level: 
X-Virus-Checked: Checked by ClamAV on apache.org
X-Old-Spam-Status: "score=-1.4 tests=ALL_TRUSTED version=3.1.7"

I'm with Jonathan on this

I pushed for Adobe to remove HGroup and VGroup before the release of  
spark as I saw these as absolutely pointless.

In spark we should use a container or data control and then add the  
required layout. There is no need to bake in layouts and expose their  
properties to the component, just pointless. Too late to removed  
HGroup and VGroup now, but please lets not add any more classes like  
this. It dums down what you can achieve with spark.

Tink



On 1 Mar 2012, at 17:35, Omar Gonzalez wrote:

> On Thu, Mar 1, 2012 at 7:34 AM, Jonathan Campos  
> <jonbcampos@gmail.com>wrote:
>
>> On Thu, Mar 1, 2012 at 2:13 AM, Omar Gonzalez <omarg.developer@gmail.com
>>> wrote:
>>
>>> I've added a page to the wiki to keep track of the current  
>>> inventory of
>> MX
>>> components, their Spark counterparts, and whether they are currently
>>> missing.
>>>
>>
>> I don't want to just go editing your work without some discussion,  
>> so I'm
>> throwing the discussion here. There are some components that I  
>> don't see
>> the need to be "spark'ed" nor do I consider them missing.  
>> Specifically:
>>
>> Grid (group + tilelayout)
>>
> I disagree here. We should have the convenience class, it makes things
> easier to find and illustrates proper use of the framework and its  
> layout
> objects.
>
> Also writing:
>
> <s:TileGroup>
> </s:TileGroup>
>
> Is a lot less verbose than:
> <s:Group>
>    <s:layout>
>        <s:TileLayout />
>    </s:layout>
> </s:Group>
>
> Plus it falls in line with the other convenience classes such as
> <s:HGroup/> and <s:VGroup/> and it helps with migration for people  
> that
> will immediately look to replace some MX layouts.
>
>
>
>
>> LinkBar (button bar + skin) <- new skin could be made easily
>> LinkButton (button + skin) <- new skin could be made easily
>>
>
> Again, while creating skins that mimic LinkButton and LinkBar I  
> still see
> that convenience classes can help here. Instead of subclassing  
> s:Button,
> writing a custom skin class, adding a click listener and writing up a
> navigateToUrl() this call all be conveniently wrapped into a  
> component u
> can use like this:
>
> <s:LinkButton href="http://www.site.com/" target="_blank />
>
> That is far more convenient and less code to write for a simple link  
> and
> again helps to mitigate the migration path.
>
>
>
>
>> PopupButton (calloutbutton) <- needs to be generalized from just  
>> mobile
>> specific
>>
>
> Agreed on this one.
>
>
>> Spacer (mx:spacer or rect)
>>
> My pet peeve here is having to still use the mx namespace. I wouldn't
> really care if the s:Spacer was line for line identical to  
> mx:Spacer, its
> just the lack of consistency that really drives me up the wall. Also,
> couldn't we just use s:Rect and again make a convenience class just  
> to keep
> the LoC shorter?
>
>
>
>
>> TileList (9as already posted list+tilelayout)
>>
> Again, this class would be a convenience class and would help mitigate
> migration path from MX to Spark. It also falls in line with other
> convenience classes such as s:HGroup and s:VGroup.
>
> I'd prefer to have:
> <s:TileList />
>
> than
>
> <s:List>
>    <s:layout>
>        <s:TileLayout />
>    <s:/layout>
> </s:List>
>
>
>
>
>> ToggleButtonBar (buttonbar + skin) <- new skin could be made easily
>>
> ToggleButton !== Button, I think another component is needed here  
> no? Or
> does s:ButtonBar have some properties that allow it to behave like a
> ToggleButtonBar?
>
>
>
>> VRule and HRule (rect)
>>
>
> Again, a convenience class to help with migration. This could very  
> well
> subclass s:Rect and just provide convenience setters to its styling
> properties
>
>
>> All Charting (they are already very spark-ish)
>
> I'm not sure on which way to go with these. They are definitely not
> Spark-ish as they do not follow the Spark skinning model at all.  
> However
> they have been deemed as performant enough by Adobe that they've  
> openly
> said they're ok to work in mobile environments. I just think we  
> should at
> least look at how the charting components can be improved in their  
> skinning
> to be more inline with the Spark skinning model.
>
>
>
>>
>> While I get the intention I think that to go down this path will  
>> cause
>> confusion and also reduce people's abilities to see new features and
>> functionality (specifically in the case of TileList, HRule/VRule,
>> LinkButton... well all of them).
>>
>> I would think that these can just be marked as resolved and ended.
>>
>
> I think the convenience classes are important as they both provide a
> cleaner migration path while at the same time help to illustrate the  
> use of
> core features of the framework, such as layouts.
>
>
>>
>> With charting I could agree that there could be an update to make  
>> skinning
>> them simpler but I have done many custom skins already with these
>> components.
>
> --
>> Jonathan Campos
>>
>
>
> I agree its possible to customize the skins of these components. I  
> just
> find it flawed that if we keep these MX charting components then  
> there are
> two skinning approaches that have to be taken, and that's just not  
> nice. We
> should try to Spark-ify the skinning model in the charting components.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
> Apache Flex PPMC Member