From flex-dev-return-6278-apmail-incubator-flex-dev-archive=incubator.apache.org@incubator.apache.org Sun Mar 11 03:23:35 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 CCDF397B6 for ; Sun, 11 Mar 2012 03:23:34 +0000 (UTC) Received: (qmail 57457 invoked by uid 500); 11 Mar 2012 03:23:34 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 57114 invoked by uid 500); 11 Mar 2012 03:23:31 -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 57086 invoked by uid 99); 11 Mar 2012 03:23:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2012 03:23:30 +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 flexcapacitor@gmail.com designates 209.85.210.47 as permitted sender) Received: from [209.85.210.47] (HELO mail-pz0-f47.google.com) (209.85.210.47) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2012 03:23:24 +0000 Received: by dado14 with SMTP id o14so2735982dad.6 for ; Sat, 10 Mar 2012 19:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yTfsrrkyQzKc7JaIDaNOzy62vp+Az7QevMy2mAleIy0=; b=iiHJv+13E3KcpTkFc6tZhPKSKfvNrFfjhC6sXXU/HDFU823RHa2s6UWTHMIMSdVR8U 7Xcal5Pckn06sE0Fse7DLyBXoZj16e/9bYzfercv2Psx2zz4JsPfBVbofseFhsWZFpX7 8RNRNSK3HWKWHNMzqO5jnUBgeZ9fwpyy1wlKnWajlxkbwMkETuhuSDAJxKljwnmq5uLW J95KumTCBw1qK/7p/un2/8r3wugPJnvX4mszf81ptrVYhORzq+s0u72wZc8olPa4Hgoy DU8z9Jr9nmKAL7SDlKDn8oc+A4VugoeMspXBd+iReThoDYlAgU53+AzKLO8kq4+ecsw9 fYMA== MIME-Version: 1.0 Received: by 10.68.242.162 with SMTP id wr2mr4013182pbc.43.1331436183730; Sat, 10 Mar 2012 19:23:03 -0800 (PST) Received: by 10.68.230.1 with HTTP; Sat, 10 Mar 2012 19:23:03 -0800 (PST) In-Reply-To: <3870D9A3-C95C-441E-8F12-C68FA5249A36@tink.ws> References: <3870D9A3-C95C-441E-8F12-C68FA5249A36@tink.ws> Date: Sat, 10 Mar 2012 21:23:03 -0600 Message-ID: Subject: Re: Missing Spark Components List From: jude To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=047d7b339cc1c5b88a04baef2482 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b339cc1c5b88a04baef2482 Content-Type: text/plain; charset=ISO-8859-1 "I pushed for Adobe to remove HGroup and VGroup before the release of spark as I saw these as absolutely pointless" The point is to have the component type that you need ready for you when you need it. Don't re-invent the wheel every time. Some of these are easy to make *for us*. Things like VGroup and HGroup can be picked up rather quickly by new comers but much more and they can become complicated rather quickly and those making them can become frustrated and blame Flex for poor performance when it is their own code that is causing it (for example using bindings in Skinning). If we don't provide these components in the Apache project then that means that each developer, when they need that component, has to pause creating their application and take a detour to create the component. This is more hazardous if they don't have an intimate knowledge and understanding of the Spark and Flex component life cycle and / or the coding conventions and practices used in them. So instead of creating a few components of high quality once by an expert group of developers for 100's of thousands of developers at all levels we have 100's of thousands of developers at all levels creating a few components at all levels of quality over and over again. If we keep it in this group we get peer review, we get unit testing, we get good examples and best (or better) practices. It's fine with me if we move these components to a separate library as long as it's part of this project. Component set 1, 2, 3 etc is great. PS I understand the disadvantage of, "baking in layouts and exposing their properties to the component". So does everyone on the Flex engineering team but they do it for the above reasons. I also understand breaking the pieces down to smaller parts so that you can assemble them into the parts you need. You're talking about creating the letters, the alphabet and that words don't belong in it. I'm saying in creating an application the less detours you have to make and the more you can reuse the more that can be focused on making the app better. My 2 cents --047d7b339cc1c5b88a04baef2482--