You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axis-cvs@ws.apache.org by ch...@apache.org on 2007/05/04 09:09:38 UTC
svn commit: r535116 - in
/webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb:
adb-advanced.html adb-codegen-integration.html adb-howto.html
adb-tweaking.html
Author: chatra
Date: Fri May 4 00:09:37 2007
New Revision: 535116
URL: http://svn.apache.org/viewvc?view=rev&rev=535116
Log:
reviewed and committing patch in https://issues.apache.org/jira/browse/AXIS2-2565. Thanks Glen
Modified:
webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-advanced.html
webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-codegen-integration.html
webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-howto.html
webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-tweaking.html
Modified: webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-advanced.html
URL: http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_2/xdocs/%40axis2_version_dir%40/adb/adb-advanced.html?view=diff&rev=535116&r1=535115&r2=535116
==============================================================================
--- webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-advanced.html (original)
+++ webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-advanced.html Fri May 4 00:09:37 2007
@@ -9,21 +9,21 @@
<h1>Advanced Axis2 Databinding Framework Features</h1>
<p>The aim of this section is provide an insight into the newly added
-advanced features of Axis2 Databinding (ADB) Framework.</p>
+advanced features of the Axis2 Databinding (ADB) Framework.</p>
<h2>Content</h2>
<ul>
<li><a href="#typeSupport">xsi:type Support</a></li>
<li><a href="#helper">Helper Mode</a></li>
- <li><a href="#more">More Stuff on ADB?</a></li>
+ <li><a href="#more">Additional ADB Topics</a></li>
</ul>
<a name="typeSupport"></a>
<h2>xsi:type Support</h2>
-<p>This is implemented by adding a extension maping class. The code that
+<p>This is implemented by adding a extension mapping class. The code that
calls the extension mapper is generated inside the Factory.parse method of
-the beans and gets active when the xsi:type attribute is present. The
-following code fragment shows how the generated type mapper looks like : </p>
+the beans and gets activated when the xsi:type attribute is present. The
+following code fragment shows what the generated type mapper looks like : </p>
<pre> public static java.lang.Object getTypeObject(java.lang.String namespaceURI,
java.lang.String typeName,
javax.xml.stream.XMLStreamReader reader) throws java.lang.Exception{
@@ -38,10 +38,10 @@
<p>Inside every Factory.parse method, the extension mapper gets called when a
xsi:type attribute is encountered <strong>and</strong> that type is not the
-type that is being parsed.</p>
+type that is currently being parsed.</p>
<p>The following code fragment shows how the ADB deserialize method calls the
-mapper class : </p>
+mapper class: </p>
<pre>
if (reader.getAttributeValue("http://www.w3.org/2001/XMLSchema-instance","type")!=null){
java.lang.String fullTypeName = reader.getAttributeValue("http://www.w3.org/2001/XMLSchema-instance",
@@ -61,11 +61,13 @@
}
}</pre>
-<p>This should make the xsi:type based parsing possible and should
-result in proper xsi:type based serializations at runtime.</p>
+<p>This makes xsi:type based parsing possible and results
+in proper xsi:type based serializations at runtime.</p>
+
+<p>By default, the mapping package is derived from the targetnamespace of the
+first schema that is encountered. The package name can also be explicitly set
+by a CompilerOption:</p>
-<p>This is automatically done but the package name for the mapper class can
-be set as an CompilerOption.</p>
<pre>
CompilerOptions compilerOptions = new CompilerOptions();
compilerOptions.setWriteOutput(true);
@@ -81,16 +83,13 @@
}
</pre>
-<p>When the mapping package is not specified it is derived from the
-targetnamespace of the first schema that is encountered.</p>
-
<a name="helper"></a>
<h2>Helper mode</h2>
<p>Helper mode is a fairly new feature. In the helper mode, the beans are
plain Java beans and all the deserialization/serialization code is moved to a
helper class. For example, the simple schema mentioned in the ADB-howto
-document will yield four classes for the two that has been previously seen.</p>
+document will yield four classes instead of the two previously generated:</p>
<ol>
<li>MyElement.java</li>
<li>MyElementHelper.java</li>
@@ -98,17 +97,18 @@
<li>SOAPStructHelper.java</li>
</ol>
-<p>The helpers basically contain all the code that went into the ADBBeans.
-Hence the beans in the helper mode are pretty much readable than the rest.
-Also note that the helper mode is available only if you are in the unpacked
-mode. The code generator by default does not expand the classes.</p>
+<p>The helpers basically contain all the serialization code that otherwise
+would go into the ADBBeans. Hence the beans in the helper mode are much
+more simplified. Also note that the helper mode is available only if you
+are in unpacked mode. The code generator by default does not expand
+the classes.</p>
<p>Helper mode can be switched on by using the setHelperMode method
-in CompilerOptions : </p>
+in CompilerOptions: </p>
<pre><strong>compilerOptions.setHelperMode(true);</strong></pre>
<a name="more"></a>
-<h2>More Stuff on ADB?</h2>
+<h2>Additional ADB Topics</h2>
<ul>
<li><a href="adb-tweaking.html">Tweaking the ADB Code Generator</a>-
explains available mechanisms to extend ADB and possibly adopt it to
Modified: webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-codegen-integration.html
URL: http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_2/xdocs/%40axis2_version_dir%40/adb/adb-codegen-integration.html?view=diff&rev=535116&r1=535115&r2=535116
==============================================================================
--- webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-codegen-integration.html (original)
+++ webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-codegen-integration.html Fri May 4 00:09:37 2007
@@ -7,7 +7,7 @@
</head>
<body>
<h1>ADB Integration With Axis2</h1>
-<p>This document will assist you to write an extension using the
+<p>This document will assist you in writing an extension using the
integrator in order to integrate ADB with Axis2.</p>
<h2>Content</h2>
<ul>
@@ -27,8 +27,8 @@
<a name="select_modes" id="select_modes"></a>
<h2>Selection of Generation Modes for ADB</h2>
<p>The extension sets the options for the code generator via the
-CompilerOptions, depending on the users settings. The following
-table summarizes the use of options. Please refer the <a href=
+CompilerOptions, depending on the user's settings. The following
+table summarizes the use of options. Please refer to the <a href=
"adb-howto.html" target="_blank">ADB-How to document</a> for the
different generation modes and their descriptions.</p>
<table border="1">
@@ -38,7 +38,7 @@
<td><strong>Selected code generation parameters</strong></td>
</tr>
<tr>
-<td>None (no other parameter than the mandatory ones)</td>
+<td>None (no parameter other than mandatory ones)</td>
<td>wrapClasses=false,writeClasses=false</td>
</tr>
<tr>
@@ -51,9 +51,8 @@
</tr>
</tbody>
</table>
-<p>If the users want to override these settings manually, they need
-to use the following parameters in the command line (prefixed with
--E)</p>
+<p>The following parameters (prefixed with -E) can be used to
+override these settings manually:</p>
<table border="1">
<tbody>
<tr>
@@ -70,24 +69,24 @@
<tr>
<td>w</td>
<td>true, false</td>
-<td>Sets the packing flag. if true the classes will be packed.</td>
+<td>Sets the wrapping flag. if true the classes will be wrapped.</td>
</tr>
</tbody>
</table>
-<p>Note that these parameters have no relevant long names and MUST
+<p>Note that these parameters have no corresponding long names and MUST
be prefixed with a -E to be processed by the code generator. For
-example</p>
+example:</p>
<pre>
WSDL2Java .... -Er true
</pre>
<a name="remember" id="remember"></a>
<h2>Things to Remember</h2>
<ol>
-<li>SimpleDBExtension is made to process requests only when the
-databinding framework is specified as ADB (using the switch -d adb
-). In the most recent release, the default has been set as ADB and
-hence if the -d option is missing then the databinding framework
-will be ADB.</li>
+<li>SimpleDBExtension is for the ADB databinding framework only and
+will process requests only when this framework is specified during
+code generation (using the switch -d adb). In the most recent
+release, the default has been set as ADB and hence if the -d option
+is missing then the databinding framework will be ADB.</li>
</ol>
<hr />
</body>
Modified: webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-howto.html
URL: http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_2/xdocs/%40axis2_version_dir%40/adb/adb-howto.html?view=diff&rev=535116&r1=535115&r2=535116
==============================================================================
--- webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-howto.html (original)
+++ webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-howto.html Fri May 4 00:09:37 2007
@@ -8,7 +8,7 @@
</head>
<body lang="en" xml:lang="en">
<h1>Axis2 Databinding Framework</h1>
-<p>This document aims to provide the architectural overview of the
+<p>This document aims to provide an architectural overview of the
Axis2 Databinding Framework (referred to as ADB from here onwards)
and be a guide to anyone who wants to use and modify ADB. The
information is presented under the following topics.</p>
@@ -37,26 +37,27 @@
<a name="intro" id="intro"></a>
<h2>Introduction</h2>
<p>The objective of the Axis2 Databinding framework is to provide a
-lightweight and simple schema compiler/ Java bean generator for
-Axis2. By no means it's to be a fully functional schema compiler
+lightweight and simple schema compiler/Java bean generator for
+Axis2. By no means is it intended to be a fully functional schema compiler
like XMLBeans. Note that ADB is written in a fashion that allows it
to be used as a stand-alone schema compiler and also to be extended
to generate code for other languages.</p>
<a name="archi" id="archi"></a>
<h2>Architectural Overview</h2>
<p>ADB is built on a modular architecture that allows it to utilize
-a pre configured writer depending on the configuration.The 'big
+a pre-configured writer depending on the configuration. The 'big
block diagram' for the code generator architecture is depicted
-below</p>
+below.</p>
<p><img src="images/ADB.jpg" alt="ADB architecture" /></p>
-<p>ADB utilizes the WS-commons XmlSchema library for reading the
-Schema. The object model for the schema comes in the form of an
+<p>ADB utilizes the WS-Commons <a href="http://ws.apache.org/commons/XmlSchema/index.html">
+XmlSchema library</a> for reading the Schema. The object
+model for the schema comes in the form of an
XmlSchema object. The schema compiler keeps an instance of the
writer (in the default case it's the JavaBeanWriter) which actually
writes the classes. The writers may use whatever technique they
prefer, in the case of the JavaBeanWriter, it uses an XSLT
template. The SchemaCompiler also uses a typemapper object that
-tells it what classnames to be used for the QNames that it
+tells it what classnames to use for the QNames that it
encounters. This type mapper is also part of the configuration and
the users can override the default type mapper by overriding the
property setting.</p>
@@ -64,24 +65,24 @@
<h2>Code and Dependencies</h2>
<p>As explained in the previous section, the schema compiler
depends on the WS-Commons XmlSchema library. The XSLT
-transformations are dependent on the JVM's DOMimplementation
-(either crimson or xerces) which means that the underlying JVM
+transformations are dependent on the JVM's DOM implementation
+(either Crimson or Xerces) which means that the underlying JVM
should be 1.4 or higher. Apart from that ADB has no dependencies on
any other special jar files. The code for the schema compiler is
completely in the <strong>org.apache.axis2.schema.*</strong>
package. This package resides in the codegen module of the Axis2
source tree.</p>
-<p>Following are the important classes and files:</p>
+<p>The following are the important classes and files of ADB:</p>
<ol>
<li><strong>SchemaCompiler</strong> - The work horse that really
compiles the schema into classes.</li>
-<li><strong>BeanWriter</strong> - BeanWriter represents the kind of
-interface the SchemaCompiler accepts as a writer. The writer needs
-to handle the actual writing of the clasess</li>
+<li><strong>BeanWriter</strong> - BeanWriters handle the the actual
+rendering of the classes. BeanWriter is the interface that
+writers need to implement in order to be used by the SchemaCompiler. </li>
<li><strong>JavaBeanWriter</strong> - The default implementation of
the BeanWriter interface.</li>
<li><strong>TypeMap</strong> - represents the interface that the
-schema compiler looks towards to find classes</li>
+schema compiler uses to find class names for a given QName.</li>
<li><strong>JavaTypeMap</strong> - the default implementation of
the TypeMap</li>
<li><strong>ADBBeanTemplate.xsl</strong> - the XSLtemplate the
@@ -94,29 +95,29 @@
<strong>axis2-adb-codegen-{$version}.jar</strong> inside the target
folder which is directly usable when the ADB schema compiler is
required.</p>
-<p>The runtime dependancies for the ADB generated classes is in the
+<p>The runtime dependencies for the ADB generated classes is in the
Axis2 adb module and the kernal module. Hence to compile and work with the generated
classes the <strong>axis2-adb-{$version}.jar</strong> and <strong>axis2-kernal-{$version}.jar</strong> needs to be
-in the classpath apart from other dependancies like the StAX,
-Axiom,Commons-logging and javax.activation.</p>
+in the classpath in addition to other dependencies such as StAX,
+Axiom, Commons-logging and javax.activation.</p>
<a name="code_gen" id="code_gen"></a>
<h2>Invoking the ADB Code Generator</h2>
<a name="schema_compiler"></a>
<h3>As a Standalone Schema Compiler</h3>
-<p>ADB comes with a main class XSD2Java that allows the schemas to
-be compiled just by giving the schema file reference.This main
-class is pretty much primitive and does not provide much control
+<p>ADB comes with a XSD2Java code generator that allows the schemas to
+be compiled just by giving the schema file reference. This main
+class is presently rather primitive and does not provide much control
over the code generation process. This is bound to improve in the
near future.</p>
-<p>Code generator accepts the following parameters</p>
+<p>XSD2Java accepts the following parameters:</p>
<ol>
<li>The Schema file name - This should be a complete file name
pointing to the local file system</li>
<li>The output folder name - This should be the name of a folder
within the local file system</li>
</ol>
-<p>Since the main class has no validations built in, the compiler
-is likely to cough up an unexpected error message if these
+<p>Since the code generator presently has no validations built into it, the compiler
+is likely to show various error messages if these
parameters are not supplied properly.</p>
<a name="api" id="api"></a>
<h3>Through the API</h3>
@@ -130,7 +131,7 @@
object. This compilerOptions object is more of a holder for the
parameters that are passed to the SchemaCompiler. The only
mandatory parameter in the CompilerOptions is the output
-directory</p>
+directory.</p>
</li>
<li><strong>SchemaCompiler - Compile(XMLSchema schema)</strong>
<p>The compile method to call for a single schema. The expected
@@ -145,7 +146,7 @@
through the API, the following classes would be helpful. One would
also need an understanding of the generation modes of the ADB
schema compiler when using it through the API. Hence the following
-section includes a brief description of the generation modes .</p>
+section includes a brief description of the generation modes.</p>
<ul>
<li><strong>org.apache.axis2.schema.XSD2Java</strong></li>
<li><strong>org.apache.axis2.schema.ExtensionUtility</strong></li>
@@ -157,13 +158,14 @@
<ol>
<li><strong>Integrated Mode</strong>
<p>In this mode the classes are generated as inner classes of the
-stub, message receiver or the interface. The ADB framework refrains
-from writing the classes but provides a map of DOM document objects
-that contains the model for the databinding class. The implementers
-are free to use the models for their needs. The Axis2 codegen
-engine parses these documents within its own XSLT parser to create
-the necessary code.</p>
-<p>Integrated mode is supposed to be used by the tool builders.</p>
+stub, message receiver or the interface. The ADB framework does
+not actually write the classes but instead provides a map of DOM
+document objects that contains the model for the databinding classes.
+The Axis2 codegen engine in turn parses these documents within
+its own XSLT parser to create the necessary classes.
+Implementers are free to use these models differently for their own particular needs.
+</p>
+<p>Integrated mode is intended to be used by tool builders.</p>
</li>
<li><strong>Wrapped Mode</strong>
<p>In the wrapped mode, the ADB databinder generates one class that
@@ -171,7 +173,7 @@
number of classes need to be limited.</p>
</li>
<li><strong>Expanded Mode</strong>
-<p>This is the usual mode where the codegenerator generates a class
+<p>This is the usual mode where the code generator generates a class
for each of the outer elements and the named complex types. The
command line tool (XSD2Java) always generates code in the expanded
mode.</p>
@@ -180,7 +182,7 @@
<p>The rules for generating code (described in the next section)
applies regardless of the mode. Switching these modes can be done
by passing the correct options via the CompilerOptions object. The
-following is table lists the options and the consequences of using
+following table lists the options and the effects of using
them.</p>
<table border="1" summary="Options and descriptions">
<tbody>
@@ -203,13 +205,13 @@
<tr>
<td>mapperClassPackage</td>
<td>The package name for the mapper class. Please see the advanced
-section for details of the mapper class</td>
+section for details of the mapper class.</td>
</tr>
<tr>
<td>helperMode</td>
<td>The switch that determines whether to switch to helper mode or
-not. Please see the advanced section for details of the helper
-mode</td>
+not. Please see the advanced section for details of helper
+mode.</td>
</tr>
<tr>
<td>ns2PackageMap</td>
@@ -221,21 +223,21 @@
<a name="deep" id="deep"></a>
<h2>Deep into Generated Code</h2>
<p>When the schema compiler is invoked (one-way or another) it
-generates code depending on the following rules</p>
+generates code depending on the following rules:</p>
<ol>
<li>All named complex types become bean classes. Any attribute or
element encapsulated in this complex type will become a field in
the generated class. Note that the support for constructs other
-than the sequence and all is not yet implemented.</li>
+than xsd:sequence and xsd:all is not yet implemented.</li>
<li>All top level elements become classes. This is a rather
-questioning feature since unless classes are generated for the top
-level elements the handling of elements become difficult and
+obvious feature since unless classes are generated for the top
+level elements the handling of elements becomes difficult and
messy!</li>
<li>SimpleType restrictions are handled by replacing the relevant
type with the basetype</li>
</ol>
<p>Once the code is generated according to the rules it looks like
-the following. Consider the following piece of schema</p>
+the following. Consider the following schema:</p>
<pre>
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://soapinterop.org/types" targetNamespace="http://soapinterop.org/types"
@@ -254,9 +256,9 @@
<p>For comprehension let us consider the expanded mode for the code
generator. Unless specifically mentioned, the rest of this document
assumes that the expanded mode of the code generation is used. This
-particular schema generates the following two classes in the
+particular schema will generate the following two classes in the
designated package, which in this case would be
-<strong>org.soapinterop.types</strong>. This package is derived
+<strong>org.soapinterop.types</strong>. The package name is derived
from the target namespace of the schema.</p>
<ol>
<li>MyElement.java</li>
@@ -269,10 +271,10 @@
respectively. MyElement on the other hand has a single field
representing the SOAPStruct object that it encapsulates.</p>
<p>The most important aspect of the generated code is that it
-encapsulates two methods for creation and serializing the beans.
+encapsulates two methods for creating and serializing the beans.
Note that to make this work, the generated beans implement the
<strong>org.apache.axis2.databinding.ADBBean</strong> interface</p>
-<p>The creator and serializer methods look like the following</p>
+<p>The creator and serializer methods look like the following:</p>
<ul>
<li>
<pre>
@@ -285,12 +287,12 @@
<ol>
<li>An element based bean class (like MyElement.java in the
example) will <strong><em>ignore the passed in QName</em></strong>.
-Instead of using the passed in QName it'll utilize it's own QName
+Instead of using the passed in QName it'll utilize its own QName
which is embedded in the class under the constant MY_QNAME, during
-the code generation. Hence it is usual to call getPullparser with a
-null for the elements.</li>
-<li>A ComplexType based bean class(like SOAPStruct.java in the
-example) will use the passed in QName to return an instance of the
+the code generation. Hence it is usual to call getPullparser() with a
+null parameter for elements.</li>
+<li>A ComplexType based bean class (like SOAPStruct.java in the
+example) will use the passed-in QName to return an instance of the
ADBpullparser. This will effectively wrap the elements inside with
an element having the passed QName</li>
</ol>
@@ -304,11 +306,10 @@
</pre>
<p>This method returns an OMElement representing the ADB bean object.</p>
<ol>
-<li>There is an annonymous ADBDataSource class has implemented, in side the getOMElement method.
-This annonymous class implements the serialize method where the serializing logic is written,
-for that pirticular bean class. Fianlly an OMSourcedElementImpl object with the
-above annonymous class type object as the data source, is
-returned.
+<li>Inside the getOMElement method an anonymous ADBDataSource class is created.
+This anonymous class implements a serialize() method where the serialization logic for that
+particular bean class is handled. Finally an OMSourcedElementImpl object with the
+above anonymous class type object as the data source is returned.
</li>
</ol>
</li>
@@ -331,9 +332,9 @@
throws java.lang.Exception
</pre>
<p>Also note that the above parse method is available in the
-<strong>Factory</strong> class generated into the relevant top
-level class.Hence one will have to get the static Factory instance
-before calling the parse methods</p>
+<strong>Factory</strong> nested class within the relevant top
+level class. Hence one will have to get the static Factory instance
+before calling the parse method.</p>
</li>
</ul>
<a name="example" id="example"></a>
@@ -347,9 +348,9 @@
</myElement>
</pre>
<p>Enthusiastic readers might already have figured out that this
-piece of XML complies to the Schema mentioned above. The following
-piece of code shows how to build a populated instance of MyElement
-with this fragment of XML</p>
+XML fragment complies with the Schema mentioned above. The following
+code snippet shows how to build a populated instance of MyElement
+with the XML above:</p>
<pre>
XMLStreamReader reader = XMLInputFactory.newInstance().
createXMLStreamReader(
@@ -357,8 +358,8 @@
MyElement elt = MyElement.Factory.parse(reader);
</pre>
<p>
-Optionally above xml fragment can be reproduced with the following
-code fragment
+Optionally, the above xml fragment can be reproduced with the following
+code fragment:
<P>
<pre>
OMElement omElement = myElement.getOMElement
@@ -366,8 +367,8 @@
String xmlString = omElement.toStringWithConsume();
</pre>
<p>Although this example takes on the tedious effort of creating a
-reader out of the String, inside the Axis2 environment an
-XMLStreamReader can be direclty asked from the OMElement! Hence, the
+reader out of a String, inside the Axis2 environment an
+XMLStreamReader can be directly obtained from the OMElement! Hence, the
parse method becomes a huge advantage for hassle free object
creation.</p>
<p>Similarly the reader obtained from the object can also be
@@ -383,16 +384,16 @@
use ADB for something serious.</p>
<a name="limitation" id="limitation"></a>
<h2>Known Limitations</h2>
-<p>ADB is meant to be a 'Simple' databinding framework and was not meant to compile all types of schemas. The following limitations
-are the most highlighted.</p>
+<p>ADB is meant to be a 'Simple' databinding framework and was not meant to compile all types of schemas.
+The following limitations are the most highlighted.</p>
<ol>
-<li>Complex Extensions and Restrictions.</li>
+<li>Complex Type Extensions and Restrictions.</li>
</ol>
<a name="more" id="more"></a>
<h2>Want to Learn More?</h2>
<ul>
<li><a href="adb-advanced.html">Advanced features of the ADB code
-generator</a> - explains xsi:type based desrialization and helper
+generator</a> - explains xsi:type based deserialization and helper
mode</li>
<li><a href="adb-tweaking.html">Tweaking the ADB Code
Generator</a> - explains available mechanisms to extend ADB and
Modified: webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-tweaking.html
URL: http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_2/xdocs/%40axis2_version_dir%40/adb/adb-tweaking.html?view=diff&rev=535116&r1=535115&r2=535116
==============================================================================
--- webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-tweaking.html (original)
+++ webservices/axis2/branches/java/1_2/xdocs/@axis2_version_dir@/adb/adb-tweaking.html Fri May 4 00:09:37 2007
@@ -21,8 +21,8 @@
</ul>
<a name="intro" id="intro"></a>
<h2>Introduction</h2>
-<p>ADB is written with future extensions in mind, with a clear and
-flexible way to extend or modify it's functionality. Available
+<p>ADB was written with future extensibility in mind, with a clear and
+flexible way to extend or modify its functionality. Available
mechanisms to extend ADB and possibly adopt it to compile schemas
to support other languages are described below.</p>
<a name="config" id="config"></a>
@@ -43,7 +43,7 @@
<p>This specifies the template to be used in the BeanWriter. The
BeanWriter author is free to use any mechanism to write the classes
but the default mechanism is to use a xsl template. This property
-may be left blank if the BeanWriter implementation does not require
+may be left blank if the BeanWriter implementation does not use
a template.</p>
</li>
<li>schema.bean.typemap
@@ -59,7 +59,7 @@
<p>The first, most simple tweak for the code generator could be to
switch to plain bean generation. The default behavior of the ADB
framework is to generate ADBBeans, but most users, if they want to
-use ADB as a standalone compiler, would love to have plain java
+use ADB as a standalone compiler, would prefer to have plain java
beans. This can in fact be done by simply changing the template
used.</p>
<p>The template for plain java beans is already available in the
@@ -79,14 +79,14 @@
<a name="advanced_tweak" id="advanced_tweak"></a>
<h2>A More Advanced Tweak - Generate Code for Another Language</h2>
<p>To generate code for another language, there are two main
-components to be written.</p>
+components that need to be written.</p>
<ul>
<li>The BeanWriter
<p>Implement the BeanWriter interface for this class. A nice
example is the
<strong>org.apache.axis2.schema.writer.JavaBeanWriter</strong>
-which has a lot of reusable code. In fact if the language is OOP
-based (such as C# or even C++), one would even be able to extend
+which has a lot of reusable code. In fact if the target language
+is object-oriented (such as C# or even C++), one would even be able to extend
the JavaBeanWriter itself.</p>
</li>
<li>The TypeMap
@@ -98,12 +98,12 @@
support another language.</p>
</li>
</ul>
-<p>Surprisingly, this is enough to have other language support for
+<p>Surprisingly, this is all that needs to be done to have other language support for
ADB. Change the configuration and you are ready to generate code
for other languages!</p>
<p>This tweaking guide is supposed to be a simple guideline for
anyone who wishes to dig deep into the mechanics of the ADB code
-generator. Users are free experiment with it and modify the schema
+generator. Users are free to experiment with it and modify the schema
compiler accordingly to their needs. Also note that the intention
of this section is <em>not</em> to be a step by step guide to
custom code generation. Anyone who wish to do so would need to dig
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org