On 07/13/2011 04:17 PM, Bill Burke wrote:
> 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.
No, certainly I would not want to limit the ability of filters and handlers to modify a request/response data. The
requirement above is targeted at the top-level (or application-level) fluent API.
>
>> - 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.
>
Yes, to satisfy this requirement to maximum, the API would need to be more complex, although not necessarily from the
user / usage point of view. While I am listing this requirement, I am aware of the trade-offs we already had to consider
earlier. We may not be able to fully satisfy the requirement, but we should still be able to use it when evaluating any
proposals or change requests.
Marek