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. 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.
> > 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'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.
>
> > 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.
And how about calling it DateParser rather than DateFormatter?
>
> that ticks all my boxes :)
Yeah, junit test cases - great!
>
> > 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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
