peter reilly wrote: > Yes, but more infrastructure is needed. > (Also, in current ant cvs, ComponentHelper is not used).
It's not used because I wanted some feedback on its interfaces. The code is (almost) the same with the one in Project, and it requires one little step to be enabled and pass the ns. > My knowledge on this subject is very small, but here > is my understanding (based on looking at jelly source > code). > > To support XML ns one needs to know the uri associated > with the namespace prefix. If you look in ProjectHelper2, in the inner ElementHandler - the onStartElement() is called with the URI, tag, qname. It creates UnknownElement(). All that's missing is an "unknownElement.setNamespace( uri )" ( and adding the getter and setter in UE ). > The same prefix may be associated with different uri in > the course of processing an xml file. The prefix is usually not relevant. ElementHelper gets it, but I don't think it should use it in any way. > By overriding sax.helpers.DefaultHandler#startPrefixMapping > and #stopPrefixMapping, one can find out when the prefix > mapping space is active and when it is terminated. This is what > jelly does. I'm not sure what jelly does, but SAX2 startElement() callback has the info we need ( i.e. the URI ), I don't thik we really need the prefix. > It would be more difficult (I may be wrong here) for ant to use > this information as resolving of most of tags is done after the xml > parsing has completed. When the UE is created we have the URI - and it's trivial to add it. > It is not necessary to do this as .DefaultHander#startElement > does pass the uri that is associated with the element. This > could get stored in the UnknownElement and used for > name resolution. (Attributes would also be be considered). > > Since namespace processing is active, the code should > use getLocalName and not getQName. True ( actually there is no getLocalName/getQName - the sax callback has both ). > To support antlibs, I am thinking that one could have a > mapping table per uri (for element tags), either within > the ComponentHelper, or have a ComponentHelper per uri. ComponentHelper's role is to create components - using URI or whatever else it wants. It can maintain one table per URI - or you can have one CH per URI ( I preffer the first option ). One use case I had in mind for CH was a namespace like "jmx:...", where the JMXComponentHelper would use the JMX metadata to create the task ( no ant table ). That's clearly outside the scope of antlib or ant ( it's just a custom task ). Costin > > Peter > > > On Friday 02 May 2003 15:42, Costin Manolache wrote: >> peter reilly wrote: >> >> \>> > example: >> >> > <typedef myfileset mypath anttest etc ..> >> >> > <copy todir="output"> >> >> > <fileset ant-type="myfileset" dir="src" >> >> > newattribute="MyFileSet attribute"/> >> >> > </copy> >> >> > >> >> > <anttest> >> >> > <path ant-type="mypath" path="build.xml" >> >> > newattribute="MyPath attribute"/> >> >> > </anttest> >> >> >> >> I assume you meant to write "ant:type" instead of "ant-type"... >> > >> > No... >> > Ant does not have the infrastructure at the moment to support XML >> > namespaces, and their associated contexts. >> >> AFAIK ant _does_ have now the infrastructure to support and use >> XML namespaces. >> >> It is not using it - because we don't know yet what's the best way >> to do it, but AFAIK the infrastructure exists. >> >> ProjectHelper2 uses SAX2, it preserves namespaces in UnknownElement and >> the code for creation of tasks/types (ComponentHelper) receives the >> namespace and the name. CH allows plugins - i.e. any task can hook >> into the component creation and provide it's own mechanism, so you >> should be able to implement whatever namespace policy you want. >> >> >> Costin >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED]
