Christopher Lenz wrote:

Hi all,

in the light of a final release of 1.6 next week, I think the DynamicConfigurator issue with namespaces needs to be resolved. I can't believe I'm the only one who has a problem with the current implementation, which concatenates the namespace URI and the local name of the element to pass it into DynamicConfigurator#createDynamicElement. This is a change that breaks backwards compatibility because the semantics of the method is changed.

The problem is that no matter what is done backwards compatibility will be broken.
Some people use the name to call Project#createTask() and Project#createDataType() to create a
type. The name passed matches this usage. Also, as noted below, the new XMLFragment can
use this information as well.
The localname is still accessible for tasks written for 1.6 (and with the magic of reflection) and
usable in ant 1.5 places.


Peter


So I wonder: why not just pass the elements local name to the method? That would preserve the semantics from 1.5 (except if the build file writer has decided to use colon-separated prefixes in element names [1]).


If there is a potential DynamicConfigurator implementation that needs the namespace information, such as Stefan's new XMLFragment, it will probably need more information about the namespace anyway (such as prefix mappings). So instead of hacking namespace support into DynamicConfigurator and thereby breaking backwards compatibility, an extended DynamicConfigurator interface should be scheduled for inclusion in a post 1.6 release.

BTW, I have other issues with the namespace support in 1.6, such as pervasive use of the term "uri" for namespace URIs. URI is (IMHO) a *type* of data, but does not convey it's semantics. The semantic is "namespace", the type is "URI". But I'm not gonna push this any further :-P

Are there any good arguments for not changing the DynamicConfigurator code to pass only the local name?

--
Christopher Lenz
/=/ cmlenz at gmx.de


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to