commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: [Digester] New rules
Date Thu, 04 Mar 2004 07:59:56 GMT
Simon Kitching wrote on Wednesday, March 03, 2004 11:54 PM:

> On Thu, 2004-03-04 at 11:11, robert burrell donkin wrote:
>> On 3 Mar 2004, at 08:41, Jörg Schaible wrote:
>>> Hi folks,
>>> what about adding new rules to digester? In my project I have two
>>> rules I can share: 
>>> 1) AddToMapRule
>>> Ctors:
>>>     AddToMapRule(int stackPosition, String key)
>>>     AddToMapRule(Map map, String key)
>>> The rule will peek the top level element of the stack and put it
>>> into a map. The map can be provided from the outside or is expected
>>> at the given stack position (generated by a previous rule). The key
>>> is requested as property from the top level element using the
>>> PropertyUtils. 
>>> Example:
>>>     digester.addObjectCreate("data", HashMap.class);
>>>     digester.addSetNext("data", "setItems");
>>>     digester.addObjectCreate("data/item", Item.class);
>>>     digester.addRule("data/item", new AddToMapRule(1, "id"));
>>>     digester.addCallMethod("data/item/id", "setId", 0, new Class[]
>>>     { Integer.class }); digester.addCallMethod("data/item/origin",
>>> "setOrigin", 0); 
> I'm not sure about this one. There are ways to implement this
> already, and I'm not convinced that a specific rule for
> handling Map objects is needed.

How? If you create a bean on the stack, how would you add it to a map? You must call "put"
taking a key and the object itself. All rules of the released 1.0-dev handle only one argument
for a call.

> In some ways it's nice,
> because it is obvious to users, but of course every rule
> added to Digester increases the jar size, the API complexity,
> and the maintenance load.

Will this be addressed in Digester2 ? I was really astonished, that the digester itself has
a method for any known rule. This makes the usage of self-written ones not too obvious. Personally
I would eliminate/deprecate all of them and just offer addRule. But this is getting OT for
this thread, for D2 I have other annotations anyway :)

>>> 2) DateFormatterRule
>>> Ctors:
>>>     DateFormatterRule(DateFormat format)
>>> The rule is used to convert an entry to a Date and push it onto the
>>> stack. The rule was not realized as Parameter rule, since the API
>>> prohibits the call of peekParams and pushParams (package scope
>>> instead of protected). See also Alex' mail about the subject.
>> i'm a bit confused by this last statement. i think that peekParams
>> and pushParams are public (at least in the CVS version).
> Looks like this has been changed from package to public since the
> last release. 

I looked only into the released sources for this one and there they have package scope.

> I'm not entirely sure making this method public is a good idea at the
> moment - I think the existing param-stack could be better
> designed, but
> once that API is public, digester is locked in to that
> design. I plan to
> give this some thought, and maybe raise a separate email on
> this topic.

By donating the rules, they will share the same package and I don't care anymore, but that's
not a real option for customer rules. I also read your proposal for named stacks and it makes
a lot of sense to me.

>>> Example:
>>>     digester.addRule("data/item/time", new DateFormatterRule(new
>>> SimpleDateFormat("yyyy/MM/dd hh:mm:ss"));
>>>     digester.addSetNext("data/item/time", "setTime");
>>> All of the rules support toString, the logger and have unit tests.
> Seems like a good idea to me.  Of course the ConvertUtils module can
> automatically do string->date already, right? But AFAIK it
> doesn't allow
> the user to specify the actual format of the input, so having a custom
> date-generating rule seems reasonable. I think it is a common enough
> use-case to be worth including in Digester.
> Not sure if it should be a CallParamRule variant or a kind of
> ObjectCreateRule (as currently implemented). Currently, I
> tend to think
> it should be rewritten as the former, but that's not a big job.

Well, using released 1.0-dev I couldn't :)

> And how about calling it DateParser rather than DateFormatter?

Don't care. If you want to have it as parameter rule, you probably may reflect this also in
its name ...

>> that ticks all my boxes :)
> Yeah, junit test cases - great!

I'm always glad, if I know that my code works.

>>> Are you interested and what do I have to do for the donation?
>> AIUI so long as you own the copyright to these works and they have
>> not been published elsewhere then all you need to do is to post them
>> to this list (probably in a zip or a tar) in an email expressing your
>> intention to donate them to the ASF. (or you could create a
>> enhancement request in bugzilla and attach the code if that's
>> easier.) 

Fine. I'll put something to Bugzilla at least on the weekend (currently working for some commons-configuration


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message