Xapi-J: an architectural detail

[Chris Lloyd]

>John Tigue wrote:
>>
>>I agree. I think we should follow the Visitor design pattern. Quoting
>>from Gamma's _Design_Patterns_: "Intent: Represent an operation to be
>>performed on the elements of an object structure. Visitor lets you
>>define a new operation without changing the classes of the elements on
>>which it operates." Here the operation is tree interation.
>

Yes, Our whole system is based on "Design Patterns". We use the visitor
pattern for formatting output and for operations where we walk a subtree
from stem to stern. They are useful and easy to implement. Visitors are
good for moving an operation outside a class. They are not so good for
defining and extending complex walking tasks.

We find it necessary to have iterators for complex walking tasks. You can
let an iterator drive a visitor as well. We are doing very complex queries
right now using iterators, algorithmns, functions, and operators. The last
three patterns are borrowed from STL. The problem with the last three
patterns for Java is that they are template driven. A very complex tree
walking query/algorithmn can be formulated in a single line of C++. I'm
sure they could be adapted to Java.

We are dealing with tree versioning as well, so we have trees within trees.
You just can't expect to walk this stuff without some well abstracted
navigation patterns.

>I wrote:
>> The idea of inheriting from IContainer is a good one. Polymorphism is
>> very
>> useful when it comes time to write navigation classes. A base class
>> for all
>> objects in the tree is very important!! We'll call this INode.
>>

>
>public interface INode    {
>    // What do we put in here?
>    }
>

It is not necessary for anything to be in the base class. It is just
necessary for there to be one.

For example: An Iterator has a very simple interface

public interface ITreeIterator
{
	ITreeIterator(INode, ICursor iCursor, INodeIterFactory iFactory);
	bool next(); // walk to the next node
	INode current(); // return the current node
	long GetIterLevel(); // return how many tags deep we are from starting
position
}

We construct the iterator with a current node which can be the document
root or any object in the tree. We use a cursor which externalizes the
walking algorithmn(forward, backward, follow links) and we use a Factory
which provides the algorithmns for walking each object type in the tree.

This iterator will return different objects in the tree or maybe even walk
the tree differently depending on the factory and cursor that it is
constructed with. 

This iterator will not work without a common base class because the
iterator knows NOTHING about the types of objects in the tree. It only
knows what an INode is.

>So the interfaces in Xapi-J would extend INode like this?
>
>public interface INode {...}
>
>public interface IContainer extends INode{...}
>
>public interface IElement extends IContainer {...}
>
>This way an IElement is also an INode so passing via base interface can
>be done for any object in the model. We're still dealing purely with
>interfaces so vendors are still free to implement their own base
>classes. This also could be mapped to CORBA, DCOM, and others.

YES!

Chris Lloyd
POET Software

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)