What about interceptors/filters? Or does this fall under "extensions"?
On 7/13/11 9:30 AM, Marek Potociar wrote:
> - API must eliminate possibility to write illegal constructs in the fluent API
> : e.g. invocation.method("PATCH").get();
>
I think I made a point earlier that the method may needed to be changed
by an interceptor, but I don't think you mean to take away this ability.
> - API must allign well with the IDE code-completion
> : the IDE code completion should be able to provide relevant hints for the fluent API based on the context
> : e.g. once the entity was set, the IDE would not list the entity() method in the fluent method invocation chain code
> completion again (this is an illustrative example, not satisfiable with the current API)
>
I'd like to see this explored. Especially by Guilherme as he seems to
have a lot of experience with this in his own api. Still, I do think a
simple class hierarchy also has merits and I believe heading down this
route will create a much more complex hierarchy.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com