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/03/14 08:43:40 UTC
Flex and names spaces in MXML
Hi,
I think that you can define public namespaces in actionscript like so:
public namespace fx = "http://ns.adobe.com/mxml/2009";
public namespace s = "library://ns.adobe.com/flex/spark";
public namespace mx = "library://ns.adobe.com/flex/mx";
Is there any way we can define the common namespaces somewhere (in UIComponent??) so we don't have to define them all the time in MXML? This may become more of an issue as we add a few more name spaces.
Ideally it would be nice (I think) to just do this:
<s:Application width="100%">
Instead of:
<s:Application width="100%"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
Perhaps we have the MXML compiler automatically create these namespaces if they are not defined? (Once it gets donated of course.)
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Om <bi...@gmail.com>.
You still need a default namespace attribute at the top of the mxml
document. This allows you to use your components without having to use a
namespace prefix.
Thanks,
Om
On Wed, Mar 14, 2012 at 1:24 PM, Left Right <ol...@gmail.com> wrote:
> Hehe, found it :)
>
>
> http://web.archive.org/web/20090106154553/http://opensource.adobe.com./wiki/display/flexsdk/MXML+2009
>
> Got to love this site some times.
>
> Best.
>
> Oleg
>
Re: Flex and names spaces in MXML
Posted by Jonathan Campos <jo...@gmail.com>.
On Wed, Mar 14, 2012 at 3:24 PM, Left Right <ol...@gmail.com> wrote:
> Hehe, found it :)
>
>
> http://web.archive.org/web/20090106154553/http://opensource.adobe.com./wiki/display/flexsdk/MXML+2009
>
> Got to love this site some times.
>
> Best.
>
> Oleg
>
I don't think Gordon would disagree with you. I think he was saying if you
wanted to have some sort of s:Application without declaring xmlns:s then it
wouldn't be valid XML markup. What you are saying is to just declare an ""
ns.
--
Jonathan Campos
Re: Flex and names spaces in MXML
Posted by Left Right <ol...@gmail.com>.
Hehe, found it :)
http://web.archive.org/web/20090106154553/http://opensource.adobe.com./wiki/display/flexsdk/MXML+2009
Got to love this site some times.
Best.
Oleg
Re: Flex and names spaces in MXML
Posted by Left Right <ol...@gmail.com>.
Sorry? Why? I think I can find some examples of Flex 4 beta code, where no
namespaces were used... It's from the time when Fx prefix was debated,
there were few builds that allowed MXML code w/o any namespaces, like
<Application>
<Button>click me</Button>
</Application>
etc.
Best.
Oleg
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> After all, I seriously think that what namespace there should be is
> irrelevant, the actual task is to make it so it is most flexible.
Which I agree with and and as a first step which was trying to remove the namesapce URL from the MXML code. In AS you use package names via import to specify which say List class you want to use - no namespace URI's required. I think you may be confusing packages with namesapces or perhaps I said wasn't clear enough?
Do you have an alternative suggestion or way to achieve this simply in MXML?
> but it absolutely doesn't fit in other use cases.
You would only use the flex-config.xml file if you were using the Flex SDK. If you didn't use it it would have no effect. What other use cases exist that would use the flex-config.xml file?
> As I mentioned above: UIComponent isn't a requirement for
> MXML, so, if, as you suggested before, these namespaces were defined in
> UIComponent, other legitimate uses would suffer from it because they would
> have to bring in UIComponent class,
Don't think that is the case either or rather depending on how you link in the SDK. Using RSLs you get everything (but they can be cached so that's OK) with static linking you only get the code you require no more and no less. Just because you using a name space doesn't mean you suddenly link in every class in that namespace into your code. If your MXML uses no mx classes you don't get any of them in your final swf.
Or am I missing your point her?
> Now, is there a particular class, which is a requirement for MXML? - no,
> there isn't any. So, you don't have a place to store these namespaces, even
> if it was somehow technically possible.
For generic MXML that is correct but for the Flex SDK there is ie flex-config.xml.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think adding a default namespace only adds confusion.
As opposed to the confusion they do cause? :-)
It would make simple MXML easier to write (especial for people new to it) and use but looks too many people are against the idea.
Not that I could do anything about it until we get has the compiler code anyway.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Right now, we have mx (going away, eventually), fx (script tags) and s
> (spark). I don't even think adding an "a" namespace to denote new
> components from Apache really makes sense at this point.
I though this had already been agreed upon? We needed an area (and new namespace) that new components would go into and be improved upon before it was decided they were good enough to go into the mx, spark or perhaps another namespace? That's why I made the changes to the PostCode components and the build scripts in the first place.
Justin
Re: Flex and names spaces in MXML
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
I think I still have a pitchfork in my closet from that one.
Personally, I think that we should keep the existing name spaces.. And for
those who don't want to use particular elements from those namespaces (for
example, with very few exceptions, my mobile flex apps don't use, nor
declare the mx namespace), don't have to.
Right now, we have mx (going away, eventually), fx (script tags) and s
(spark). I don't even think adding an "a" namespace to denote new
components from Apache really makes sense at this point.
The reason why mx -> s was important was that the architectural really
changed, plus the planned obsolescence of the old components. I don't
think there is much on our plate right now that constitutes a similar need
(aside some of the architectural changes that Alex and Mike have been
teasing us with).
-Nick
On Sat, Mar 17, 2012 at 12:28 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/16/12 9:08 PM, "Omar Gonzalez" <om...@gmail.com> wrote:
>
>
> >
> > I think s:List and mx:List is fine. I think changing the classes to
> MxList
> > or sList or SList is pretty ugly.
> In Flex 4, the early pre-releases added Fx to everything (FxList,
> FxTextInput) to avoid requiring folks learn about namespaces. The
> pre-release users strongly put down the Fx prefix and we used namespaces
> instead. I think it was the right decision.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: Flex and names spaces in MXML
Posted by Alex Harui <ah...@adobe.com>.
On 3/16/12 9:08 PM, "Omar Gonzalez" <om...@gmail.com> wrote:
>
> I think s:List and mx:List is fine. I think changing the classes to MxList
> or sList or SList is pretty ugly.
In Flex 4, the early pre-releases added Fx to everything (FxList,
FxTextInput) to avoid requiring folks learn about namespaces. The
pre-release users strongly put down the Fx prefix and we used namespaces
instead. I think it was the right decision.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Flex and names spaces in MXML
Posted by Omar Gonzalez <om...@gmail.com>.
On Fri, Mar 16, 2012 at 9:01 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > I don't mind them either. I tried using manifest files and always ran
> into
> > weird issues in FlashBuilder with them so I never used them.
> Each namespace URI maps directly to a manifest file so you are probably
> using them and don't realise it.
>
I was referring to custom application manifest files for your own stuff.
>
> > They're also a hassle to maintain.
> A little. But are required for building the swcs that make up the SDK.
>
Yea I realize that. I was just saying in my app code I prefer to have lots
of namespaces as opposed to making a manifest for my app code.
I think s:List and mx:List is fine. I think changing the classes to MxList
or sList or SList is pretty ugly.
-omar
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I don't mind them either. I tried using manifest files and always ran into
> weird issues in FlashBuilder with them so I never used them.
Each namespace URI maps directly to a manifest file so you are probably using them and don't realise it.
> They're also a hassle to maintain.
A little. But are required for building the swcs that make up the SDK.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Omar Gonzalez <om...@gmail.com>.
On Friday, March 16, 2012, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> For what it's worth, I see nothing wrong with "excessive" use of names
paces.
> Perhaps it's just me they bug :-)
>
> Good to hear another viewpoint.
>
> Thanks,
> Justin
>
>
I don't mind them either. I tried using manifest files and always ran into
weird issues in FlashBuilder with them so I never used them. They're also a
hassle to maintain.
-omar
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> For what it's worth, I see nothing wrong with "excessive" use of names paces.
Perhaps it's just me they bug :-)
Good to hear another viewpoint.
Thanks,
Justin
RE: Flex and names spaces in MXML
Posted by Aaron Miller <am...@learnatvivid.com>.
For what it's worth, I see nothing wrong with "excessive" use of names paces. I would actually argue this is a good thing. It makes the code more clear and concise in my opinion.
I think it just comes down to a matter of preference, and probably has a lot to do with how Flex is used. Even for relatively simple projects, I will create a custom component set with their own name spaces. I also have projects that use MXML without touching a single class in the Flex framework. For me, the value of Flex isn't in it's component set, it's the constructs it provides for creating a solid application architecture. MXML works great for for me how it is now.
All the Best,
~Aaron
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Also you'd only get that many namespaces if you used a variety of different
> component sets in a single mxml document.
Which is quite likely I think. You currently quite often need to use both spark and mx if you want to use apache you need to add that so that. (The four already fx, s,mx and a).
There has been talk in another thread of having a apache mx namespace and an apache spark namespace so you might need to add one or both of those.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Jonathan Campos <jo...@gmail.com>.
On Mar 16, 2012 8:55 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> Hi,
>
> If we make no changes it probably means that down the track we're likely
to end up with this:
>
> <s:Application width="100%"
> xmlns:fx="http://ns.adobe.com/mxml/2009"
> xmlns:s="library://ns.adobe.com/flex/spark"
> xmlns:mx="library://ns.adobe.com/flex/mx"
> xmlns:a="http://flex.apache.org/ns"
> xmlns:as="http://flex.apache.org/sparkns"
> xmlns:amx="http://flex.apache.org/mxns"
> xmlns:nc="http://flex.apache.org/ncns">
>
> Which I'd like to avoid somehow.
>
> Thanks,
> Justin
>
> PS "nc" is new component model that someone's come up.
This is exactly why namespaces should be well planned and rarely added.
Also you'd only get that many namespaces if you used a variety of different
component sets in a single mxml document. More than likely you'd have far
fewer actually in use at once.
Re: Flex and names spaces in MXML
Posted by aYo ~ <ay...@binitie.com>.
I really do not see any problem here. Its flexible and that's the point.
a
On 17 Mar 2012 01:55, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> If we make no changes it probably means that down the track we're likely
> to end up with this:
>
> <s:Application width="100%"
> xmlns:fx="http://ns.adobe.com/mxml/2009"
> xmlns:s="library://ns.adobe.com/flex/spark"
> xmlns:mx="library://ns.adobe.com/flex/mx"
> xmlns:a="http://flex.apache.org/ns"
> xmlns:as="http://flex.apache.org/sparkns"
> xmlns:amx="http://flex.apache.org/mxns"
> xmlns:nc="http://flex.apache.org/ncns">
>
> Which I'd like to avoid somehow.
>
> Thanks,
> Justin
>
> PS "nc" is new component model that someone's come up.
Re: Flex and names spaces in MXML
Posted by Duane Nickull <du...@uberity.com>.
Thank you - clarifies a lot.
Maybe a compromise is to simply just use <a:component> for every new
component from Apache until Adobe actually adopts it into the main fork?
My vote on this, put it up for vote now, and move on to more important
issues. We can revisit later.
Duane
----------------
President/COO Überity Technology Corporation
Adobe LiveCycle ES & Enterprise Specialist
Blog | http://technoracle.blogspot.com
Twitter | @Uberity @duanechaos
On 12-03-16 9:13 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> This is assuming that someone would use both Adobe and Apache spark
>> components
>Which is very likely as initially the apache set of components are going
>to be small in number and would be used with other spark or mx components.
>
>> It's 4 extra lines of code. Why is this a bad situation?
>It not bad as such. I just thought it would be nice not to have to
>specify those lines of code over again in multiple files in a single
>project. It something that bugs me a little.
>
>> What is "a" for? An Apache version of FX? Sorry to be naïve.
>New apache components. Neither fx or mx nor sparc. Doesn't have to be "a"
>as you can name name spaces anything, "as" and "asf" have also been
>suggested.
>
>Previous discussion around name spaces concluded to put all new
>components into an name space while they can be worked on before decided
>if they should go into the spark or mx space or a new name space.
>
>It has been decided that having real URLs in as the namespace is a good
>idea.
>
>It hasn't been decided if we should just have a apache namespace and a
>temporary name space or just use a single namespace for both. ie
>components will stay in the apache namespace if they don't fit in with
>spark or mx once it been decided they are good enough.
>
>Was also suggested that we have a namespace for incubation and for after
>we graduate (so the URLs are correct and point somewhere real).
>
>It's also suggested an apache mx name space and spark name space but
>there seems a little resistance to that.
>
>Hopefully I've got all that correct.
>
>Thanks,
>Justin
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This is assuming that someone would use both Adobe and Apache spark
> components
Which is very likely as initially the apache set of components are going to be small in number and would be used with other spark or mx components.
> It's 4 extra lines of code. Why is this a bad situation?
It not bad as such. I just thought it would be nice not to have to specify those lines of code over again in multiple files in a single project. It something that bugs me a little.
> What is "a" for? An Apache version of FX? Sorry to be naïve.
New apache components. Neither fx or mx nor sparc. Doesn't have to be "a" as you can name name spaces anything, "as" and "asf" have also been suggested.
Previous discussion around name spaces concluded to put all new components into an name space while they can be worked on before decided if they should go into the spark or mx space or a new name space.
It has been decided that having real URLs in as the namespace is a good idea.
It hasn't been decided if we should just have a apache namespace and a temporary name space or just use a single namespace for both. ie components will stay in the apache namespace if they don't fit in with spark or mx once it been decided they are good enough.
Was also suggested that we have a namespace for incubation and for after we graduate (so the URLs are correct and point somewhere real).
It's also suggested an apache mx name space and spark name space but there seems a little resistance to that.
Hopefully I've got all that correct.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> In any case, what do you see as an alternative? I cannot see any other
> than combining the a, as and amx into one.
Well I think it would be possible to make one huge manifest file (ie one name space that includes everything).
You would then have to decide how to resolve the conflicts (classes with same names). Yu could do this by using the previous name spaces where required (easy) or change identical class name so there no conflicts and perhaps this can be done in the manifest file? ie rename List to mxList and sList in this manifest file?
Not sure if that a good idea or not.
Justin
Re: Flex and names spaces in MXML
Posted by Duane Nickull <du...@uberity.com>.
On 12-03-16 7:55 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>If we make no changes it probably means that down the track we're likely
>to end up with this:
>
><s:Application width="100%"
> xmlns:fx="http://ns.adobe.com/mxml/2009"
> xmlns:s="library://ns.adobe.com/flex/spark"
> xmlns:mx="library://ns.adobe.com/flex/mx"
> xmlns:a="http://flex.apache.org/ns"
> xmlns:as="http://flex.apache.org/sparkns"
> xmlns:amx="http://flex.apache.org/mxns"
> xmlns:nc="http://flex.apache.org/ncns">
This is assuming that someone would use both Adobe and Apache spark
components (same for halo) and also use custom components. I can see that
if this group does it's job correctly, this would only be a temporary
situation at least. IN any event, this would be required to tell the
compiler which s:button to actually use. It's 4 extra lines of code. Why
is this a bad situation?
What is "a" for? An Apache version of FX? Sorry to be naïve.
In any case, what do you see as an alternative? I cannot see any other
than combining the a, as and amx into one.
Duane
----------------
President/COO Überity Technology Corporation
Adobe LiveCycle ES & Enterprise Specialist
Blog | http://technoracle.blogspot.com
Twitter | @Uberity @duanechaos
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
If we make no changes it probably means that down the track we're likely to end up with this:
<s:Application width="100%"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:a="http://flex.apache.org/ns"
xmlns:as="http://flex.apache.org/sparkns"
xmlns:amx="http://flex.apache.org/mxns"
xmlns:nc="http://flex.apache.org/ncns">
Which I'd like to avoid somehow.
Thanks,
Justin
PS "nc" is new component model that someone's come up.
Re: Flex and names spaces in MXML
Posted by Jonathan Campos <jo...@gmail.com>.
I think adding a default namespace only adds confusion.
"So why do I leave this components namespace blank and set another?"
I would drop the idea for default namespaces
On Mar 16, 2012 6:37 PM, "Left Right" <ol...@gmail.com> wrote:
> No-no-no :)
> Framework code is an extension, an add-on. There is absolutely no reason it
> should get into "default" namespace. There is enough frustration as it is
> about all sorts of non-built-in AS3 code that Adobe tossed into Flash CS,
> and made the use mandatory. Please don't add even more to it. All these
> http.../mx, http.../halo etc namespaces are no default. A lot of people
> using Flex (compiler) don't need them and don't want them.
>
> Too little profit for too many changes. If you want to make really good
> template language - forget about XML at all, it's not meant to be a good
> template language, it has never been designed to be it. The benefits of
> having XML as a template language are that other tools support it already
> and that it is familiar to the users. If you lose the first benefit and you
> confuse your users, you are left with nothing.
>
> After all, I seriously think that what namespace there should be is
> irrelevant, the actual task is to make it so it is most flexible. Flexible,
> in my understanding is "possible to substitute or remove". I.e. if I wanted
> to put List class into default namespace, while not using Flex framework, I
> wouldn't have to deal with any naming collisions. This is, by the way,
> quite realistic requirement, because, for reasons beyond my comprehension,
> in Flex framework, List names a graphical component, while any programmer
> with some experience would expect List to be a data structure.
> Well, it's like Java classes are in java.lang.* package, Lisp default
> functions are in common-lisp-user package, .NET core classes are in
> Windows.* namespace etc. Default namespace is for the programmers, not the
> language (and they shouldn't really use it too, unless maybe for
> experiments).
>
> After all, you really look at it from a perspective of someone who only
> used MXML for one particular thing and that's why the solution you are
> trying to offer might look logical to you, but it absolutely doesn't fit in
> other use cases. As I mentioned above: UIComponent isn't a requirement for
> MXML, so, if, as you suggested before, these namespaces were defined in
> UIComponent, other legitimate uses would suffer from it because they would
> have to bring in UIComponent class, and you really don't want to feed
> that monstrously obese piece of code to the compiler, once your entire
> project may be 10000 (ten thousands!) times smaller than that thing.
> Now, is there a particular class, which is a requirement for MXML? - no,
> there isn't any. So, you don't have a place to store these namespaces, even
> if it was somehow technically possible.
>
> Using some other template language to generate AS3? - yup, that's
> interesting :) I was once thinking about some very simple language for
> describing resource files. My first idea was CSS, but then I realized it is
> overly complex (has redundant parts), then I looked at Protobuf - cool, but
> it would be difficult to add Flash-specific things and it already requires
> things impossible in Flash (64-bit integers). I was thinking about
> something like JSON, but it's overly verbose and doesn't allow references.
> I finally stopped at symbolic expressions, but got some other things to do
> :) Though I think that it could actually work.
>
> Best.
>
> Oleg
>
Re: Flex and names spaces in MXML
Posted by Left Right <ol...@gmail.com>.
No-no-no :)
Framework code is an extension, an add-on. There is absolutely no reason it
should get into "default" namespace. There is enough frustration as it is
about all sorts of non-built-in AS3 code that Adobe tossed into Flash CS,
and made the use mandatory. Please don't add even more to it. All these
http.../mx, http.../halo etc namespaces are no default. A lot of people
using Flex (compiler) don't need them and don't want them.
Too little profit for too many changes. If you want to make really good
template language - forget about XML at all, it's not meant to be a good
template language, it has never been designed to be it. The benefits of
having XML as a template language are that other tools support it already
and that it is familiar to the users. If you lose the first benefit and you
confuse your users, you are left with nothing.
After all, I seriously think that what namespace there should be is
irrelevant, the actual task is to make it so it is most flexible. Flexible,
in my understanding is "possible to substitute or remove". I.e. if I wanted
to put List class into default namespace, while not using Flex framework, I
wouldn't have to deal with any naming collisions. This is, by the way,
quite realistic requirement, because, for reasons beyond my comprehension,
in Flex framework, List names a graphical component, while any programmer
with some experience would expect List to be a data structure.
Well, it's like Java classes are in java.lang.* package, Lisp default
functions are in common-lisp-user package, .NET core classes are in
Windows.* namespace etc. Default namespace is for the programmers, not the
language (and they shouldn't really use it too, unless maybe for
experiments).
After all, you really look at it from a perspective of someone who only
used MXML for one particular thing and that's why the solution you are
trying to offer might look logical to you, but it absolutely doesn't fit in
other use cases. As I mentioned above: UIComponent isn't a requirement for
MXML, so, if, as you suggested before, these namespaces were defined in
UIComponent, other legitimate uses would suffer from it because they would
have to bring in UIComponent class, and you really don't want to feed
that monstrously obese piece of code to the compiler, once your entire
project may be 10000 (ten thousands!) times smaller than that thing.
Now, is there a particular class, which is a requirement for MXML? - no,
there isn't any. So, you don't have a place to store these namespaces, even
if it was somehow technically possible.
Using some other template language to generate AS3? - yup, that's
interesting :) I was once thinking about some very simple language for
describing resource files. My first idea was CSS, but then I realized it is
overly complex (has redundant parts), then I looked at Protobuf - cool, but
it would be difficult to add Flash-specific things and it already requires
things impossible in Flash (64-bit integers). I was thinking about
something like JSON, but it's overly verbose and doesn't allow references.
I finally stopped at symbolic expressions, but got some other things to do
:) Though I think that it could actually work.
Best.
Oleg
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Now imagine you decided to put framework code forcefully into default
> namespace - you prevented everyone from using that namespace even though
> they might not be using the framework.
Not quite correct. They could use the names space and name it something else. I think it could be smart enough to only add the default names spaces if they were not already defined or their names used.
> You cannot really avoid doing it because of the tools that work with MXML are built on top of tools
> that work with XML, and if MXML breaks some basic XML rules, the tools will
> stop working.
Yep it would involve changing the compiler (both MXML and perhaps ASDocs) what other tools work with MXML other then various IDEs I guess? "old" style MXML would still be a valid option which any new feature it may take a while for the IDE's to catch up.
> The only reason for using MXML, really, is that there are tools for working
> with XML, so you have prerequisites. But, really, if anyone was about to
> break the compatibility with XML
The root names space could be added by any tool (or by hand if required) so I don;t see the need to move away from XMML all together. Still an interesting idea about making another templating system that's not XML based.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Left Right <ol...@gmail.com>.
Justin,
Unfortunately, you have to already tell the compiler what namespace to use
on the root node. This is because the system has already been built wrong.
Second, I don't think this is a very good idea in general, and especially
not if it should be handled by MXMLC code. This approach created a lot of
problems and fundamental confusions about MXML in the past. MXML is a
template. What you now put as a default (Application) may not even exist in
the project that uses MXML. So, if you want to keep this template generic,
you need a way to show in the template itself, what is the origin of the
class that is being used.
Due to the documentation and suggested workflows, there is an impression
that MXML is exclusively used with mx or spark or derived components, while
there is no such connection. The code below is absolutely valid MXML (at
least as of version < 4 of SDK):
<flash:Sprite xmlns:flash="flash.display.*">
<flash:enterFrame>
super.removeEventListener(Event.ENTER_FRAME, arguments.callee);
trace("This is a no-Flex MXML");
</flash:enterFrame>
</flash:Sprite>
In later version you'd need to specify the namespace for flex framework you
are "targeting" even though it targets none... well, reason has never been
a strong side of MXML. :)
Now imagine you decided to put framework code forcefully into default
namespace - you prevented everyone from using that namespace even though
they might not be using the framework. I would see how putting things,
which are unquestionably present and will likely remain so in a long time,
into default namespace - the top-level Flash classes seem to be good
candidates. Classes from flash.* packages aren't, because there's no
analogue in JavaScript, and if you want to crosscompile to JavaScript,
you'll find it to be a problem. All the mx, spark, flashx, com.adobe and
similar - are just extensions, and it should be clear to anyone using the
tool.
On a somewhat different note, MXML being an XML variant has to adhere to
XML rules, so, the code you wrote isn't valid. XML is a very bad choice for
designing programming language templates, but reason has never been a
strong side of MXML. (does it sound familiar yet? :)) So that's why, unlike
in AS, you will have to declare the prefix you are using with the node name
in the ancestor tag of the tag that is using it. You cannot really avoid
doing it because of the tools that work with MXML are built on top of tools
that work with XML, and if MXML breaks some basic XML rules, the tools will
stop working.
The only reason for using MXML, really, is that there are tools for working
with XML, so you have prerequisites. But, really, if anyone was about to
break the compatibility with XML, then there's no point in using lots of
other things imposed by XML. Maybe it would be better to take RTF or LaTeX
as a pattern... maybe YAML, or, oh horror, s-expressions! :)
Best.
Oleg
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Seems to be a variety of views here all from including trying to do away with names spaces if we can :-) Certainly no consensus.
My original suggestion was just to have the standard URLs predefined but still use name space names in MXML code.
The name space URIs are defined in flex-config.xml so It would be possible to omit them from the code. We would have to specify a default name space name (mx, s etc) but would still have to use name space names when specifying components eg Have to use <mx:List> or <s:List> not <List>
Like this perhaps:
<namespace>
<uri>http://www.apache.org/flex</uri>
<manifest>apache-manifest.xml</manifest>
<name>a</name>
</namespace>
<namespace>
<uri>library://ns.adobe.com/flex/spark</uri>
<manifest>spark-manifest.xml</manifest>
<name>s</name>
</namespace>
<namespace>
<uri>library://ns.adobe.com/flex/mx</uri>
<manifest>mx-manifest.xml</manifest>
<name>mx</name>
</namespace>
The only down side and this may be a big one is that the MXML files would no longer be 100% valid XML. Which may cause some issues for 3rd party tools IDEs etc etc
We could take this a step further if we specified an order to look through the standard name spaces ie Apache then Spark then MX ie the order they are listed in the flex-config.xml.
My objective here is to make standard MXML code a bit easier for humans to read. Here what some code would look like. You would still need to use some namespace names but not all over the place.
<Application> <-- found in Spark (not mx) namespace -->
<Declarations> <-- found in fx namesapce -->
<PostCodeValidator id="pcv"/> <-- found in apache namespace -->
<Declarations>
<mx:List id="country" /> <-- Wanted mx one not spark one so needed to specify name space name -->
</Application>
I don't imagine that the MXML compiler changes would be that hard to make this happen and wouldn't break any existing code or force it to change.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Left Right <ol...@gmail.com>.
Om: not quite. There is one implied default namespace for any XML document,
it's something with w3c in the URI, it's the namespace where 'lang'
attribute goes for example. So, what I was saying in my first response is
that Flex could've had added one default namespace too, for example for
built-in classes, such as int, Number, String etc. To be honest, I could
never understand what do these do under mx or spark namespaces. It would be
also informative and good from the educational standpoint to have flash.*
classes in a special namespace, because these are also sorts of built-ins.
And then all the rest to be whatever people want them to be.
Gordon. Oh, OK, your previous answer just sounded odd without this
explanation.
Duane, probably not a good example, because this is taken care of by DTDs
and such: the bar inside bar would be distinct from bar inside foo by the
fact it's inside bar. But these rules' complexity rises in geometrical
progression, so they are not useful for non-trivial XML documents. But, XML
is just a bad format for most purposes it's been used in 21'st century, so
these aren't news.
I think that it's not possible today to use default namespace because mx
and spark code generation work differently, and there's no way otherwise
for the compiler to know, which one to use. So, having mandatory namespace
solves the problem, but in a bad, non-generic way. It would be best if code
generation didn't rely on namespace used (because there is no logical
dependency between the two).
I would see this as a big step forward, and was advocating this before, if
the code generation mechanism was made available to developer. S.t. for
example it would be based on templates, or rule sets. The solution Adobe
came up with is a typical "enterprise" kind of thinking - trying to deal
with outcomes rather then fixing the source of the problem.
Imagine the example below:
[Mixin]
public class FlexInit {
public static function init():void {
${Accessibility initialization block}
${AMF aliases registration block}
. . .
}
This is the code that might have been used to generate FlexInit class. So
that if it was your project, and you knew you aren't going to implement
accessibility anyways, you could loose the first block. If you wanted to
override the default behavior of AMF aliases registration - again, you
would be able to do so. More yet, if you didn't want this template to be
used - you'd have to remove it, and the mention of it from other templates.
Similarly, the rules of translation of arbitrary MXML code into AS3 could
be expressed in some CFG-like language, so that if you wanted to alter the
way attributes are treated, add, for example, access modifiers, constants
usage etc. you would have something like:
identifier := ${access modifier} ${static} 'var' ${node name} ':' ${type
specifier} (initializer)*
rule, which would take certain parts of an XML node and replace the ${...}
with respective content. This would've create a really generic and reusable
system. On the other hand, having MXML templates hardcoded into compiler
has a "potential" of, for example, breaking all projects of all users in
some subtle way for the life time of the release.
Best.
Oleg
RE: Flex and names spaces in MXML
Posted by Gordon Smith <go...@adobe.com>.
What I meant was that if you write <s:Button/> without declaring what s is (with xmlns:s="..." on that tag or on an enclosing tag) then you don't have valid XML.
- Gordon
-----Original Message-----
From: David Francis Buhler [mailto:davidbuhler@gmail.com]
Sent: Wednesday, March 14, 2012 1:55 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex and names spaces in MXML
Omitting the xmlns attributes in MXML would make MXML valid XML, it just wouldn't prevent namespace collisions (because there is no namespace prefix).
On Wed, Mar 14, 2012 at 4:47 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Omitting the xmlns attributes in MXML would make MXML not be valid XML.
>
> That's probably an issue.
>
> Does anything currently require them to be 100% valid XML with namespaces (compared to well formed XML missing namespaces)?
>
> Thanks,
> Justin
Re: Flex and names spaces in MXML
Posted by Duane Nickull <du...@uberity.com>.
On 12-03-14 1:54 PM, "David Francis Buhler" <da...@gmail.com> wrote:
>Omitting the xmlns attributes in MXML would make MXML valid XML, it
>just wouldn't prevent namespace collisions (because there is no
>namespace prefix).
Correct. XML NameSpaces are perhaps one of the most misunderstood
mechanisms on the planet. You can have perfectly legal XML like this:
<!--I am not typing the XML PI every time to demonstrate-->
<foo>
<bar/>
</foo>
But if you have a large schema and there are different elements with the
same name, a parser's handler will not know how to differentiate the two.
<foo>
<bar>This bar is meant for a widget</bar>
<struct>
<bah>
<bar>This is some other bar</bar>
</bah>
</struct>
<foo>
Because the designers of MXML wanted to allow developers to build custom
components, the namespaces are considered a mandatory piece of the MXML to
avoid collisions (elements in different classes with the same name) in the
event those building custom components accidentally used names used by
MXML (this still throws the odd error WRT the SDK and named methods like
"close()".
Consider an XML fragment like this:
<?xml version="1.0"?>
<document xmlns:foo="http://www.value1.com" >
<!--If you do a "getNamespace()" on the following element, it will
return the value of "www.value1.com"-->
<foo:name>Duane Nickull</foo:name>
<InnerElement xmlns:foo="http://www.value2.com"><name/>
<!-- if you do the same "getNamespace()" operation on the next
line, the value will be www.value2.com-->
<foo:name>Duane Nickull</foo:name>
</InnerElement>
</document>
Parsers always resort to the inner most lexically
scoped namespace. In any event, you would need a conflict of both the
namespace itself AND the namespace value before any harm was done.
I vote to leave MXML as it is from an XML namespace standpoint.
I would suggest one minor fix -> CDATA declarations for anything like CSS
styles that have even the remote possibility of having XML illegal
characters in them one day.
Duane
>
Re: Flex and names spaces in MXML
Posted by David Francis Buhler <da...@gmail.com>.
Omitting the xmlns attributes in MXML would make MXML valid XML, it
just wouldn't prevent namespace collisions (because there is no
namespace prefix).
On Wed, Mar 14, 2012 at 4:47 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Omitting the xmlns attributes in MXML would make MXML not be valid XML.
>
> That's probably an issue.
>
> Does anything currently require them to be 100% valid XML with namespaces (compared to well formed XML missing namespaces)?
>
> Thanks,
> Justin
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Omitting the xmlns attributes in MXML would make MXML not be valid XML.
That's probably an issue.
Does anything currently require them to be 100% valid XML with namespaces (compared to well formed XML missing namespaces)?
Thanks,
Justin
RE: Flex and names spaces in MXML
Posted by Gordon Smith <go...@adobe.com>.
Omitting the xmlns attributes in MXML would make MXML not be valid XML.
- Gordon Smith, Adobe
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Wednesday, March 14, 2012 12:44 AM
To: flex-dev@incubator.apache.org
Subject: Flex and names spaces in MXML
Hi,
I think that you can define public namespaces in actionscript like so:
public namespace fx = "http://ns.adobe.com/mxml/2009"; public namespace s = "library://ns.adobe.com/flex/spark";
public namespace mx = "library://ns.adobe.com/flex/mx";
Is there any way we can define the common namespaces somewhere (in UIComponent??) so we don't have to define them all the time in MXML? This may become more of an issue as we add a few more name spaces.
Ideally it would be nice (I think) to just do this:
<s:Application width="100%">
Instead of:
<s:Application width="100%"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
Perhaps we have the MXML compiler automatically create these namespaces if they are not defined? (Once it gets donated of course.)
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It doesn't really work that way.
I'm not saying have no namespaces but just define the likely ones by default.
You would still have to specify <mx:List /> or <s:List /> to indicate which list component you want to use.
And of course you still could define your own name spaces.
> So, if this problem was to be addressed, maybe it would be possible to add
> a compiler argument `-default-namespace` that would have to match a
> namespace from those available to the project and would be implied when
> resolving components.
That sounds like an idea worth investigating.
Thanks,
Justin
Re: Flex and names spaces in MXML
Posted by Left Right <ol...@gmail.com>.
It doesn't really work that way. Especially not since Flex 4.
There was an attempt at having no namespace at all and to assume mx
namespace to be the default. But since in Flex 4 there are a lot of
components in the SDK that come in two flowers, but with same names, but
not only that, the code generation has changed, you must have the namespace
specified on the top-level component tag.
Now, what is the use of the namespace in MXML: you should probably first
find all the *-manifest.xml files in the framework folder of the SDK to see
where it comes from. So, namespace maps arbitrary components under the same
"package". I can imagine this was a more of an forced move, because,
originally, MXML would understand namespaces to be the package names. For
example:
<flash:Sprite xmlns:flash="flash.display.*"/>
Now imagine an average MXML template - it may use components from tens of
different packages, so your top-level tag would looks something like:
<flex:Application
xmlns:flex="mx.core.*"
xmlns:bindings="mx.bindings.*"
xmlns:utils="mx.utils.*"
. . .
>
. . .
</flex:Application>
That's another... doubtingly useful feature of MXML design... while in AS3
you only need to import into scope once, and you don't need to mention the
source, unless there is ambiguity, XML format doesn't allow this kind of
approach (why use XML for programming language templates is another tough
question, I'm not trying to ask at the moment...)
So, ultimately, that would be a step backwards to the situation, where you
have to write the package and the imported class all the time.
The compiler attribute `-namespace` came to rescue: so you can group
classes into the same namespace regardless of their actual
namespace/package. This is still not as good as normal AS3 way to deal with
the problem, but it reduces the verbosity, so that's the reason to use it.
So, if this problem was to be addressed, maybe it would be possible to add
a compiler argument `-default-namespace` that would have to match a
namespace from those available to the project and would be implied when
resolving components. So you would only need to specify a namespace for the
foreign code.
This has it's downside as it might be too complex for an average user to
configure and is prone to subtle errors - results of naming collisions.
Best.
Oleg