commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Date Mon, 28 Feb 2011 16:51:04 GMT
Hi Matt!!!
thanks a lot for your feedbacks, you know I never consider them as $0.02 :)

To reply to your question: I'm sure it is possible adapting the
Module/EDLS over the existing Digester, adapting the existing
configuration layer, but the core conceptual difference is that the
current Digester works according to "given a Digester instance,
configure it", my proposal instead works according to "given a
configuration, create Digester instances".
Moreover I tried to improve the design to make the Digester extensions
easier to integrate: I noticed that rules defined in xml, annotations
and plugins, to gain the maximum benefit, guided users to use the
proper loader; in this version, there is only one universal loader,
able to load all the different modules.

+1000 to apply your suggestion, I really like it, this evening I'll
give a try to it modify the code and modify the tests, what persuaded
me to apply this modification was that I was convinced I needed the
Class of the returned type, something like

public <T> T parse(InputSource input, Class<T> returnedType) throws
IOException, SAXException {
 return returnedType.cast(this.root);

that I don't like and wouldn't be very useful in therms of APIs design :P

Thanks a *lot* for your precious suggestion, I hope you have the
pleasure to get more familiar with the Digester and I'd really like
having you more involved :)
Have a nice day,

On Mon, Feb 28, 2011 at 5:11 PM, Matt Benson <> wrote:
> On Mon, Feb 28, 2011 at 7:35 AM, Simone Tripodi
> <> wrote:
>> Good morning all guys,
>> in the last month I've invested my spare time on redesigning a new
>> potential version of the Digester component in Sandbox, according to
>> what I proposed time ago on dev ML[1].
>> The experiment is complete at 95%, is not of course a release but
>> there are enough tests/samples/docs to start playing with it.
>> I also sent an email to users ML[2] requesting for feedbacks,
>> unfortunately no one expressed his opinion yet, but I'll be patient at
>> least for the next 2-3 weeks before pushing a request again.
>> I'd like to ask also your feedbacks and suggestions, in case you would
>> be interested in a potential promotion on Proper, or it should be
>> contributed somewhere else like extras, but I hope it will find a
>> place in commons.
>> As Rahul proposed, since there are APIs breakage, maybe it should be
>> taken in consideration as a new component, but at the same time as
>> Matt suggested, since it processes inputs in the same way, maybe is
>> just a major release.
>> WDT? What are your thoughts about it? Sorry if it looks like a silly
>> question but I've never taken part of a sandbox promotion.
>> Looking forward to hear from you, have a nice day!
> I've never used the existing [digester] component but having read over
> the documentation of the new component/version it looks quite nice to
> use.  Not being a user I don't immediately appreciate exactly what the
> pain level of upgrading would be (I think I mentioned this before)....
> in the event that it is deemed to be large, is there any way to design
> a workalike for the [digester] 2.x configuration style?  If not, why
> not?
> Also, when I was skimming the examples/APIs/code yesterday (my vanity
> having triggered my curiosity to see just how my [proxy] 2 work had
> influenced you ;)  ) I noticed that the top-level Digester APIs might
> benefit from the "auto-casting" return type trick (of which I don't
> know the common name, if one exists) whereby the compiler
> automatically does the cast for you for assignments, e.g.:
> @SuppressWarnings("unchecked")
> public <T> T parse(InputSource input) throws IOException, SAXException {
>  .
>  .
>  .
>  return (T) this.root;
> }
> client code:
> Foo foo = digester.parse(...);
> which IMO can make things a little easier on users who (think they)
> know what type of object they expect.  Arguably you could do it
> throughout Digester/Impl wherever you have Object return types; others
> might disagree.
> $0.02,
> Matt
>> Simo
>> [1]
>> [2]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message