Browse Source

last time

git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@443375 13f79535-47bb-0310-9956-ffa450edef68
master
Matthew Jason Benson 19 years ago
parent
commit
e2e287ea93
1 changed files with 7 additions and 8 deletions
  1. +7
    -8
      docs/manual/CoreTypes/namespace.html

+ 7
- 8
docs/manual/CoreTypes/namespace.html View File

@@ -41,15 +41,15 @@
on the parser. on the parser.
</li> </li>
</ul> </ul>
<p>Use of colons in element names has been discouraged in the past
IIRC, and using any attribute starting with "xml" is actually strongly
<p>Use of colons in element names has been discouraged in the past,
and using any attribute starting with "xml" is actually strongly
discouraged by the XML spec to reserve such names for future use. discouraged by the XML spec to reserve such names for future use.
</p> </p>
<h3>Motivation</h3> <h3>Motivation</h3>


<p>In build files using a lot of custom and third-party tasks, it is <p>In build files using a lot of custom and third-party tasks, it is
easy to get into name conflicts. When individual types are defined, the easy to get into name conflicts. When individual types are defined, the
build file writer can do some name-spacing manually (for example, using
build file writer can do some namespacing manually (for example, using
"tomcat-deploy" instead of just "deploy"). But when defining whole "tomcat-deploy" instead of just "deploy"). But when defining whole
libraries of types using the <code>&lt;typedef&gt;</code> 'resource' attribute, the libraries of types using the <code>&lt;typedef&gt;</code> 'resource' attribute, the
build file writer has no chance to override or even prefix the names build file writer has no chance to override or even prefix the names
@@ -58,7 +58,7 @@


<p> <p>
Adding a 'prefix' attribute to <code>&lt;typedef&gt;</code> might have been enough, Adding a 'prefix' attribute to <code>&lt;typedef&gt;</code> might have been enough,
but XML already has a well-known method for name-spacing. Thus, instead
but XML already has a well-known method for namespacing. Thus, instead
of adding a 'prefix' attribute, the <code>&lt;typedef&gt;</code> and <code>&lt;taskdef&gt;</code> of adding a 'prefix' attribute, the <code>&lt;typedef&gt;</code> and <code>&lt;taskdef&gt;</code>
tasks get a 'uri' attribute, which stores the URI of the XML namespace tasks get a 'uri' attribute, which stores the URI of the XML namespace
with which the type should be associated: with which the type should be associated:
@@ -175,7 +175,7 @@
result in the parameters "a" and "b" being used as parameters to configure the nested "config" element. result in the parameters "a" and "b" being used as parameters to configure the nested "config" element.
</p> </p>
<p>It also means that you can use attributes from other namespaces <p>It also means that you can use attributes from other namespaces
to markup the build file with extra meta data, such as RDF and
to markup the build file with extra metadata, such as RDF and
XML-Schema (whether that's a good thing or not). The same is not true XML-Schema (whether that's a good thing or not). The same is not true
for elements from unknown namespaces, which result in a error. for elements from unknown namespaces, which result in a error.
</p> </p>
@@ -187,7 +187,7 @@
<a href="../develop.html#nestedtype">add type introspection rules</a>: <a href="../develop.html#nestedtype">add type introspection rules</a>:
Ant types and tasks are now free to accept arbritrary named types as Ant types and tasks are now free to accept arbritrary named types as
nested elements, as long as the concrete type implements the interface nested elements, as long as the concrete type implements the interface
expected by the task/type. The most obvioius example for this is the
expected by the task/type. The most obvious example for this is the
<code>&lt;condition&gt;</code> task, which supports various nested conditions, all <code>&lt;condition&gt;</code> task, which supports various nested conditions, all
of which extend the interface <tt>Condition</tt>. To integrate a of which extend the interface <tt>Condition</tt>. To integrate a
custom condition in Ant, you can now simply <code>&lt;typedef&gt;</code> the custom condition in Ant, you can now simply <code>&lt;typedef&gt;</code> the
@@ -204,7 +204,7 @@
<p> <p>
In Ant 1.6, this feature cannot be used as much as we'd all like to: a In Ant 1.6, this feature cannot be used as much as we'd all like to: a
lot of code has not yet been adapted to the new introspection rules, lot of code has not yet been adapted to the new introspection rules,
and elements like the builtin Ant conditions and selectors are not
and elements like Ant's built-in conditions and selectors are not
really types in 1.6. This is expected to change in Ant 1.7. really types in 1.6. This is expected to change in Ant 1.7.
</p> </p>
<h3>Namespaces and Antlib</h3> <h3>Namespaces and Antlib</h3>
@@ -216,6 +216,5 @@
scheme for the namespace URI: the <tt>antlib</tt> scheme, which expects the package name in which a special <tt>antlib.xml</tt> file is located. scheme for the namespace URI: the <tt>antlib</tt> scheme, which expects the package name in which a special <tt>antlib.xml</tt> file is located.
</p> </p>



</body> </body>
</html> </html>

Loading…
Cancel
Save