Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3EB0F4FA.3060400@nada.kth.se>
Date: Thu, 01 May 2003 12:20:42 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: commons-dev@jakarta.apache.org
CC: jeff@infohazard.org, nicolas@marchildon.net
Subject: [Betwixt] DOM Facade
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I'm interested in writing a DOM facade for Betwixt. My use case for such
a facade is for accessing business objects and the data model in Cocoon
as XML from XSLT. We had a long discussion about that at Cocoon-dev
recently [1]. There were also a thread about DOM facades for Java beans
xml-apache-general a while ago [2] where several people expressed
interest in helping although not leading such an effort.

In the thread [2] Domify [3], Betwixt and JXPath were mentioned. Domify
already is a (read only) DOM facade for Java beans, but has a fixed bean
to XML mapping rule. Betwixt provide flexible bean mapping rules but
need some refactoring to make these mapping rules accesible for a DOM
facade. JXPath provide an XML interface for beans, DynaBeans, DOM and
JDOM, but has not any mechanism for flexible bean mapping.

As I like the flexible bean mapping rules in Betwixt, I prefer to base
the DOM facade on Betwixt.

Plan
----
1. In Betwixt there is one class: AbstractBeanWriter, that both includes
the logic for transforming the Java bean structure and the mapping info
to XML nodes and traversing the tree in deep first order and writing the
   XML in a serial form (e.g. as text or SAX). I'd like to factor out the
code that creates XML nodes so that the XML structure can be accessed in
any order. The Navigator interface in Jaxen or the interfaces
o.a.c.jxpath.ri.model.NodePointer and o.a.c.jxpath.ri.model.NodeIterator
   in JXPath could be used as model, although I'd like to start with a
much more minimal interface.

2. Build a read only DOM facade above the XML node interface from 1.
This could be fairly similar to Domify.

3. Extend the DOM facade so that Java beans can be constructed and
connected through the DOM interface.

                                - o -

I have started to work on the refactoring of the AbstractBeanWriter and 
would like some feedback from the Betwixt team on my design ideas this 
far. So let us go into the techical details:

Design
------
My overall design goal is of course to factor out the XML tree traversal 
and node access code from the AbstractBeanWriter so that it could be 
used in a DOM facade as well. I also want to do this in such a way that 
it doesn't affect the performance or memory usage for the SAX or text 
generation. Furthermore I would like to move all knowledge about the 
intended structure of the generated XML to the descriptors to make the 
responsabilities clearer. currently there are some such information in 
the AbstractBeanWriter.

Each node in the XML tree that corresponds to the Java bean structure
can be identified by a pair consisting of a Descriptor object and a
Context object. The Descriptor is an ElementDescriptor, an 
AtributeDescriptor and so on depending on the node type. To make this 
more explicit in the code we define a class where the objects points to 
nodes in the XML tree:

class Pointer {
    attribute Descriptor descriptor,
    attribute Context context
}

In the AbstractBeanWriter the attributes writeIDs and writeEmptyElements 
affect the stucture of the generated XML tree. I would prefer that all 
information about the prefered tree structure is concentrated to the 
descriptors. IMO these attributes should be moved to the XMLIntrospector 
which in turn can use it to give the right information to the descriptors.

The AbstractBeanWriter also contains the attributes idMap, idGenerator 
and beanStack that are needed for creating id attributes for handling 
circular data structures. James Strachan proposed moving the id 
generation stuff to expressions [4], I think that it is a good idea. It 
would IMO require that the idMap, idGenerator and the beanStack are part 
of the Context object. The beanStack could be replaced by letting each 
Context object contain a reference to its parent.

There is also a need for accessing the attributes and the children of an 
element. I think I would prefer doing that through an Iterator over 
Pointers. For attributes, an indexed access structure using the the 
attributesDescriptors array would work. But for the children of an 
element the relation between indexes in the contenDescriptors array and 
positions in the generated XML is much more complicated for the cases 
where wrapCollectionsInElement is false or writeEmptyElements is false. 
      This basically means that to provide indexed access, all the 
children of the element need to be created and stored in an array. As I 
prefer an as light weight, access structure as possible I think an 
iterator over the chidren is better as it can wait to access a child 
until it is needed.

Given a Pointer that contains an ElementDescriptor we need some utility 
code that provide access to the different parts of an element, and like 
wise for attributes and other types of nodes. This could be done by 
creating wrappers objects for elements, attributes etc that contain a 
Pointer object. But in the interest of keeping things light weight and 
avoid the creation of lots of small objects, a better idea IMO, is to 
have ElementHelper, AttributeHelper etc, classes that contains static 
node access methodes that takes Pointers as an argument.

                                - o -

I guess that what I wrote about the proposed refactoring might be booth 
to vague and to techical to make it easily understandable. I'm working 
on implementing the above design, and would be happy to get some 
feedback on the proposed design.

/Daniel Fagerstrom


[1] [RT] the quest for the perfect template language,
http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2
[2] Accessing java beans through DOM,
http://marc.theaimsgroup.com/?t=104933325200002&r=1&w=2
[3] Domify, http://domify.sf.net
[4] IRC chat, http://irc.werken.com/channels/betwixt/2002-12-29.html


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org