Return-Path: Delivered-To: apmail-avalon-dev-archive@www.apache.org Received: (qmail 44734 invoked from network); 24 Oct 2003 21:21:21 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 24 Oct 2003 21:21:21 -0000 Received: (qmail 15472 invoked by uid 500); 24 Oct 2003 21:21:03 -0000 Delivered-To: apmail-avalon-dev-archive@avalon.apache.org Received: (qmail 15429 invoked by uid 500); 24 Oct 2003 21:21:03 -0000 Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list dev@avalon.apache.org Received: (qmail 15370 invoked from network); 24 Oct 2003 21:21:02 -0000 Received: from unknown (HELO onramp.i95.net) (205.177.132.17) by daedalus.apache.org with SMTP; 24 Oct 2003 21:21:02 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.10/8.12.9) with ESMTP id h9OLL78M008402 for ; Fri, 24 Oct 2003 17:21:08 -0400 Message-ID: <3F9997C4.2020503@apache.org> Date: Fri, 24 Oct 2003 17:21:08 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Documenting the TreeBuilder stuff Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I started putting in some information that would at least document the interfaces alot better based on what I saw on the list so far. I put Each type of ProcessingNodeBuilder or ProcessingNode interface is nicely separated, and they do one thing and one thing well. I really don't have any issues with that at all. The TreeBuilder interface is much less straightforward. It mixes the concerns of the meta information for the language type captured in the config file with a bunch of processing things. I think we should look at separating the interface into more logical units. That would help make it more understandable. For instance, we have a TreeBuilder which represents the language. That is nice and good. However, IMO it has one responsibility: to create ProcessingNodeBuilders for a particular file. The root ProcessingNodeBuilder in turn should have the responsibility of creating the ProcessingTree. The ProcessingTree in turn is used directly to process requests. So, in essence, we have a couple of roles here--which might even simplify the implementation a bit: * TreeBuilder: Create a ProcessingNodeBuilder tree. (what goes on in the implementation should not be exposed in the interface) * RootProcessingNodeBuilder: Create a Processor (which is implemented by the ProcessingNodes) * Processor: The actual runtime system we use (the assembled sitemap so to speak). Currently, it looks like there are implementation details exposed in the TreeBuilder, mixed with runtime details exposed for the processing node builders. I dunno, though. Do we want the TreeBuilder to only expose an interface to get a particular Processor based on a URI??? I'm undecided. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For additional commands, e-mail: dev-help@avalon.apache.org