[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Xapi-J: an architectural detail
>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@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|