commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin van den Bemt <>
Subject Re: [Betwixt] DOM Facade
Date Fri, 02 May 2003 11:21:58 GMT
Hi Robert..

I am back amongst the living, I really need an irc update of what needs
to be done (besides the task list that is).
I agree totally with your view about betwixt and maybe part of the
solution is a rewrite + full test coverage of the current version of
betwixt to see if we can stay backward compatible.
Maybe we can create a proposal directory where we can start with a clean
implementation, so we can get a new perspective on how the structure
could be (more interfaces eg, so it is easier to write extensions).
What I also really would like to see is automatic bean generation from
an xml file (although that is not the initial purpose of betwixt, but
mostly used that way as far as I can tell).The last thing can be
completely independend of anything else though. (I'll add it to the wish
list). Also ignoring .betwixt files should be possible (i'll add that
one too). 

I have an internet connection at my girlfriends now and will try to keep
connected during the weekend on irc :) 
Btw From 7 till 15 june I will be trying to get to England (sailing that
is). Don't know where we are going yet, but I'll let you know :)


On Fri, 2003-05-02 at 11:29, robert burrell donkin wrote:
> hi Daniel
> it's a long post (with even longer references) and it'll take a bit to 
> digest in detail. but i thought that it'd be better to come back with some 
> initial thoughts now and maybe come back to some individual points later. 
> maybe IRC might be a good way to discuss some of your design ideas.
> (these comments are unordered and a little disconnected.)
> DOM facade would be cool and all help appreciated. some users already use 
> betwixt with cocoon - but using SAX rather than DOM.
> betwixt is hard to work with. it's very easy to break and hard to 
> understand. it needs to be refactored but it's hard to see the right way 
> to do this. there is a chronic shortage of good test cases. some stuff is 
> a subtle and so it's easy to make mistakes. maybe supporting DOM might be 
> the key to a better structure but i'd prefer it to be thought out properly 
> before hand.
> even though betwixt is an alpha, we're still pretty hot on deprecation  
> and preserving compatibility (betwixt has an existing user base).
> a few other people have recently volunteered to add features to betwixt. i'
> d like to be able to coordinate these effort so that they aren't wasted.
> i'd like to hear the opinions of others about any major refactoring before 
> it goes ahead.
> - robert
> On Thursday, May 1, 2003, at 11:20 AM, Daniel Fagerstrom wrote:
> > 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,
> >
> > [2] Accessing java beans through DOM,
> >
> > [3] Domify,
> > [4] IRC chat,
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message