db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From t...@apache.org
Subject cvs commit: jakarta-ojb/xdocs/stylesheets site.xsl site.vsl
Date Sun, 08 Dec 2002 12:01:04 GMT
thma        2002/12/08 04:01:04

  Modified:    xdocs    tutorial2.xml tutorial1.xml faq.xml
               xdocs/stylesheets site.xsl site.vsl
  Log:
  Applied Tim's patches
  
  Revision  Changes    Path
  1.6       +9 -3      jakarta-ojb/xdocs/tutorial2.xml
  
  Index: tutorial2.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-ojb/xdocs/tutorial2.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- tutorial2.xml	31 Jul 2002 10:45:39 -0000	1.5
  +++ tutorial2.xml	8 Dec 2002 12:01:03 -0000	1.6
  @@ -3,6 +3,7 @@
   
     <properties>
       <author email="thma@apache.org">Thomas Mahler</author>
  +    <author email="tobrien@transolutions.net">Tim O'Brien</author>    
       <title>ObJectRelationalBridge Tutorial - Part 2</title>
     </properties>
   
  @@ -270,15 +271,20 @@
   
           // now perform persistence operations
           Transaction tx = null;
  +
  +        try {
               // 3. open transaction
               tx = odmg.newTransaction();
               tx.begin();
  -
  +            
               // 4. acquire write lock on new object
  -            tx.lock(newProduct, tx.WRITE);
  +            tx.lock(newProduct, Transaction.WRITE);
   
               // 5. commit transaction
               tx.commit();
  +        } catch( LockNotGrantedException lnge ) {
  +        	// Code omitted for tutorial brevity....
  +        }    
       }
   ]]></source>
   
  @@ -322,7 +328,7 @@
               Product toBeEdited = (Product) result.get(0);
   
               // 4. lock the product for write access
  -            tx.lock(toBeEdited, tx.WRITE);
  +            tx.lock(toBeEdited, Transaction.WRITE);
   
               // 5. Edit the product entry
               System.out.println("please edit existing product");
  
  
  
  1.13      +36 -12    jakarta-ojb/xdocs/tutorial1.xml
  
  Index: tutorial1.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-ojb/xdocs/tutorial1.xml,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- tutorial1.xml	4 Dec 2002 21:03:22 -0000	1.12
  +++ tutorial1.xml	8 Dec 2002 12:01:03 -0000	1.13
  @@ -412,13 +412,18 @@
    
     <p>
      Selecting an object from the PersistenceBroker is simple - we must
  -   first create a QueryByExample object.  A QueryByExample object is
  +   first create a QueryByCriteria object.  A QueryByCriteria object is
      created with a new Product object that contains an "id" property
      which has been populated with the id the user supplied.  You will
      notice that all of the other properties of the Product object
  -   remain unpopulated. We have essentially defined a filter by
  -   specifying our desire for a Product object that matches this
  -   product id.
  +   remain unpopulated. We have essentially defined a <b>filter</b> by
  +   populating only the "productId" property - our query will retrieve only
  +   the product that has this productId.  Instead of passing an object to the 
  +   query constructor, we could have passed a Class, and a Criteria object.  
  +   Constructing a Criteria object directly allows you
  +   to specify an arbitrarily complex collection of query criteria such as "productId"
  +   must be greater than 2 and less than 5.  A complex query is demonstrated later in this
  +   tutorial.
     </p>
    
     <p>
  @@ -443,8 +448,8 @@
           Product example = new Product();
           example.setId(id);
   
  -        // 2. build a QueryByExample from this sample instance:
  -        Query query = new QueryByExample(example);
  +        // 2. build a QueryByCriteria from this sample instance:
  +        Query query = new QueryByCriteria(example);
           try
           {
               // 3. start broker transaction
  @@ -500,8 +505,8 @@
           // 1. build an example object with matching primary key values:
           Product example = new Product();
           example.setId(id);
  -        // 2. build a QueryByExample from this sample instance:
  -        Query query = new QueryByExample(example);
  +        // 2. build a QueryByCriteria from this sample instance:
  +        Query query = new QueryByCriteria(example);
           try
           {
               // start broker transaction
  @@ -523,16 +528,35 @@
     ]]></source>
   
     <p>
  -    I did use a QueryByExample in this case as it needs a minimum of code
  -    for primary key lookups. But you can also build a query based on
  -    filter criteria. In this use case the query building would look like
  -    follows:
  +    A QueryByCriteria was used to simplify this tutorial and reduce the
  +    amount of code necessary to demonstrate the essential components of OJB.
  +    It is important to note that one can also build a query based on
  +    filter criteria through the Criteria object.  The following code demonstrates
  +    the construction of a same query using a Criteria object:
     </p>
   
     <source><![CDATA[
       // build filter criteria:
       Criteria criteria = new Criteria();
       criteria.addEqualTo(_id, new Integer(id));
  +    // build a query for the class Product with these filter criteria:
  +    Query query = new QueryByCriteria(Product.class, criteria);
  +    ...
  +  ]]></source>
  +
  +  <p>
  +  	An arbitrary number of criteria can be added to produce very complex 
  +  	queries.  The following code demonstrates a more complex use of the Criteria
  +  	object, one that is not present in this tutorial application.  This code 
  +  	retrieves all products which are priced less than 5.40 (USD, Yen, Euros, etc.)
  +  	and  of which we have at least 2 million in stock: 
  +  </p>
  +
  +  <source><![CDATA[
  +    // build filter criteria:
  +    Criteria criteria = new Criteria();
  +    criteria.addLessThan("price", new Double( 5.40 ));
  +    criteria.addGreaterThan("stock", new Integer( 2000000 ));
       // build a query for the class Product with these filter criteria:
       Query query = new QueryByCriteria(Product.class, criteria);
       ...
  
  
  
  1.10      +495 -493  jakarta-ojb/xdocs/faq.xml
  
  Index: faq.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-ojb/xdocs/faq.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- faq.xml	29 Jul 2002 15:28:50 -0000	1.9
  +++ faq.xml	8 Dec 2002 12:01:04 -0000	1.10
  @@ -1,131 +1,142 @@
   <?xml version="1.0"?>
   <document>
   
  -  <properties>
  -    <author email="thma@apache.org">Thomas Mahler</author>
  -    <title>ObJectRelationalBridge FAQ</title>
  -  </properties>
  -
  -<body>
  -
  -<section name="frequently asked questions">
  -
  -<subsection name="Help! I don't get OJB installed!">
  -	<ul>
  -		<li>
  -			Please read the document <a href="quickstart.html">quickstart.html</a>.
  -		</li>
  -		<li>
  -			Be sure to follow all steps mentioned in that document.
  -		</li>
  -		<li>
  -			Don't try to use any shortcuts. Don't try to do it in a
  -			somewhat different way.
  -		</li>
  -		<li>
  -			Read the respective documentation before you try to 
  -			<a href="platforms.html">run OJB against your target database</a> 
  -			and before you try to
  -			<a href="deployment.html">deploy OJB within your specific target environment</a>.
  -		</li>		
  -	</ul>
  -</subsection>
  -
  -<subsection name="Help! I still don't get OJB installed!">
  -<p>
  -	The following answer is quoted from the OJB user-list. It is from a
  -	reply to a user who had serious troubles in getting started with OJB.
  -</p>
  -<p>
  -	I would say it was stupid not to understand OJB. How can you know what
  -	another programmer wrote. I've been a Java programmer for quite some time
  -	and I could show you stuff I wrote that I know you wouldn't understand.
  -	I'll just break it down the best I can on what, where and why.
  -</p>
  -<p>	
  -	OJB is a data persistence layer for Java. I'll just use an example of how I
  -	use it. I have an RDMS. I would like to save Java object states to this
  -	database and I would like to be able to search this information as well. If
  -	you serialize objects it's hard to search and if you use SQL it won't work
  -	with any different database. Plus it's a mess having to work with all that
  -	SQL in your code. And by using SQL you don't get to work with just Java
  -	objects. But, with OJB your separated from having to work outside the
  -	object world and unlike serialization you can preform SQL like searches on
  -	your data. Also, there's things like caching and connection pooling in OJB
  -	that help with performance. After setting up OJB you will us either ODMG or
  -	JDO to access your information in a object centric manner. ODMG is a
  -	standard for the api for accessing your data. That means you can use any
  -	ODMG compliant api if you don't want to use OJB. The JDO part is like ODMG
  -	except it's the SUN JDO standard. I use ODMG because the JDO interface is
  -	not ready yet.
  -</p>
  -<p>	
  -	OJB is easy to use. I'll just break it down into two sides. There's the
  -	side your writing your code for your application and there's the side that
  -	you configure to make OJB connect to your database. Starting with your
  -	application side, all that is needed is to use the interface you wish. I
  -	use ODMG because JDO is not complete yet. Here's a link to the ODMG part
  -	with some code for examples. http://jakarta.apache.org/ojb/tutorial2.html
  -	That's all you need on the application side. Next there's the configuration
  -	side. This is the one your fighting with. Here you need to setup the core
  -	tables for OJB and you will define the classes you wish to store in your
  -	database.
  -</p>
  -<p>	
  -	First thing to do is to build the cvs's with the default database HSQL,
  -	because you know it will work. If you get past this point you should have a
  -	working OJB compiled. Now if your using JDK 1.4 you will need to set in
  -	build.properties JDBC=+JDBC30 and do a build.sh preprocess first. Next you
  -	will do a build.sh junit and this will build OJB and test everything for
  -	you. If you get a build successful then your in business. Then you will
  -	want to run build.sh jar to create the OJB jar to put in your /lib. You
  -	will need a couple other jars in you /lib directory to make it all work.
  -	See this page for those. http://jakarta.apache.org/ojb/deployment.html
  -</p>
  -<p>	
  -	Next you will need some xml and configuration files in your class path for
  -	OJB. You will find those files under {$OJB_base_dir}/target/test/ojb. All
  -	the repository.xml's and OJB.properties for sure. With all these files in
  -	place with your application you should be ready to use OJB and start
  -	writing your application.
  -</p>
  -<p>	
  -	Finally you will want to setup your connection to your database and define
  -	your classes you will be storing in your database. In the repository.xml
  -	file you can configure your JDBC parameters so OJB can connect to your
  -	database. You will also need your JDBC jar somewhere in your class path.
  -	Then you will define your classes in the repository_user.xml file. Look
  -	here for examples. http://jakarta.apache.org/ojb/tutorial1.html Note you
  -	will want to comment out the junit part in repository.xml because it's just
  -	for testing.
  -</p>
  -<p>	
  -	The final thing to do is to make sure the OJB core tables are in your
  -	database. Look on this page for the core tables.
  -	http://jakarta.apache.org/ojb/platforms.html. These core tables are used by
  -	OJB to store internal data while it's running. It needs these. Then there's
  -	the tables you define. The ones you mapped in the repository_user.xml file.
  -</p>
  -<p>	
  -	Sorry if any of this is off. OJB is growing so fast that it's hard to keep
  -	up with all changes. The order I gave the steps in is just how I would
  -	think it's understood better. You can go in any order you want. The steps
  -	I've shown are mostly for deployment. Hope this helps you understand OJB a
  -	little better. I'm not sure if this is what your wanting or not.
  -</p>
  -</subsection>
  -
  -
  -
  -<subsection name="Why OJB, why yet another O/R mapping tool?">
  -<p>
  -  here are some outstanding OJB features:
  -  <ul>
  -    <li>It's fully ODMG 3.0 compliant</li>
  -    <li>It will have a full JDO implementation</li>
  -    <li>It's higly scalable (Loadbalanced Multiserver scenario)</li>
  -    <li>It provides multiple APIs:
  -      <ul>
  + <properties>
  +  <author email="thma@apache.org">Thomas Mahler</author>
  +  <author email="tobrien@transolutions.net">Tim O'Brien</author>
  +  <title>ObJectRelationalBridge FAQ</title>
  + </properties>
  +
  + <body>
  +
  +  <section name="Frequently Asked Questions" anchor="faq">
  +   <ul>
  +    <li><a href="#1">Help! I'm having problems installing and using OJB!</a></li>
  +    <li><a href="#2">Help! I still have serious problems installing OJB!</a></li>
  +    <li><a href="#3">Why OJB? Why do we need another O/R mapping tool?</a></li>       
  +    <li><a href="#4">Does OJB support my RDBMS?</a></li>
  +    <li><a href="#5">How to use OJB with my RDBMS?</a></li>
  +    <li><a href="#6">How to page and sort?</a></li>
  +    <li><a href="#7">What about performance and memory usage if thousands of objects matching a query are returned as a Collection?</a></li>   
  +    <li><a href="#8">How is OJB related to ODMG and JDO?</a></li>
  +    <li><a href="#9">What are the differences between the PersistenceBroker API and the ODMG API? Which one should I use in my applications?</a></li>
  +    <li><a href="#10">What are the OJB internal tables for?</a></li>
  +    <li><a href="#11">When is it helpful to use Proxy Classes?</a></li>
  +    <li><a href="#12">How can I convert data between RDBMS and OJB?</a></li>
  +    <li><a href="#13">How can I trace and/or profile SQL statements executed by OJB?</a></li>
  +    <li><a href="#14">How does OJB manage foreign keys?</a></li>
  +    <li><a href="#15">I don't like OQL, can I use the PersistenceBroker Queries within ODMG?</a></li>
  +    <li><a href="#16">The OJB JDO implementation is not finished, how can I start using OJB?</a></li>
  +   </ul>
  + 
  +   <subsection name="Help! I'm having problems installing and using OJB!" anchor="1">	
  +    <p>
  +     Please read the <a href="quickstart.html">OJB Quick Start</a> document. OJB is a
  +     powerful and complex system - installing and configuring OJB is not a trivial task.
  +     Be sure to follow <b>all the steps</b> mentioned in that document - don't skip any steps
  +     when first installing OJB on your systems.  
  +    </p>
  +    <p>
  +     If you are having problems running OJB against your target database, read the 
  +     respective <a href="platforms.html">platform documentation</a>.  Before you
  +     try to deploy OJB to your environment, read the 
  +     <a href="deployment.html">deployment guide</a>.
  +    </p>
  +   </subsection>
  +
  +   <subsection name="Help! I still have serious problems installing OJB!" anchor="2">
  +    <p>
  +	 The following answer is quoted from the OJB user-list. It is from a
  +	 reply to a user who had serious problems getting started with OJB.
  +    </p>
  +    <p>
  +	 I would say it was stupid not to understand OJB. How can you know what
  +	 another programmer wrote. I've been a Java programmer for quite some time
  +	 and I could show you stuff I wrote that I know you wouldn't understand.
  +	 I'll just break it down the best I can on what, where and why.
  +    </p>
  +    <p>	
  +	 OJB is a data persistence layer for Java. I'll just use an example of how I
  +	 use it. I have an RDMS. I would like to save Java object states to this
  +	 database and I would like to be able to search this information as well. If
  +	 you serialize objects it's hard to search and if you use SQL it won't work
  + 	 with any different database. Plus it's a mess having to work with all that
  +	 SQL in your code. And by using SQL you don't get to work with just Java
  +	 objects. But, with OJB your separated from having to work outside the
  +	 object world and unlike serialization you can preform SQL like searches on
  +	 your data. Also, there's things like caching and connection pooling in OJB
  +	 that help with performance. After setting up OJB you will us either ODMG or
  +	 JDO to access your information in a object centric manner. ODMG is a
  +	 standard for the api for accessing your data. That means you can use any
  +	 ODMG compliant api if you don't want to use OJB. The JDO part is like ODMG
  +	 except it's the SUN JDO standard. I use ODMG because the JDO interface is
  +	 not ready yet.
  +    </p>
  +    <p>	
  +	 OJB is easy to use. I'll just break it down into two sides. There's the
  +	 side your writing your code for your application and there's the side that
  +	 you configure to make OJB connect to your database. Starting with your
  +	 application side, all that is needed is to use the interface you wish. I
  +	 use ODMG because JDO is not complete yet. Here's a link to the ODMG part
  +	 with some code for examples. http://jakarta.apache.org/ojb/tutorial2.html
  +	 That's all you need on the application side. Next there's the configuration
  +	 side. This is the one your fighting with. Here you need to setup the core
  +	 tables for OJB and you will define the classes you wish to store in your
  +	 database.
  +    </p>
  +    <p>	
  +	 First thing to do is to build the cvs's with the default database HSQL,
  +	 because you know it will work. If you get past this point you should have a
  +	 working OJB compiled. Now if your using JDK 1.4 you will need to set in
  +	 build.properties JDBC=+JDBC30 and do a build.sh preprocess first. Next you
  +	 will do a build.sh junit and this will build OJB and test everything for
  +	 you. If you get a build successful then your in business. Then you will
  +	 want to run build.sh jar to create the OJB jar to put in your /lib. You
  +	 will need a couple other jars in you /lib directory to make it all work.
  +	 See this page for those. http://jakarta.apache.org/ojb/deployment.html
  +    </p>
  +    <p>	
  +	 Next you will need some xml and configuration files in your class path for
  +	 OJB. You will find those files under {$OJB_base_dir}/target/test/ojb. All
  +	 the repository.xml's and OJB.properties for sure. With all these files in
  +	 place with your application you should be ready to use OJB and start
  +	 writing your application.
  +    </p>
  +    <p>	
  + 	 Finally you will want to setup your connection to your database and define
  +	 your classes you will be storing in your database. In the repository.xml
  +	 file you can configure your JDBC parameters so OJB can connect to your
  +	 database. You will also need your JDBC jar somewhere in your class path.
  +	 Then you will define your classes in the repository_user.xml file. Look
  +	 here for examples. http://jakarta.apache.org/ojb/tutorial1.html Note you
  +	 will want to comment out the junit part in repository.xml because it's just
  +	 for testing.
  +    </p>
  +    <p>	
  + 	 The final thing to do is to make sure the OJB core tables are in your
  +	 database. Look on this page for the core tables.
  +	 http://jakarta.apache.org/ojb/platforms.html. These core tables are used by
  +	 OJB to store internal data while it's running. It needs these. Then there's
  +	 the tables you define. The ones you mapped in the repository_user.xml file.
  +    </p>
  +    <p>	
  + 	 Sorry if any of this is off. OJB is growing so fast that it's hard to keep
  +	 up with all changes. The order I gave the steps in is just how I would
  +	 think it's understood better. You can go in any order you want. The steps
  +	 I've shown are mostly for deployment. Hope this helps you understand OJB a
  +	 little better. I'm not sure if this is what your wanting or not.
  +    </p>
  +   </subsection>
  +
  +   <subsection name="Why OJB? Why do we need another O/R mapping tool?" anchor="3">
  +    <p>
  +     here are some outstanding OJB features:
  +     <ul>
  +      <li>It's fully ODMG 3.0 compliant</li>
  +      <li>It will have a full JDO implementation</li>
  +      <li>It's higly scalable (Loadbalanced Multiserver scenario)</li>
  +      <li>It provides multiple APIs:
  +       <ul>
           <li>The full fledged ODMG-API,</li>
           <li>The JDO API (planned) </li>
           <li>
  @@ -133,108 +144,108 @@
             kernel which can be used to build higher level APIs (like the ODMG and
             JDO Implementations)
           </li>
  -      </ul>
  -    </li>
  -    <li>It's able to handle multible RDBMS simultaneously.</li>
  -    <li>
  -      it has a slick MetaLevel Architecture: By changing the MetaData at runtime
  -      you can change the O/R mapping behaviour. (E.G. turning on/off usage of
  -      Proxies.)
  -    </li>
  -    <li>
  -      It has a simple CacheMechanisms that is fully garbage	collectable by usage
  -      of weak references.
  -    </li>
  -    <li>It has a simple and clean pattern based design.</li>
  -    <li>
  -      It uses a configurable plugin concept. This allows to replace components
  -      (e.g. the ObjectCache) by user defined Replacements.
  -    </li>
  -    <li>
  -      It has a modular architecture (you can quite easily reuse	some components
  -      in your own applications if you don't want to use	the whole thing:
  -      <ul>
  -        <li>The PersistenceBroker (e.g. to build your own PersistenceManager)</li>
  +       </ul>
  +      </li>
  +      <li>It's able to handle multiple RDBMS simultaneously.</li>
  +      <li>
  +       it has a slick MetaLevel Architecture: By changing the MetaData at runtime
  +       you can change the O/R mapping behaviour. (E.G. turning on/off usage of
  +       Proxies.)
  +      </li>
  +      <li>
  +       It has a simple CacheMechanisms that is fully garbage	collectable by usage
  +       of weak references.
  +      </li>
  +      <li>It has a simple and clean pattern based design.</li>
  +      <li>
  +       It uses a configurable plugin concept. This allows to replace components
  +       (e.g. the ObjectCache) by user defined Replacements.
  +      </li>
  +      <li>
  +       It has a modular architecture (you can quite easily reuse	some components
  +       in your own applications if you don't want to use	the whole thing:
  +       <ul>
  +        <li>The PersistenceBroker (e.g. to build your own PersistenceManager)</li> 
           <li>The Query Interface as an abstract query syntax</li>
           <li>The OQL Parser</li>
           <li>The MetaData Layer</li>
           <li>The JDBC Accesslayer</li>
  -      </ul>
  -    </li>
  -    <li>
  -      It has a very sharp focus: It's concerned with O/R mapping and nothing
  -      else.
  -    </li>
  -  </ul>
  -
  -  Before making OJB an OpenSource project I had a look around at the
  -  emerging OpenSource O/R scene and was asking myself if there is
  -  really a need for yet another O/R tool.
  -</p>
  -<p>
  -  I came to the conclusion that there was a need for OJB because:
  -  <ul>
  -    <li>There was no ODMG/JDO compliant opensource tool available</li>
  -    <li>There was no scalable opensource O/R tool available</li>
  -    <li>
  -      there was no tool available with the idea of a PersistenceBroker Kernel
  -      that could be easiliy extended
  -    </li>
  -    <li>The tools available had no dynamic MetaData architectures.</li>
  -    <li>
  -      The tools available were not as clearly designed as I hoped,
  -      thus extending one of them would have been very difficult.
  -    </li>
  -  </ul>
  -</p>
  -</subsection>
  -
  -<subsection name="Does OJB support my RDBMS?">
  -  <p>
  -    <A HREF="platforms.html">please refer to this document</A>.
  -  </p>
  -</subsection>
  -
  -<subsection name="How to use OJB with my RDBMS?">
  -  <p>
  -    <A HREF="platforms.html">please refer to this document</A>.
  -  </p>
  -</subsection>
  -
  -<subsection name="How to page and sort?">
  -  <p>
  -    Sorting can be configured by
  -    org.apache.ojb.broker.query.Criteria::orderBy(column_name).
  -  </p>
  -  <p>
  -    There is no paging support in OJB. OJB is concerned with Object/Relational
  -    mapping and not with application specific presentation details like
  -    presenting a scrollable page of items.
  -  </p>
  -  <p>
  -    OJB returns query results as Collections or Iterators.
  -  </p>
  -  <p>
  -    You can easily implement your partial display of result data by using an
  -    Iterator as returned by ojb.broker.PersistenceBroker::getIteratorByQuery(...).
  -  </p>
  -</subsection>
  -
  -<subsection name="What about performance and memory usage if thousands of
  -objects matching a query are returned as a Collection?">
  -  <p>
  -    You can do two things to enhance performance if you have to process queries
  -    that produce thousands of result objects:
  -  </p>
  -  <ol>
  -    <li>
  +       </ul>
  +      </li>
  +      <li>
  +       It has a very sharp focus: It's concerned with O/R mapping and nothing
  +       else.
  +      </li>
  +     </ul>  
  +
  +     Before making OJB an OpenSource project I had a look around at the
  +     emerging OpenSource O/R scene and was asking myself if there is
  +     really a need for yet another O/R tool.
  +    </p>
  +    <p>
  +     I came to the conclusion that there was a need for OJB because:
  +     <ul>
  +      <li>There was no ODMG/JDO compliant opensource tool available</li>
  +      <li>There was no scalable opensource O/R tool available</li>
  +      <li>
  +       there was no tool available with the idea of a PersistenceBroker Kernel
  +       that could be easiliy extended
  +      </li>
  +      <li>The tools available had no dynamic MetaData architectures.</li>
  +      <li>
  +       The tools available were not as clearly designed as I hoped,
  +       thus extending one of them would have been very difficult.
  +      </li>
  +     </ul>
  +    </p>
  +   </subsection> 
  +
  +   <subsection name="Does OJB support my RDBMS?" anchor="4">
  +    <p>
  +     <A HREF="platforms.html">please refer to this document</A>.
  +    </p>
  +   </subsection> 
  +
  +   <subsection name="How to use OJB with my RDBMS?" anchor="5">
  +    <p>
  +     <A HREF="platforms.html">please refer to this document</A>.
  +    </p>
  +   </subsection> 
  +
  +   <subsection name="How to page and sort?" anchor="6">
  +    <p>
  +     Sorting can be configured by
  +     org.apache.ojb.broker.query.Criteria::orderBy(column_name).
  +    </p>
  +    <p>
  +     There is no paging support in OJB. OJB is concerned with Object/Relational
  +     mapping and not with application specific presentation details like
  +     presenting a scrollable page of items.
  +    </p>
  +    <p>
  +     OJB returns query results as Collections or Iterators.
  +    </p>
  +    <p>
  +     You can easily implement your partial display of result data by using an
  +     Iterator as returned by ojb.broker.PersistenceBroker::getIteratorByQuery(...).
  +    </p>
  +   </subsection> 
  +
  +   <subsection name="What about performance and memory usage if thousands of
  +    objects matching a query are returned as a Collection?" anchor="7">
  +    <p>
  +     You can do two things to enhance performance if you have to process queries
  +     that produce thousands of result objects:
  +    </p>
  +    <ol>
  +     <li>
         Use getIteratorByQuery() rather than getCollectionByQuery().
         The returned Iterator is lazy and does not materialize Objects in
         advance.Objects are only materialized if you call the Iterators
         next() method. Thus you have total control about when and how many
         Objects get materialized!
  -    </li>
  -    <li>
  +     </li>
  +     <li>
         You can define Proxy Objects as placeholder for your
         persistent business objects. Proxys are lighweight objects that
         contain only primary key information. Thus their materialization is
  @@ -244,252 +255,246 @@
         are accessed directly. Thus you can build similar lazy paging as
         with the Iterator. You will find examples in the packages
         test.ojb.broker
  -    </li>
  -  </ol>
  -  <p>
  -    The Perfomance of 1. will be better than 2. This approach will
  -    also work for VERY large resultsets, as there are no references to
  -    result objects that would prevent their garbage collectability.
  -  </p>
  -</subsection>
  -
  -<subsection name="How is OJB related to ODMG and JDO?">
  -  <p>
  -    ODMG is a standard API for Object Persistence specified by the ODMG
  -    consortium (www.odmg.org). 
  -    JDO is Sun's API specification for Object Persistence. ODMG may
  -    well be regarded as a Precursor to JDO.
  -    In fact JDO incorporates
  -    many ideas from ODMG and several people who have been involved in
  -    the ODMG spec are now in the JDO team.
  -    <br/>    
  -    I assume JDO will have
  -    tremendous influence on OODBMS-, RDBMS-, J2EE-server and O/R-tool-vendors 
  -    to provide compliant products.
  -    <br/>
  -    OJB wants to provide first class support for JDO and ODMG APIs.
  -  </p>
  -  <p>
  -    OJB currently contains of four main layers, each with its own API:
  -    <ol>
  -
  -    <li>
  -      A low-level <b>PersistenceBroker</b> API which serves as the OJB persistence
  -      kernel. The PersistenceBroker also provides a scalable
  -      multi-server architecture that allows to used it in heavy-duty
  -      app-server scenarios.
  -      <br/>
  -      This API can also be used directly by applications that don't need full
  -      fledged object level transactions (see <a href="tutorial1.html">
  -      tutorial1</a> for details).
  -    </li>
  -
  -    <li>
  -    	An Object Transaction Manager (OTM) layer that contains all features that
  -    	JDO and ODMG have in common as Object level transactions, lock-management,
  -    	instance lifecyle etc.
  -    	(See <a href="jdo-proposal.html">jdo-proposal.html</a> for details.)
  -    	The OTM is work in progress. 
  -    </li>
  -      
  -    <li>
  -      A full featured <b>ODMG 3.0</b> compliant API. (See <a href="tutorial2.html">
  -      tutorial2</a> for an introduction.)
  -      <br/> Currently this API is implemented on top the PersistenceBroker. Once the
  -      OTM layer is finished ODMG will be implemented on top of OTM.
  -    </li>
  -
  -    <li>
  -      A <b>JDO</b> compliant API. This is work in progress.
  -      (See <a href="tutorial4.html">
  -      tutorial4</a> for an introduction.)
  -      <br/> Currently this API is implemented on top the PersistenceBroker. Once the
  -      OTM layer is finished JDO will be implemented on top of OTM.
  -
  -    </li>
  -          
  +     </li>
       </ol>
  -  </p>
  -  
       <p>
  -  	The following graphics shows the layering of these APIs. Please note that the
  -  	layers coloured in yellow are not yet implemented.
  -  <center>
  -  	<img src="images/ojb-layers.png"/>
  -  </center>
  -  </p>
  +     The Perfomance of 1. will be better than 2. This approach will
  +     also work for VERY large resultsets, as there are no references to
  +     result objects that would prevent their garbage collectability.
  +    </p>
  +   </subsection> 
   
  +   <subsection name="How is OJB related to ODMG and JDO?" anchor="8">
  +    <p>
  +     ODMG is a standard API for Object Persistence specified by the ODMG
  +     consortium (www.odmg.org). 
  +     JDO is Sun's API specification for Object Persistence. ODMG may
  +     well be regarded as a Precursor to JDO.
  +     In fact JDO incorporates
  +     many ideas from ODMG and several people who have been involved in
  +     the ODMG spec are now in the JDO team.
  +     <br/>    
  +     I assume JDO will have
  +     tremendous influence on OODBMS-, RDBMS-, J2EE-server and O/R-tool-vendors 
  +     to provide compliant products.
  +     <br/>
  +     OJB wants to provide first class support for JDO and ODMG APIs.
  +    </p>
  +    <p>
  +     OJB currently contains of four main layers, each with its own API:
  +     <ol>
  +      <li>
  +       A low-level <b>PersistenceBroker</b> API which serves as the OJB persistence
  +       kernel. The PersistenceBroker also provides a scalable
  +       multi-server architecture that allows to used it in heavy-duty
  +       app-server scenarios.
  +       <br/>
  +       This API can also be used directly by applications that don't need full
  +       fledged object level transactions (see <a href="tutorial1.html">
  +       tutorial1</a> for details).
  +      </li> 
  +
  +      <li>
  +       An Object Transaction Manager (OTM) layer that contains all features that
  +       JDO and ODMG have in common as Object level transactions, lock-management,
  +       instance lifecyle etc.
  +       (See <a href="jdo-proposal.html">jdo-proposal.html</a> for details.)
  +       The OTM is work in progress. 
  +      </li>
  +       
  +      <li>
  +       A full featured <b>ODMG 3.0</b> compliant API. (See <a href="tutorial2.html">
  +       tutorial2</a> for an introduction.)
  +       <br/> Currently this API is implemented on top the PersistenceBroker. Once the
  +       OTM layer is finished ODMG will be implemented on top of OTM.
  +      </li> 
  +
  +      <li>
  +       A <b>JDO</b> compliant API. This is work in progress.
  +       (See <a href="tutorial4.html">
  +       tutorial4</a> for an introduction.)
  +       <br/> Currently this API is implemented on top the PersistenceBroker. Once the
  +       OTM layer is finished JDO will be implemented on top of OTM.
  +      </li>
  +           
  +     </ol>
  +    </p>
     
  +    <p>
  +     The following graphics shows the layering of these APIs. Please note that the
  +     layers coloured in yellow are not yet implemented.
  +     <center>
  +   	  <img src="images/ojb-layers.png"/>
  +     </center>
  +    </p>
     
  -</subsection>
  +   </subsection>
   
  -<subsection name="What are the differences between the PersistenceBroker API and
  -the ODMG API? Which one should I use in my applications?">
  -  <p>
  -    The PersistenceBroker (PB) provides a minimal API for transparent
  -    persistence:
  -    <ul>
  +   <subsection name="What are the differences between the PersistenceBroker API and
  +     the ODMG API? Which one should I use in my applications?" anchor="9">
  +    <p>
  +     The PersistenceBroker (PB) provides a minimal API for transparent
  +     persistence:
  +     <ul>
         <li>O/R mapping</li>
         <li>Retrieval of objects with a simple query interface from RDBMS</li>
         <li>storing (insert, update) of objects to RDBMS</li>
         <li>deleting of objects from RDBMS</li>
  -    </ul>
  -  </p>
  -  <p>This is all you need for simple applications as in tutorial1.</p>
  -  <p>
  -    The OJB ODMG implementation uses the PB as its persistence kernel.
  -    But it provides much more functionality to the application developer.
  -    ODMG is a full fledged API for Object Persistence, including:
  -    <ul>
  +     </ul>
  +    </p>
  +    <p>This is all you need for simple applications as in tutorial1.</p>
  +    <p>
  +     The OJB ODMG implementation uses the PB as its persistence kernel.
  +     But it provides much more functionality to the application developer.
  +     ODMG is a full fledged API for Object Persistence, including:
  +     <ul>
         <li>OQL Query interface</li>
         <li>real Object Transactions</li>
         <li>
  -        A Locking Mechanism for management of concurrent threads (apps)
  -        accessing the same objects
  +       A Locking Mechanism for management of concurrent threads (apps)
  +       accessing the same objects
         </li>
         <li>predefined persistent capable Collections and Hashtables</li>
  -    </ul>
  -  </p>
  -  <p>
  -    Some examples explaining the implications of these functional differences:
  -    <ol>
  +     </ul>
  +    </p>
  +    <p>
  +     Some examples explaining the implications of these functional differences:
  +     <ol>
         <li>
  -        Say you use the PB to query an object O that has a collection
  -        attribute col with five elements a,b,c,d,e. Next you delete Objects
  -        d and e from col and store O again with
  -        PersistenceBroker.store(O);<br/>
  -        PB will store the remaining objects a,b,c. But it will not delete d and
  -        e ! If you then requery object O it will again contain a,b,c,d,e !!!<br/>
  -        The PB keeps no transactional state of the persistent Objects, thus it
  -        does not know that d and e have to be deleted. (as a side note: deletion
  -        of d and e could also be an error, as there might be references to them
  -        from other objects !!!)<br/>
  -        Using ODMG for the above scenario will eliminate all trouble: Objects
  -        are registered to a transaction so that on commit of the transaction it
  -        knows that d and e do not longer belong to the collection. the ODMG
  -        collection will not delete the objects d and e but only the REFERENCES
  -        from the collection to those objects!
  -      </li>
  -      <li>
  -        Say you have two threads (applications) that try to access
  -        and modify the same object O. The PB has no means to check whether
  -        objects are used by concurrent threads. Thus it has no locking
  -        facilities. You can get all kind of trouble by this situation. The
  -        ODMG implementation has a Lockmanager that is capable of
  -        synchronizing concurrent threads. You can even use four transaction
  -        isolation levels:<br/>read-uncommitted, read-committed,
  -        repeatable-read, serializable.
  +       Say you use the PB to query an object O that has a collection
  +       attribute col with five elements a,b,c,d,e. Next you delete Objects
  +       d and e from col and store O again with
  +       PersistenceBroker.store(O);<br/>
  +       PB will store the remaining objects a,b,c. But it will not delete d and
  +       e ! If you then requery object O it will again contain a,b,c,d,e !!!<br/>
  +       The PB keeps no transactional state of the persistent Objects, thus it
  +       does not know that d and e have to be deleted. (as a side note: deletion
  +       of d and e could also be an error, as there might be references to them
  +       from other objects !!!)<br/>
  +       Using ODMG for the above scenario will eliminate all trouble: Objects
  +       are registered to a transaction so that on commit of the transaction it
  +       knows that d and e do not longer belong to the collection. the ODMG
  +       collection will not delete the objects d and e but only the REFERENCES
  +       from the collection to those objects!
         </li>
  -    </ol>
  -  </p>
  -  <p>
  -    In my eyes the PB is a persistence kernel that can be used to
  -    build high-level PersistenceManagers like an ODMG or JDO
  -    implementation. It can also be used to write simple applications, but
  -    you have to do all management things (locking, tracking objects
  -    state, object transactions) on your own.
  -  </p>
  -</subsection>
  -
  -<subsection name="what are the OJB internal tables for?">
  -  <p>
  -    <a href="platforms.html">please refer to this document</a>.
  -  </p>
  -</subsection>
  -
  -<subsection name="When is it helpful to use Proxy Classes?">
  -  <p>
  -    Proxy classes can be used for &quot;lazy loading&quot; aka
  -    &quot;lazy materialization&quot;. Using Proxy classes can help you in
  -    reducing unneccessary db lookups. Example:
  -  </p>
  -  <p>
  -    Say you load a ProductGroup object from the db which contains a
  -    collection of 15 Article objects.
  -  </p>
  -  <p>
  -    Without proxies all 15 Article objects are immediately loaded from
  -    the db, even if you are not interested in them but just want to
  -    lookup the description-attribute of the ProductGroup object.
  -  </p>
  -  <p>
  -    With a proxy class, the collection is filled with 15 proxy
  -    objects, that implement the same interface as the &quot;real objects&quot;
  -    but contain only an OID and a void reference.
  -  </p>
  -  <p>
  -    Once you access such a proxy object it loads its &quot;real
  -    subject&quot; by OID and delegates the method call to it.
  -  </p>
  -  <p>
  -    have a look at <A HREF="tutorial3.html">tutorial3.html</A>. 
  -    This document has a large section on proxies.
  -  </p>
  -</subsection>
  -
  -<subsection name="How can I convert data between RDBMS and OJB?">
  -  <p>
  -    For Example I have a DB column of type INTEGER but a class atribute of type
  -    boolean. How can I provide an automatic mapping with OJB?
  -  </p>
  -  <p>
  -    OJB provides a concept of ConversionStrategies that can be used for such
  -    conversion tasks. <A HREF="jdbc-types.html">Have a look at the respective
  -    document</A>.
  -  </p>
  -</subsection>
  -
  -
  -<subsection name="How can I trace and/or profile SQL statements executed by OJB?">
  -  <p>
  -	 OJB ships with out of the box support for P6Spy.
  +      <li>
  +       Say you have two threads (applications) that try to access
  +       and modify the same object O. The PB has no means to check whether
  +       objects are used by concurrent threads. Thus it has no locking
  +       facilities. You can get all kind of trouble by this situation. The
  +       ODMG implementation has a Lockmanager that is capable of
  +       synchronizing concurrent threads. You can even use four transaction
  +       isolation levels:<br/>read-uncommitted, read-committed,
  +       repeatable-read, serializable.
  +      </li>
  +     </ol>
  +    </p>
  +    <p>
  +     In my eyes the PB is a persistence kernel that can be used to
  +     build high-level PersistenceManagers like an ODMG or JDO
  +     implementation. It can also be used to write simple applications, but
  +     you have to do all management things (locking, tracking objects
  +     state, object transactions) on your own.
  +    </p>
  +   </subsection>  
  +
  +   <subsection name="What are the OJB internal tables for?" anchor="10">
  +    <p>
  +     <a href="platforms.html">please refer to this document</a>.
  +    </p>
  +   </subsection>
  +
  +   <subsection name="When is it helpful to use Proxy Classes?" anchor="11">
  +    <p>
  +     Proxy classes can be used for &quot;lazy loading&quot; aka
  +     &quot;lazy materialization&quot;. Using Proxy classes can help you in
  +     reducing unneccessary db lookups. Example:
  +    </p>
  +    <p>
  +     Say you load a ProductGroup object from the db which contains a
  +     collection of 15 Article objects.
  +    </p>
  +    <p>
  +     Without proxies all 15 Article objects are immediately loaded from
  +     the db, even if you are not interested in them but just want to
  +     lookup the description-attribute of the ProductGroup object.
  +    </p>
  +    <p>
  +     With a proxy class, the collection is filled with 15 proxy
  +     objects, that implement the same interface as the &quot;real objects&quot;
  +     but contain only an OID and a void reference.
  +    </p>
  +    <p>
  +     Once you access such a proxy object it loads its &quot;real
  +     subject&quot; by OID and delegates the method call to it.
  +    </p>
  +    <p>
  +     have a look at <A HREF="tutorial3.html">tutorial3.html</A>. 
  +     This document has a large section on proxies.
  +    </p>
  +   </subsection> 
  +
  +   <subsection name="How can I convert data between RDBMS and OJB?" anchor="12">
  +    <p>
  +     For Example I have a DB column of type INTEGER but a class atribute of type
  +     boolean. How can I provide an automatic mapping with OJB?
  +    </p>
  +    <p>
  +     OJB provides a concept of ConversionStrategies that can be used for such
  +     conversion tasks. <A HREF="jdbc-types.html">Have a look at the respective
  +     document</A>.
  +    </p>
  +   </subsection>
  +
  +
  +   <subsection name="How can I trace and/or profile SQL statements executed by OJB?" anchor="13">
  +    <p> 
  +   	 OJB  ships with out of the box support for P6Spy.
   	 P6Spy is a JDBC proxy. It delegates all JDBC calls to the 
   	 real JDBC driver and traces all calls to a log file.
  - </p>
  - <p>
  -	 In the file <code>build.properties</code> you have to set the switch 
  +    </p>
  +    <p> 
  + 	 In the file <code>build.properties</code> you have to set the switch 
   	 <code>useP6Spy</code> to <code>true</code> in order to activate it:
  -  </p>
  -  <source>
  +    </p>
  +    <source>
   # The useP6Spy switch determines if the tracing JDBC driver P6Spy is used.
   # If you enable this switch, you must also edit the file
   # jakarta-ojb/src/test/org/apache/ojb/spy.properties
   # to tell P6Spy which JDBC driver to use and where to write the log.
   # By default the HSQLDB driver is used.
   useP6Spy=true
  -  </source>
  -  <p>
  +    </source>
  +    <p> 
   	 This setup uses P6Spy to trace and profile all executed
  -	SQL to a file <code>target/test/ojb/spy.log</code>.
  +	 SQL to a file <code>target/test/ojb/spy.log</code>.
   	 It also measures the time needed to execute each statement!
  -  </p>
  -</subsection>
  +    </p>
  +   </subsection>
   
  -<subsection name="How does OJB manage foreign keys ?">
  -<p>
  -	Automatically! you just define 1:1, 1:n or m:n associations in the
  -	repository_user.xml file.
  -	OJB does the rest!
  -</p>
  -<p>		
  -	Please refer to <a href="tutorial3.html">tutorial3</a> and
  -	<a href="repository.html">repository.html</a> for details.
  -</p>
  -</subsection>
  -
  -<subsection name="I don't like OQL, can I use the PersistenceBroker Queries within ODMG?">
  -
  -<p>	
  -	Yes you can! The ODMG implementation relies on PB Queries internally!
  -	Several users (including myself) are doing this.
  -</p>
  -<p>	
  -	If you have a look at <code>org.apache.ojb.odmg.oql.OqlQueryImpl.execute()</code> 
  -	you will see how OJB Query objects can be used withing ODMG transactions.
  -	The most important thing is to lock all objects returned by a query to the current transaction. 
  -</p>
  -
  -<source>
  +   <subsection name="How does OJB manage foreign keys?" anchor="14">
  +    <p>
  +	 Automatically! you just define 1:1, 1:n or m:n associations in the
  +	 repository_user.xml file.
  +	 OJB does the rest!
  +    </p>
  +    <p>		
  +	 Please refer to <a href="tutorial3.html">tutorial3</a> and
  +	 <a href="repository.html">repository.html</a> for details.
  +    </p>
  +   </subsection>
  +
  +   <subsection name="I don't like OQL, can I use the PersistenceBroker Queries within ODMG?" anchor="15">
  +    <p>	
  +	 Yes you can! The ODMG implementation relies on PB Queries internally!
  +	 Several users (including myself) are doing this.
  +    </p>
  +    <p>	
  +	 If you have a look at the <code>execute()</code> method in <code>org.apache.ojb.odmg.oql.OqlQueryImpl</code> 
  +	 you will see how OJB Query objects can be used withing ODMG transactions.
  +	 The most important thing is to lock all objects returned by a query to the current transaction. 
  +    </p>
  +    <source>
       public Object execute() throws org.odmg.QueryException
       {
           try
  @@ -519,7 +524,7 @@
                   toBeLocked = iter.next();
                   //we can only lock objects, not attributes
                   if (broker.hasClassDescriptor(toBeLocked.getClass()))
  -                    tx.lock(toBeLocked, tx.READ);
  +                    tx.lock(toBeLocked, Transaction.READ);
               }
               
               ...
  @@ -532,62 +537,59 @@
               throw new org.odmg.QueryException(t.getMessage());
           }
       }
  -</source>
  +    </source>
  +   </subsection>
   
  -</subsection>
  -
  -<subsection name="The OJB JDO implementation is not finished, how can I start using OJB?">
  -<p>
  -	I recommend to not use JDO now, but to use the existing ODMG api 
  -	for the time being.
  -</p>
  -<p>	
  -	Migrating to JDO later will be smooth if you follow the following steps.
  -	I recommend to first divide your model layer into Activity- (or Process-) 
  -	classes and Entity classes.
  -</p>
  -<p>	
  -	Entity classes represent classes that must be made persistent at some 
  -	point in time, say a "Customer" or a "Order" object.
  -	These persistent classes and the repsective O/R mapping in repository.xml will
  -	remain unchanged.
  -</p>
  -<p>		
  -	Activities are classes that perform business tasks and work upon 
  -	entities, e.g. "edit a Customer entry", "enter a new Order"...
  -	They implement (parts of) use cases.
  -</p>
  -<p>		
  -	Activities are driving transactions against the persistent storage.
  -</p>
  -<p>	
  -	I recommend to have a Transaction interface that your Activities can 
  -	use. This Transaction interface can be implemented by ODMG or by JDO 
  -	Transactions (which are quite similar). The implementation should be made 
  -	configurable to allow to switch from ODMG to JDO later.
  -</p>
  -<p>	
  -	The most obvious difference between ODMG and JDO are the query 
  -	languages: ODMG uses OQL, JDO define JDOQL.
  -	As an OO developer you won't like both of them.
  -	I recommend to use the ojb Query objects that allow an abstract syntax 
  -	representation of queries.
  -	It is possible to use these queries within ODMG transactions and it will 
  -	also be possible to use them within JDO Transactions. (this is contained in the FAQ too).
  -</p>
  -<p>		
  -	Using your own Transaction interface in conjunction with the OJB query 
  -	api will provide a simple but powerful abstraction of the underlying 
  -	persistence layer.
  -</p>
  -<p>		
  -	We are using this concept to provide an abstract layer above OJB-ODMG, 
  -	TopLink and LDAP servers in my company.
  -	Making it work with OJB-JDO will be easy!
  -</p>
  -</subsection>
  -
  -</section>
  -
  -</body>
  +   <subsection name="The OJB JDO implementation is not finished, how can I start using OJB?" anchor="16">
  +    <p>
  + 	 I recommend to not use JDO now, but to use the existing ODMG api 
  +	 for the time being.
  +    </p>
  +    <p>	
  +	 Migrating to JDO later will be smooth if you follow the following steps.
  +	 I recommend to first divide your model layer into Activity- (or Process-) 
  +	 classes and Entity classes.
  +    </p>
  +    <p>	
  + 	 Entity classes represent classes that must be made persistent at some 
  +	 point in time, say a "Customer" or a "Order" object.
  +	 These persistent classes and the repsective O/R mapping in repository.xml will
  +	 remain unchanged.
  +    </p>
  +    <p>		
  + 	 Activities are classes that perform business tasks and work upon 
  +	 entities, e.g. "edit a Customer entry", "enter a new Order"...
  +	 They implement (parts of) use cases.
  +    </p>
  +    <p>		
  +	 Activities are driving transactions against the persistent storage.
  +    </p>
  +    <p>	
  +	 I recommend to have a Transaction interface that your Activities can 
  +	 use. This Transaction interface can be implemented by ODMG or by JDO 
  +	 Transactions (which are quite similar). The implementation should be made 
  +	 configurable to allow to switch from ODMG to JDO later.
  +    </p>
  +    <p>	
  +	 The most obvious difference between ODMG and JDO are the query 
  +	 languages: ODMG uses OQL, JDO define JDOQL.
  +	 As an OO developer you won't like both of them.
  +	 I recommend to use the ojb Query objects that allow an abstract syntax 
  +	 representation of queries.
  +	 It is possible to use these queries within ODMG transactions and it will 
  +	 also be possible to use them within JDO Transactions. (this is contained in the FAQ too).
  +    </p>
  +    <p>		
  + 	 Using your own Transaction interface in conjunction with the OJB query 
  +	 api will provide a simple but powerful abstraction of the underlying 
  +	 persistence layer.
  +    </p>
  +    <p>		
  + 	 We are using this concept to provide an abstract layer above OJB-ODMG, 
  +	 TopLink and LDAP servers in my company.
  +	 Making it work with OJB-JDO will be easy!
  +    </p>
  +   </subsection>
  +  </section>
  + </body>
   </document>
  
  
  
  1.4       +23 -2     jakarta-ojb/xdocs/stylesheets/site.xsl
  
  Index: site.xsl
  ===================================================================
  RCS file: /home/cvs/jakarta-ojb/xdocs/stylesheets/site.xsl,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- site.xsl	14 Jul 2002 12:06:23 -0000	1.3
  +++ site.xsl	8 Dec 2002 12:01:04 -0000	1.4
  @@ -171,11 +171,22 @@
       <xsl:variable name="name">
         <xsl:value-of select="@name"/>
       </xsl:variable>
  +    <xsl:variable name="anchor">
  +      <xsl:choose>
  +      	<xsl:when test="@anchor">
  +	      <xsl:value-of select="@anchor"/>
  +	    </xsl:when>
  +	    <xsl:otherwise>
  +	      <xsl:value-of select="@name"/>
  +	    </xsl:otherwise>
  +	  </xsl:choose>
  +	</xsl:variable>
  +	  
       <table border="0" cellspacing="0" cellpadding="2" width="100%">
         <!-- Section heading -->
         <tr><td bgcolor="{$banner-bg}">
             <font color="{$banner-fg}" face="arial,helvetica.sanserif">
  -          <a name="{$name}">
  +          <a name="{$anchor}">
             <strong><xsl:value-of select="@name"/></strong></a></font>
         </td></tr>
         <!-- Section body -->
  @@ -191,11 +202,21 @@
       <xsl:variable name="name">
         <xsl:value-of select="@name"/>
       </xsl:variable>
  +    <xsl:variable name="anchor">
  +      <xsl:choose>
  +      	<xsl:when test="@anchor">
  +	      <xsl:value-of select="@anchor"/>
  +	    </xsl:when>
  +	    <xsl:otherwise>
  +	      <xsl:value-of select="@name"/>
  +	    </xsl:otherwise>
  +	  </xsl:choose>
  +    </xsl:variable>
       <table border="0" cellspacing="0" cellpadding="2" width="100%">
         <!-- Subsection heading -->
         <tr><td bgcolor="{$sub-banner-bg}">
             <font color="{$sub-banner-fg}" face="arial,helvetica.sanserif">
  -          <a name="{$name}">
  +          <a name="{$anchor}">
             <strong><xsl:value-of select="@name"/></strong></a></font>
         </td></tr>
         <!-- Subsection body -->
  
  
  
  1.2       +2 -2      jakarta-ojb/xdocs/stylesheets/site.vsl
  
  Index: site.vsl
  ===================================================================
  RCS file: /home/cvs/jakarta-ojb/xdocs/stylesheets/site.vsl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- site.vsl	1 Jul 2002 20:35:19 -0000	1.1
  +++ site.vsl	8 Dec 2002 12:01:04 -0000	1.2
  @@ -131,7 +131,7 @@
       <table border="0" cellspacing="0" cellpadding="2" width="100%">
         <tr><td bgcolor="$subbannerbg">
           <font color="$subbannerfg" face="arial,helvetica,sanserif">
  -          <a name="$subsection.getAttributeValue("name")"><strong>$subsection.getAttributeValue("name")</strong></a>
  +          <a name="$subsection.getAttributeValue("anchor")"><strong>$subsection.getAttributeValue("name")</strong></a>
           </font>
         </td></tr>
         <tr><td>
  @@ -157,7 +157,7 @@
       <table border="0" cellspacing="0" cellpadding="2" width="100%">
         <tr><td bgcolor="$bannerbg">
           <font color="$bannerfg" face="arial,helvetica,sanserif">
  -          <a name="$section.getAttributeValue("name")"><strong>$section.getAttributeValue("name")</strong></a>
  +          <a name="$section.getAttributeValue("anchor")"><strong>$section.getAttributeValue("name")</strong></a>
           </font>
         </td></tr>
         <tr><td>
  
  
  

Mime
View raw message