You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2012/07/31 04:06:39 UTC
What namespace should new components go in?
Hi,
Reposting (and expanding) as suggested under a new topic to make it clear this discussion is about namespaces. This has been discussed on the list before but no clear consensus was reached.
In the patches branch I've created a new apache target in the build script to compile an an apache.swc to place new components in. It uses a new namespace - http://flex.apache.org/ns. This has been in the patches branch for several months. The PostCode validator and format classes currently use this namespace and I would like to move them into trunk, followed closely by Mike's collection classes.
What are people preferred option with new components and namespaces?
1. Use existing mx and spark namespaces
Advantages: No new namespaces required.
Disadvantages: New components mixed in with old and compiled into existing swcs making them larger etc, hard know what's new over 4.6 SDK. Not always obvious which namespace mx or spark a new component should go into.
2. Place components under a single new namespace called http://flex.apache.org/ns.
Advantages: All new components have a new ant target, new swc and namespace so easy to see what is new in the SDK and if a project is using Apache Flex. Work already done in patches branch. Namespace is valid URL and was suggested by a mentor.
Disadvantages: It's a new namespace.
Example of how a user of the SDK would see it/use it:
http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/validators/src/PostCodeValidationExample.mxml?view=markup
(also see patches branch)
3. Place components under a single new namespace other than one suggested in 2.
See 3 for advantages and disadvantages.
4. Place components under multiple new namespaces
Advantage: No need to decide if it's a mx or spark component.
Disadvantages: Lots of new namespaces. More work on build scripts.
5. Don't care.
In which case I'll just check in what I've done in the patches branch.
Thanks,
Justin
Re: What namespace should new components go in?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Is this stating we migrate from mx/s to a new namespace, or simply start a new namespace for apache flex specific components?
No I think existing namespace should stay the same. Too much code and documentation would have to change, I'm only talking about new classes/components.
Thanks,
Justin
RE: What namespace should new components go in?
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Is this stating we migrate from mx/s to a new namespace, or simply start a new namespace for apache flex specific components?
If it's for a new component set then I'm for option 2. New name space with keeping any component naming the same...
<mx:TextInput />
<s:TextInput />
<a:TextInput />
<mycomponents:TextInput />
If it's replacing the existing mx/s sets, we should do option 4, since the mx/s are not completely compatible.
<amx:TextInput />
<as:TextInput />
<mycomponents:TextInput />
-Mark
-----Original Message-----
From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin Mclean
Sent: Monday, July 30, 2012 22:07
To: flex-dev@incubator.apache.org
Subject: What namespace should new components go in?
Hi,
Reposting (and expanding) as suggested under a new topic to make it clear this discussion is about namespaces. This has been discussed on the list before but no clear consensus was reached.
In the patches branch I've created a new apache target in the build script to compile an an apache.swc to place new components in. It uses a new namespace - http://flex.apache.org/ns. This has been in the patches branch for several months. The PostCode validator and format classes currently use this namespace and I would like to move them into trunk, followed closely by Mike's collection classes.
What are people preferred option with new components and namespaces?
1. Use existing mx and spark namespaces
Advantages: No new namespaces required.
Disadvantages: New components mixed in with old and compiled into existing swcs making them larger etc, hard know what's new over 4.6 SDK. Not always obvious which namespace mx or spark a new component should go into.
2. Place components under a single new namespace called http://flex.apache.org/ns.
Advantages: All new components have a new ant target, new swc and namespace so easy to see what is new in the SDK and if a project is using Apache Flex. Work already done in patches branch. Namespace is valid URL and was suggested by a mentor.
Disadvantages: It's a new namespace.
Example of how a user of the SDK would see it/use it:
http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/validators/src/PostCodeValidationExample.mxml?view=markup
(also see patches branch)
3. Place components under a single new namespace other than one suggested in 2.
See 3 for advantages and disadvantages.
4. Place components under multiple new namespaces
Advantage: No need to decide if it's a mx or spark component.
Disadvantages: Lots of new namespaces. More work on build scripts.
5. Don't care.
In which case I'll just check in what I've done in the patches branch.
Thanks,
Justin
Re: What namespace should new components go in?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I like this idea but maybe an "experimental" namespace and then the
> official "apache" namespace or spark, etc.
For the experimental namespace how about this:
Perhaps http://flex.apache.org/expermenental/ns? "default" namespace prefix "x" and a package name of "org.apache.flex.experimental"?
Of cause you can can make the prefix anything you want but people tend to stick with mx: and s: for existing mx and spark name spaces in code I've seen.
Justin
Re: What namespace should new components go in?
Posted by Jonathan Campos <jo...@gmail.com>.
On Mon, Jul 30, 2012 at 9:06 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> 2. Place components under a single new namespace called
> http://flex.apache.org/ns.
> Advantages: All new components have a new ant target, new swc and
> namespace so easy to see what is new in the SDK and if a project is using
> Apache Flex. Work already done in patches branch. Namespace is valid URL
> and was suggested by a mentor.
> Disadvantages: It's a new namespace.
>
I like this idea but maybe an "experimental" namespace and then the
official "apache" namespace or spark, etc.
--
Jonathan Campos
Re: What namespace should new components go in?
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
I personally like #2. And I don't see having another namespace as a
disadvantage -- we already have mx, fx, and s, let alone any custom ones
that people add.
-Nick
On Mon, Jul 30, 2012 at 10:06 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> Reposting (and expanding) as suggested under a new topic to make it clear
> this discussion is about namespaces. This has been discussed on the list
> before but no clear consensus was reached.
>
> In the patches branch I've created a new apache target in the build script
> to compile an an apache.swc to place new components in. It uses a new
> namespace - http://flex.apache.org/ns. This has been in the patches
> branch for several months. The PostCode validator and format classes
> currently use this namespace and I would like to move them into trunk,
> followed closely by Mike's collection classes.
>
> What are people preferred option with new components and namespaces?
>
> 1. Use existing mx and spark namespaces
> Advantages: No new namespaces required.
> Disadvantages: New components mixed in with old and compiled into existing
> swcs making them larger etc, hard know what's new over 4.6 SDK. Not always
> obvious which namespace mx or spark a new component should go into.
>
> 2. Place components under a single new namespace called
> http://flex.apache.org/ns.
> Advantages: All new components have a new ant target, new swc and
> namespace so easy to see what is new in the SDK and if a project is using
> Apache Flex. Work already done in patches branch. Namespace is valid URL
> and was suggested by a mentor.
> Disadvantages: It's a new namespace.
>
> Example of how a user of the SDK would see it/use it:
>
> http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/validators/src/PostCodeValidationExample.mxml?view=markup
>
> (also see patches branch)
>
> 3. Place components under a single new namespace other than one suggested
> in 2.
> See 3 for advantages and disadvantages.
>
> 4. Place components under multiple new namespaces
> Advantage: No need to decide if it's a mx or spark component.
> Disadvantages: Lots of new namespaces. More work on build scripts.
>
> 5. Don't care.
> In which case I'll just check in what I've done in the patches branch.
>
> Thanks,
> Justin
Re: What namespace should new components go in?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think (but I'm not 100% sure about this) that the "library:" is just a convention for a namespace associated with a SWC.
Which is inconsistent with the mx namespace but I'll assume that's for historic reasons.
> But this convention allows the sole "http:" namespace to stand out as the language namespace that indicates the use of MXML 2006 vs. MXML 2009, which I think is nice.
If we were thinking of adding new apache namespace should we keep the distinction between 2006 and 2009? I'd prefer to drop the year from the URI if we can.
> In general, XML namespaces are not expected to map to web pages.
Sure but it a nice to have I think and also in common usage. The W3C maps namespace URIs to real URLs (eg http://www.w3.org/1999/xhtml). Perhaps we should follow a similar format as described here (and elsewhere)?
http://www.w3.org/2005/07/13-nsuri
But I like the idea as if a user of the SDK goes to that link it take them to the Apache Flex site - where they can find out more info etc.
Thanks,
Justin
RE: What namespace should new components go in?
Posted by Gordon Smith <go...@adobe.com>.
I think (but I'm not 100% sure about this) that the "library:" is just a convention for a namespace associated with a SWC. But this convention allows the sole "http:" namespace to stand out as the language namespace that indicates the use of MXML 2006 vs. MXML 2009, which I think is nice.
In general, XML namespaces are not expected to map to web pages.
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin Mclean
Sent: Tuesday, July 31, 2012 3:41 PM
To: flex-dev@incubator.apache.org
Subject: Re: What namespace should new components go in?
HI,
> http://ns.adobe.com/mxml/2009 -> http://ns.apache.com/mxml/2012
> library://ns.adobe.com/flex/spark ->
> library://ns.apache.com/flex/spark
> library://ns.adobe.com/flex/mx -> library://ns.apache.com/flex/mx
Probably better to use "flex.apache.com/ns" rather than "ns.apache.com" as once we incubate we'll have access to "flex.apache.com" but not "apache.com". While not essential I think it nice if the URIs map to real web page.
I assume it would be possible to have both namespaces coexisting for a while as it's just a mapping between uri's and manifest files in flex-config.xml.
BTW any reason the newer namespace have "library:" rather than "http:"?
Thanks,
Justin
Re: What namespace should new components go in?
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> http://ns.adobe.com/mxml/2009 -> http://ns.apache.com/mxml/2012
> library://ns.adobe.com/flex/spark -> library://ns.apache.com/flex/spark
> library://ns.adobe.com/flex/mx -> library://ns.apache.com/flex/mx
Probably better to use "flex.apache.com/ns" rather than "ns.apache.com" as once we incubate we'll have access to "flex.apache.com" but not "apache.com". While not essential I think it nice if the URIs map to real web page.
I assume it would be possible to have both namespaces coexisting for a while as it's just a mapping between uri's and manifest files in flex-config.xml.
BTW any reason the newer namespace have "library:" rather than "http:"?
Thanks,
Justin
RE: What namespace should new components go in?
Posted by Gordon Smith <go...@adobe.com>.
Yes, but updating MXML files for new namespace URIs would involve only a trivial search and replace.
However, maybe it makes more sense to do this as part of the eventual switch to the Falcon compiler.
- Gordon
-----Original Message-----
From: JP Bader [mailto:jp@zavteq.com]
Sent: Tuesday, July 31, 2012 9:10 AM
To: flex-dev@incubator.apache.org
Subject: Re: What namespace should new components go in?
+1 to change the URI to apache, however that might (most likely will)
cause backwards compatibility issues for any mxml refs.
On Tue, Jul 31, 2012 at 11:00 AM, Gordon Smith <go...@adobe.com> wrote:
> Regarding the existing namespaces -- and I'm referring to the namespace URIs, not the namespace prefixes -- isn't it time to get "adobe" out of them and "apache" into them, now that the parity release is complete?
>
> For example,
>
> http://ns.adobe.com/mxml/2009 -> http://ns.apache.com/mxml/2012
> library://ns.adobe.com/flex/spark ->
> library://ns.apache.com/flex/spark
> library://ns.adobe.com/flex/mx -> library://ns.apache.com/flex/mx
>
> - Gordon
>
> -----Original Message-----
> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of
> Justin Mclean
> Sent: Monday, July 30, 2012 7:07 PM
> To: flex-dev@incubator.apache.org
> Subject: What namespace should new components go in?
>
> Hi,
>
> Reposting (and expanding) as suggested under a new topic to make it clear this discussion is about namespaces. This has been discussed on the list before but no clear consensus was reached.
>
> In the patches branch I've created a new apache target in the build script to compile an an apache.swc to place new components in. It uses a new namespace - http://flex.apache.org/ns. This has been in the patches branch for several months. The PostCode validator and format classes currently use this namespace and I would like to move them into trunk, followed closely by Mike's collection classes.
>
> What are people preferred option with new components and namespaces?
>
> 1. Use existing mx and spark namespaces
> Advantages: No new namespaces required.
> Disadvantages: New components mixed in with old and compiled into existing swcs making them larger etc, hard know what's new over 4.6 SDK. Not always obvious which namespace mx or spark a new component should go into.
>
> 2. Place components under a single new namespace called http://flex.apache.org/ns.
> Advantages: All new components have a new ant target, new swc and namespace so easy to see what is new in the SDK and if a project is using Apache Flex. Work already done in patches branch. Namespace is valid URL and was suggested by a mentor.
> Disadvantages: It's a new namespace.
>
> Example of how a user of the SDK would see it/use it:
> http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/validat
> ors/src/PostCodeValidationExample.mxml?view=markup
>
> (also see patches branch)
>
> 3. Place components under a single new namespace other than one suggested in 2.
> See 3 for advantages and disadvantages.
>
> 4. Place components under multiple new namespaces
> Advantage: No need to decide if it's a mx or spark component.
> Disadvantages: Lots of new namespaces. More work on build scripts.
>
> 5. Don't care.
> In which case I'll just check in what I've done in the patches branch.
>
> Thanks,
> Justin
--
JP Bader
Principal
Zavteq, Inc.
@lordB8r | jp@zavteq.com
608.692.2468
Re: What namespace should new components go in?
Posted by JP Bader <jp...@zavteq.com>.
+1 to change the URI to apache, however that might (most likely will)
cause backwards compatibility issues for any mxml refs.
On Tue, Jul 31, 2012 at 11:00 AM, Gordon Smith <go...@adobe.com> wrote:
> Regarding the existing namespaces -- and I'm referring to the namespace URIs, not the namespace prefixes -- isn't it time to get "adobe" out of them and "apache" into them, now that the parity release is complete?
>
> For example,
>
> http://ns.adobe.com/mxml/2009 -> http://ns.apache.com/mxml/2012
> library://ns.adobe.com/flex/spark -> library://ns.apache.com/flex/spark
> library://ns.adobe.com/flex/mx -> library://ns.apache.com/flex/mx
>
> - Gordon
>
> -----Original Message-----
> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin Mclean
> Sent: Monday, July 30, 2012 7:07 PM
> To: flex-dev@incubator.apache.org
> Subject: What namespace should new components go in?
>
> Hi,
>
> Reposting (and expanding) as suggested under a new topic to make it clear this discussion is about namespaces. This has been discussed on the list before but no clear consensus was reached.
>
> In the patches branch I've created a new apache target in the build script to compile an an apache.swc to place new components in. It uses a new namespace - http://flex.apache.org/ns. This has been in the patches branch for several months. The PostCode validator and format classes currently use this namespace and I would like to move them into trunk, followed closely by Mike's collection classes.
>
> What are people preferred option with new components and namespaces?
>
> 1. Use existing mx and spark namespaces
> Advantages: No new namespaces required.
> Disadvantages: New components mixed in with old and compiled into existing swcs making them larger etc, hard know what's new over 4.6 SDK. Not always obvious which namespace mx or spark a new component should go into.
>
> 2. Place components under a single new namespace called http://flex.apache.org/ns.
> Advantages: All new components have a new ant target, new swc and namespace so easy to see what is new in the SDK and if a project is using Apache Flex. Work already done in patches branch. Namespace is valid URL and was suggested by a mentor.
> Disadvantages: It's a new namespace.
>
> Example of how a user of the SDK would see it/use it:
> http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/validators/src/PostCodeValidationExample.mxml?view=markup
>
> (also see patches branch)
>
> 3. Place components under a single new namespace other than one suggested in 2.
> See 3 for advantages and disadvantages.
>
> 4. Place components under multiple new namespaces
> Advantage: No need to decide if it's a mx or spark component.
> Disadvantages: Lots of new namespaces. More work on build scripts.
>
> 5. Don't care.
> In which case I'll just check in what I've done in the patches branch.
>
> Thanks,
> Justin
--
JP Bader
Principal
Zavteq, Inc.
@lordB8r | jp@zavteq.com
608.692.2468
RE: What namespace should new components go in?
Posted by Gordon Smith <go...@adobe.com>.
Regarding the existing namespaces -- and I'm referring to the namespace URIs, not the namespace prefixes -- isn't it time to get "adobe" out of them and "apache" into them, now that the parity release is complete?
For example,
http://ns.adobe.com/mxml/2009 -> http://ns.apache.com/mxml/2012
library://ns.adobe.com/flex/spark -> library://ns.apache.com/flex/spark
library://ns.adobe.com/flex/mx -> library://ns.apache.com/flex/mx
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin Mclean
Sent: Monday, July 30, 2012 7:07 PM
To: flex-dev@incubator.apache.org
Subject: What namespace should new components go in?
Hi,
Reposting (and expanding) as suggested under a new topic to make it clear this discussion is about namespaces. This has been discussed on the list before but no clear consensus was reached.
In the patches branch I've created a new apache target in the build script to compile an an apache.swc to place new components in. It uses a new namespace - http://flex.apache.org/ns. This has been in the patches branch for several months. The PostCode validator and format classes currently use this namespace and I would like to move them into trunk, followed closely by Mike's collection classes.
What are people preferred option with new components and namespaces?
1. Use existing mx and spark namespaces
Advantages: No new namespaces required.
Disadvantages: New components mixed in with old and compiled into existing swcs making them larger etc, hard know what's new over 4.6 SDK. Not always obvious which namespace mx or spark a new component should go into.
2. Place components under a single new namespace called http://flex.apache.org/ns.
Advantages: All new components have a new ant target, new swc and namespace so easy to see what is new in the SDK and if a project is using Apache Flex. Work already done in patches branch. Namespace is valid URL and was suggested by a mentor.
Disadvantages: It's a new namespace.
Example of how a user of the SDK would see it/use it:
http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/validators/src/PostCodeValidationExample.mxml?view=markup
(also see patches branch)
3. Place components under a single new namespace other than one suggested in 2.
See 3 for advantages and disadvantages.
4. Place components under multiple new namespaces
Advantage: No need to decide if it's a mx or spark component.
Disadvantages: Lots of new namespaces. More work on build scripts.
5. Don't care.
In which case I'll just check in what I've done in the patches branch.
Thanks,
Justin
Re: What namespace should new components go in?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Can there be a #6? If there was an MX version and you are essentially
> creating the Spark version then put it under the spark namespace.
Sure. Only downside (and only a very minor one) is that it it not obvious that it's a new component but not a big issues as long as we can indicate such in the documentation etc
Thanks,
Justin
Re: What namespace should new components go in?
Posted by Alex Harui <ah...@adobe.com>.
On 7/30/12 7:06 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> Reposting (and expanding) as suggested under a new topic to make it clear this
> discussion is about namespaces. This has been discussed on the list before but
> no clear consensus was reached.
>
Can there be a #6? If there was an MX version and you are essentially
creating the Spark version then put it under the spark namespace.
Otherwise, put it in a new namespace. There should be multiple new
namespaces where it makes sense. Start with the one you've suggested for
now and we'll see what gets contributed and organize accordingly.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui