From flex-dev-return-5924-apmail-incubator-flex-dev-archive=incubator.apache.org@incubator.apache.org Thu Mar 1 17:58:51 2012 Return-Path: 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 5736D922C for ; Thu, 1 Mar 2012 17:58:51 +0000 (UTC) Received: (qmail 39434 invoked by uid 500); 1 Mar 2012 17:58:50 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 39406 invoked by uid 500); 1 Mar 2012 17:58:50 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 39397 invoked by uid 99); 1 Mar 2012 17:58:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Mar 2012 17:58:50 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of omarg.developer@gmail.com designates 74.125.82.175 as permitted sender) Received: from [74.125.82.175] (HELO mail-we0-f175.google.com) (74.125.82.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Mar 2012 17:58:45 +0000 Received: by wera1 with SMTP id a1so559498wer.6 for ; Thu, 01 Mar 2012 09:58:24 -0800 (PST) Received-SPF: pass (google.com: domain of omarg.developer@gmail.com designates 10.180.74.177 as permitted sender) client-ip=10.180.74.177; Authentication-Results: mr.google.com; spf=pass (google.com: domain of omarg.developer@gmail.com designates 10.180.74.177 as permitted sender) smtp.mail=omarg.developer@gmail.com; dkim=pass header.i=omarg.developer@gmail.com Received: from mr.google.com ([10.180.74.177]) by 10.180.74.177 with SMTP id u17mr13198919wiv.13.1330624704408 (num_hops = 1); Thu, 01 Mar 2012 09:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ui5l9eBLnIaZN3bAR8nklKVih3HNoV94S48C0Ea6ocg=; b=YirbP6uHIGlPpYQrBe0NLFEXQUKxELUL75Fzn3gEa9r1mrtzLPkD2KadXulLrh9g9h aJ/p0muwkdhWjLX+NeDRqHhtJ+R0AklbKSf8hkbYK2oNTDJFfj4uJDP00u1hB02ucjaO K92ffoQO207ht9akDuv/g2kJHfMtk1KY3BuHI= MIME-Version: 1.0 Received: by 10.180.74.177 with SMTP id u17mr10583789wiv.13.1330624704265; Thu, 01 Mar 2012 09:58:24 -0800 (PST) Received: by 10.180.95.137 with HTTP; Thu, 1 Mar 2012 09:58:24 -0800 (PST) In-Reply-To: References: Date: Thu, 1 Mar 2012 09:58:24 -0800 Message-ID: Subject: Re: s:Spacer (was Re: Missing Spark components) From: Omar Gonzalez To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=f46d0438900bd3bd7704ba3234b5 X-Virus-Checked: Checked by ClamAV on apache.org --f46d0438900bd3bd7704ba3234b5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 1, 2012 at 9:48 AM, Michael A. Labriola < labriola@digitalprimates.net> wrote: > > This is exactly why I feel we should have these. People first > > instinct, at least mine was, was to look for an equivalent. Subclassing > with convenience setters would go a long way toward reducing > frustrations people have had with migrating. Not everyone is immediately > aware of >all the skinning possibilities and new paradigms such as the > layout object so anything we can do to smooth out the migration is a plus. > Plus it illustrates proper use of some of the Spark concepts. Don't see how > its a bad thing. If >people really want to keep writing out a few lines for > a Rect as opposed to just writing then that's > their choice but I think we should have the class available so I'm going to > code one up today. > > Just my 2 cents. This all seems dangerous. Have a composed implementation > of each individual set of classes just gets us back to mx. > > Why set the width to 100% on a space, why not have or > then you don't need to set the properties at all? > Incidentally, I support that idea (honestly) if someone want to compose > objects in their own framework or project for their own use, but does the > SDK really need to have every combination of composition that's possible? > To me that is opposite of a small, tight SDK. > > Mike > I didn't put 100%, I put just 100, 100 pixels. :P But I get what you're saying, however, I still think that easing the migration path is a worthy endeavor. I'm not saying we need a class for every possible composition, that's ridiculous. But I think we can raise the barrier to entry for some MX users. You've stated several times many companies are still on MX, I've talked to many companies as well that have tried to do the migration from MX to Spark. The biggest pain point I commonly heard was the unclear path of migration for some of their components. Its not like based on the list I'm proposing for hundreds of new components, its but a small handful of convenience classes, some of which already exist such as s:HGroup and s:VGroup. -- Omar Gonzalez s9tpepper@apache.org Apache Flex PPMC Member --f46d0438900bd3bd7704ba3234b5--