Return-Path: 
 <user-return-19671-apmail-commons-user-archive=commons.apache.org@commons.apache.org>
Delivered-To: apmail-commons-user-archive@www.apache.org
Received: (qmail 35411 invoked from network); 3 Aug 2007 08:11:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 3 Aug 2007 08:11:15 -0000
Received: (qmail 32081 invoked by uid 500); 3 Aug 2007 08:11:12 -0000
Delivered-To: apmail-commons-user-archive@commons.apache.org
Received: (qmail 31673 invoked by uid 500); 3 Aug 2007 08:11:10 -0000
Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@commons.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@commons.apache.org>
List-Post: <mailto:user@commons.apache.org>
List-Id: <user.commons.apache.org>
Reply-To: "Jakarta Commons Users List" <user@commons.apache.org>
Delivered-To: mailing list user@commons.apache.org
Received: (qmail 31664 invoked by uid 99); 3 Aug 2007 08:11:10 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Aug 2007 01:11:10 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [213.46.255.22] (HELO viefep18-int.chello.at) (213.46.255.22)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Aug 2007 08:10:46 +0000
Received: from [192.168.0.4] (really [84.113.196.60])
          by viefep18-int.chello.at
          (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP
          id <20070803081044.FYCX1375.viefep18-int.chello.at@[192.168.0.4]>
          for <user@commons.apache.org>; Fri, 3 Aug 2007 10:10:44 +0200
Subject: Re: [Digester] Generic digester patterns?
From: simon <simon.kitching@chello.at>
To: Jakarta Commons Users List <user@commons.apache.org>
In-Reply-To: <1E243DEC-B785-4269-ACC2-BF9925FF2F8D@ernstdehaan.com>
References: <0DB7A78C-D517-46C9-A156-D5359F4759F6@ernstdehaan.com>
	 <1186068453.6041.19.camel@simon-laptop>
	 <1186068624.6041.22.camel@simon-laptop>
	 <C59ABA1E-6A9A-40FE-9F3B-D9FD0778F041@ernstdehaan.com>
	 <1186086582.6095.19.camel@simon-laptop>
	 <1E243DEC-B785-4269-ACC2-BF9925FF2F8D@ernstdehaan.com>
Content-Type: text/plain
Date: Fri, 03 Aug 2007 10:10:21 +0200
Message-Id: <1186128621.6073.16.camel@simon-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

On Fri, 2007-08-03 at 08:48 +0200, Ernst de Haan wrote:
> Simon,
> 
> 
> Your in-depth answers are very much appreciated!
> 
> > I'm not quite sure what you mean by "re-use" here.
> >
> > What you're trying to implement isn't that common I think.  
> > Generally it
> > is known what child xml elements a particular xml element can have, so
> > writing explicit rules isn't a problem. Yes, the rules need  
> > updating if
> > a new child element must be supported, but in general the java code
> > needs to be updated anyway (eg to add a new setter method on the  
> > parent
> > class) and everything needs to then be retested so having to modify  
> > the
> > digester rules at the same time doesn't seem to me to be a big  
> > concern.
> 
> Well, in a typical configuration file, there are a lot of common data  
> types used. For example, in a configuration file for a user interface:
> - text string
> - integer number
> - color
> - font
> - etc.
> 
> These data types could be used in many different places in the  
> document, e.g.:
> 
> <Config>
>     <Background><Color ... /></Background>
>     <TitleText><Font ... /></TitleText>
>     <SubtitleText><Font ... /></SubtitleText>
>     <LabelText><Font ... /></LabelText>
> </Config>
> 
> It works when I resort to having one pattern for every higher level  
> element (Background, TitleText, etc.). But I would prefer to use  
> SetNesterPropertiesRule in combination with matchers for the lower- 
> level elements (Color, Font, etc.)
> 
> I hope this is a better explanation of what I meant to bring across...

Ok, I see what you mean. I don't think this is a very common scenario
(the same tags occurring with different parent tags) but I can see it
would be annoying to have to repeat the rules for each parent.

When using the direct java API for digester this isn't a problem; you
just write a subroutine that takes a pattern "prefix" and generates a
set of rules. Then you call that subroutine with "Background",
"TitleText" etc as parameters.

Perhaps the closest equivalent in xmlrules is to use xinclude or a DTD
entity? ie define a block of rules for color/font etc then reference
that block from within pattern blocks for background, titletext, ...

Using leading/trailing wildcards is not quite the same thing; with
wildcards things can go wrong if the user creates unexpected xml (eg a
Color tag directly under config). However if you're also validating the
input xml that problem can be ignored. So simply using one of the
non-default Rules implementation should also do what you want I think.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org