>> : 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.
As Bill pointed out, even this example is possible (not allowing to
invoke entity twice, or making it more difficult, or only if the user
picks a type such as atom or another multipart one), but it makes the
DSL more complex. It's a decision to make - no right or wrong, but
points of view that favor or one or another side. Should I build any
other example on the current API? Such as the one with the entity
mentioned?
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Wed, Jul 13, 2011 at 11:17 AM, Bill Burke <bburke_at_redhat.com> 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.
>
>> - 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
>