[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
From:       Simone Tripodi <simonetripodi () apache ! org>
Date:       2011-02-28 16:51:04
Message-ID: AANLkTi=WFhOJtdbhkUsDCd+C9qZtL0XCw2vNpsR4eLpi () mail ! gmail ! com
[Download RAW message or body]

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

@SuppressWarnings("unchecked")
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,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Feb 28, 2011 at 5:11 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
> On Mon, Feb 28, 2011 at 7:35 AM, Simone Tripodi
> <simonetripodi@apache.org> 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] http://markmail.org/message/5ry2lmfkpxkrqwh6
>> [2] http://markmail.org/message/qybp7ra3g5tpeayi
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


[prev in list] [next in list] [prev in thread] [next in thread]