commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [Betwixt] DOM Facade
Date Fri, 02 May 2003 17:42:42 GMT
  hi Robert

robert burrell donkin wrote:

> hi Daniel
> it's a long post (with even longer references)

Then you should see some of my posts on cocoon-dev ;) There is a 
tradition over there at cocoon-dev about writing long design documents 
and doing distributed design.

> 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. 

Yes, seems like a good idea.

> 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. 

SAX works well if you want to serialize all of your bean structure to 
XML and of course, there are many applications where this is a good 
idea. What I have in mind are cases when you want to access only a small 
part of a possibly very large bean structure through XSLT. For such 
cases it would be very inneficient to serialize all of the data as XML, 
a lazy DOM adapter is a much better idea. Furthermore some XSLT 
processors e.g. Xalan can work directly on an input DOM document 
(through a thin adapter layer). For SAX input however, an internal DOM 
like structure has to be build in the XSLT processor.

> betwixt is hard to work with. it's very easy to break and hard to 
> understand.

Agreed, I have spent quite some time learning how it works. I think 
Betwixt would be much easier to understand with a clearer layering and 
clearer responsiblity for the different layers. This is done in JXPath 
as an related example. In JXPath all access to the Java beans are made 
through two interfaces: NodePointer and NodeIterator. As a consequence, 
one can quite easily use JXPath together with new data models and they 
have already implemented quite a few: Java Beans, DynaBeans, DOM and 
JDOM. For Jaxen there is a similar situation, all data is accesed 
through the Navigator interface. We would need such an interface in Betwixt.

As Betwixt currently is structured, the AbstractBeanWriter contains much 
knowledge about how the different descriptors together with Java beans 
should be translated to XML. All this knowledege should IMO be factored 
out from the AbstractBeanWriter to a new layer, like in JXPath or Jaxen. 
Furthermore the information about the structure of the produced XML 
document is mainly found in the XMLBeanInfo and the Descriptor classes, 
but some information (e.g. about ID generation), is found in the 
AbstractBeanWriter, IMO it would be much more easy to understand and 
mantain Betwixt if all such information could be moved to the 
XMLBeanInfo and Descriptor interfaces.

> it needs to be refactored but it's hard to see the right way to do this.

I'm working on refactoring Betwixt along the lines I propsed in my 
previous mail and have among other things moved the ID generation 
mechanism to Expression classes. Now, I guess it would be a tough task 
for you to review a very large patch file that affects several classes, 
on the other hand it is hard to know if a design idea works whithout 
implementing it.

I propose that we try to formulate a common vision for the improved 
internal design. We could do this by working on a design document in the 
jakarta-common Wiki. I could start by adding my proposal. Then we could 
work towards the high level design goal, in a number of small 
refactoring steps and thus avoid breaking anything along the way.

> there is a chronic shortage of good test cases. some stuff is a subtle 
> and so it's easy to make mistakes.

I'm aware of this OTH the only certain way to not break anything that 
works is to not do anything at all ;) Refactoring often work as a 
motivation for writing more test cases.

> maybe supporting DOM might be the key to a better structure but i'd 
> prefer it to be thought out properly before hand.

Yes, lets discuss design for a while, but we also should start 
incremental refactoring quite soon. Complete upfront design seldom work, 
and even worse: it tend to become extremely boring after a while ;)

> even though betwixt is an alpha, we're still pretty hot on 
> deprecation  and preserving compatibility (betwixt has an existing 
> user base). 

I'm not talking about changing any external contracts or behaviour (at 
least as long as they are correct), I'm only talking about making 
clearer internal contracts.

> 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. 

Sounds good.

/Daniel Fagerstrom

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

View raw message