flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tink <f...@tink.ws>
Subject Re: What namespace should new components go in?
Date Tue, 31 Jul 2012 21:48:53 GMT
Hey Justin

On 31 Jul 2012, at 15:14, Justin Mclean wrote:

> Nor am I suggesting one namespace per new component added. 

I was aware of that, I meant to imply we would have got a new namespace with 4.5 and the introduction
of Spark DataGrid, Form, Image, Module, Busy Indicator, SkinnablePopUpContainer, Date/Time,
Number/Currency Formatters & Number/Currency Validators. If we start out with a pattern
of introducing a new namespace when u have new components in a release, we should continue
that pattern no matter how many components you introduce in a release. For me if they are
spark based classes they should be in spark packages and in the spark namespace, if they are
mx based classes they should be in mx packages and namespace.

The packages and namespace names should not be influenced by the release a component was introduced

> 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 namesake.

The PostCodeValidator implementation extends the mx validator and the PostCodeFormatter extends
the mx validator. Neither extend the spark validation or formatting base classes, therefore
IMO they should both go in mx packages and be in the mx namespace. If someone then adds a
spark based solution they can be also be easily added to the SDK without conflict and preserving
backwards compatibility.

> +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?

mx:Rect/s:Rect are namespace issues. My point was a little off topic i guess although the
package names do fit into the 2 broad namespaces of mx and spark.

Moving the components out of "components" and into "containers" & "controls" could again
be a bit of a headache for those that have used them in AS (find and replace would do the
job again though). By updating the manifest, there wouldn't be any mxml namespace issue.

We in agreement that changing the URI for the namespaces to remove 'adobe' would also be good.
maybe we could provide a simple AIR tool that performs the find and replace on a codebase
for both the URI, and spark container/controls packages.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message