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
