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 in. > 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. Tink
