Choice is good I agree. Commons CSV will also support annotated POJO,
that will give two ways to use the API.
Emmanuel Bourg
Le 16/03/2012 22:26, Simone Tripodi a écrit :
Hi all,
whatever name/pattern is called what we intend to apply, the result
doesn't change :P
Jokes a part, given the past experience of Digester3, as reported by
Matt and James, I can suggest you to not limit to users the
possibilities to chose their preferred approaches.
Digester3 - which of course has a larger set of APIs - allows users
configuring it with four APIs set:
* plain old Digester2.X addRule() alike methods;
* the RulesBinder fluent APIs;
* Annotated POJOs, built on top of RulesBinder;
* XML descriptors, built on top of RulesBinder.
no restrictions - just provide the n API layers that users want/need
on top of one in order to centralize the errors and make them
satisfied (which is he most important side, IMHO).
When developing Digester3, I wondered who would have used the xmlrules
today: pooff, magically a users not only is using it, he's also
contributing on making it betetr on supporting multi-thread
environments.
So, concluding: instead of choosing which approach has to be applied,
just apply both as Seb is proposing.
Just my 0.02 cents,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Mar 16, 2012 at 5:40 PM, James Carman
<jcar...@carmanconsulting.com> wrote:
Did I say they were the same?
On Mar 16, 2012 12:22 PM, "Emmanuel Bourg"<ebo...@apache.org> wrote:
Le 16/03/2012 13:34, James Carman a écrit :
+1 for builder pattern and fluent API
Fluent API != Builder Pattern
They are similar because they use method chaining, but that's not
equivalent.
http://martinfowler.com/bliki/**FluentInterface.html<http://martinfowler.com/bliki/FluentInterface.html>
http://en.wikipedia.org/wiki/**Fluent_interface<http://en.wikipedia.org/wiki/Fluent_interface>
http://en.wikipedia.org/wiki/**Builder_pattern<http://en.wikipedia.org/wiki/Builder_pattern>
Emmanuel Bourg
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
