Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 58899 invoked from network); 9 Oct 2003 15:35:36 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Oct 2003 15:35:36 -0000 Received: (qmail 13899 invoked by uid 500); 9 Oct 2003 15:35:12 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 13826 invoked by uid 500); 9 Oct 2003 15:35:12 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 13795 invoked from network); 9 Oct 2003 15:35:11 -0000 Received: from unknown (HELO smtp005.mail.ukl.yahoo.com) (217.12.11.36) by daedalus.apache.org with SMTP; 9 Oct 2003 15:35:11 -0000 Received: from suedu3-202-220.utaonline.at (HELO MEDION1) (christianessl@212.152.202.220 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 9 Oct 2003 15:35:12 -0000 To: Jakarta Commons Developers List Subject: Re: [HiveMind] more on BuilderFactory References: <00af01c38e61$db83dd90$d0020a0a@ALMIGHTYBEAST> <3F857CA9.2020905@comcast.net> Message-ID: Content-Type: text/plain; charset=iso-8859-15; format=flowed From: Christian Essl MIME-Version: 1.0 Date: Thu, 09 Oct 2003 17:36:06 +0200 In-Reply-To: <3F857CA9.2020905@comcast.net> User-Agent: Opera7.11/Win32 M2 build 2887 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 think this way we could also solve that chicken-egg problem with rules and translators: The HiveMind build in processing is kept. This build in processing is used by the ProcessingServices to have their rules, translators, xsl-functions etc defined/added. (ProcessingServices are only allowed to use the build in). To differentiate between the build in processing and the 'custom- processing' the configuration-point tag is just checked wheter it contains a tag. On Thu, 09 Oct 2003 11:20:09 -0400, Harish Krishnaswamy wrote: > Yeah, I like this idea. Options are good. > > Christian Essl wrote: > >> I am personally quite happy with the digester/translator aproach >> HiveMind uses currently. >> >> I like Knut's suggestion to split up the validating schema from the >> processing. >> >> Maybe in a later release of HiveMind it could be possible to use a >> something like this: >> >> >> .... >> >> .... >> >> >> >> The schema checks the elements and after this check the elements are >> given to the defined processing-service: >> >> public interface ProcessingService{ >> public List getContributions(Element[] processingContent,Element[] >> contributions,String config-id); >> } >> >> I think this way the configuration-point definer could choose the form >> he want's to define/parse the contributions. >> >> On Thu, 9 Oct 2003 08:35:43 -0400, Howard M. Lewis Ship >> wrote: >> >>> Been running around a lot, but found a few minutes to think about this >>> in more detail. >>> >>>> -----Original Message----- >>>> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden >>>> Sent: Tuesday, October 07, 2003 6:28 AM >>>> To: commons-dev@jakarta.apache.org >>>> Subject: Re: [HiveMind] more on BuilderFactory >>>> >>>> >>>> The more I think about this, the more I wonder if the XML processing >>>> rules and the BuilderFactory could be joined. Afterall, they do very >>>> similar things... >>>> >>>> Unlike in Digester the the HiveMind processing rules are written in >>>> XML. So how about using a more declarative notation? Take the schema >>>> from the "Startup" configuration point of the case study (descriptions >>>> skipped): >>>> >>> >>>> >>>> What if this were written in a more declarative way (resembling a >>>> pipeline as in Cocoon or Jelly) using XPath navigations to access >>>> attribute values: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>

>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>

>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> The problem here is that without the explicit stack-oriented approach >>> used with Digester, it isn't >>> clear what the top object on the stack is at the time the rules for the >>> invoke-static contribution >>> are executed. This is because wraps around