Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of justinmclean@gmail.com
 designates 209.85.160.47 as permitted sender)
Sender: Justin Mclean <justinmclean@gmail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1280)
Subject: Re: What namespace should new components go in?
From: Justin Mclean <justin@classsoftware.com>
In-Reply-To: <fo8jxckwsdqu3f6xl2y05qo7.1343742557813@email.android.com>
Date: Wed, 1 Aug 2012 00:14:39 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1C68CD6-BFE9-4243-8969-EC2AD01F5DCC@classsoftware.com>
References: <fo8jxckwsdqu3f6xl2y05qo7.1343742557813@email.android.com>
To: flex-dev@incubator.apache.org

Hi,

> That would mean that each time we release with some additional =
components we would end up adding a new namespace (i.e we'd have got a =
new namespace for a spark DataGrid)
Nor am I suggesting one namespace per new component added. I was just =
suggesting one new namespace to add new components to. Yes in some cases =
it may make more sense to add new components to the existing spark or mx =
namespace. The postccode formatter/validator classes are not quite mx =
and not quite spark so it's a little difficult to know where to add them =
if we didn't add a new namesapce.

> That said I think it was insane that Adobe threw all ui components =
into a single "component" package with the introduction of spark instead =
of keeping the "container", "control" packing used in mx, with the =
extremely lame excuse that it was difficult to distinguish the =
difference between containers and controls in spark.
+1 to that. We might be able to change that via adding duplicate =
packages via manifest files (I think not tired). Along the same lines as =
mx:Rect/s:Rect?

Thanks,
Justin=