Hi
On 26/08/11 19:48, Marek Potociar wrote:
>
>
> On 08/26/2011 08:03 PM, Bill Burke wrote:
>>
>>
>> On 8/26/11 12:22 PM, Sergey Beryozkin wrote:
>>> On 26/08/11 17:19, Marek Potociar wrote:
>>>>
>>>>
>>>> On 08/26/2011 06:03 PM, Sergey Beryozkin wrote:
>>>>> In the previous revision Invocation was a 'dead' redundant entity
>>>>> only waiting to be dropped. It's back...
>>>>
>>>> As author, I disagree. Invocation is the encapsulation of command
>>>> pattern concept. It would not be dropped.
>>>
>>> As I said in the other email, I'm fine with it staying, as long as we
>>> can come up with a more or less realistic example showing that command
>>> pattern in action, can you please think of one ? I'll +1 if yes
>>>
>>
>> Sergey has a huge point which I alluded to in a previous email. Wasn't the command pattern something somebody suggested
>> (me I think), rather than based on user input? Taking it out simplifies things a lot.
>>
>>
>
> Yes, it was you who requested to add invocation:
>
> On 05/23/2011 03:27 PM, Bill Burke wrote:
>>
>> BTW, my original proposal with execute() and resolve() also works well with a command pattern. For example, you could
>> have one piece of code that queues up a bunch of different HTTP requests that needs to be executed. The executor just
>> calls execute() on each ClientRequest.
>
> Are you now suggesting we take the generic invocation out?? Apart from losing a lot of potential flexibility I don't see
> how that's going to improve things. The fluent client API is now pretty much clean, easy to use and understand, fluently
> consistent and still pretty concise. At the same time, it is possible to flexibly tweak any aspect of a request even
> outside of the filter, if the app desing requires it. I'm afraid that, at this point, removing the invocation would put
> us several steps back in discussion about what would we need to remove from the request API to keep the fluent flow
> consistent while still being able to make invocation extend the http request and not sacrifice any major functionality
> of filters... I am not sure we want to go back there. At least certainly not me.
I was thinking about it on the way home - yes, even though it's Friday :-).
I thought about the following compromise.
In the previous trunk's revision Invocation was encapsulating the idea
of a builder pattern perfectly well. The only thing one can do with it
was to get to it via Target,prepare()-> http verb factory method().
At this stage Invocation is completely initialized and ready be consumed
by a function, batch processor, etc. The only thing a generic batch
handler can do with it is to invoke() or submit().
I appreciate the occasional necessity to batch requests and generalize
the processing somehow.
I think the major tension on the API is coming due to the original idea
to get the transition from Target to Invocation working. That said,
attempting to combine/implement two ideas (1st one - make an HTTP
request, the other one - make sure this and other requests it can be
used by a generic handler) is somewhat problematic,
I thought (assuming the previous revision is there) to leave things
exactly the same way they were, Target being a self-contained entity,
and Invocation being what it is for - an invocable entity. But break a
transitional link between Target and Invocation - and support two flows.
One for creating a Target-ed request,
The other one for creating a generically invocable Invocation by simply
moving Target.prepare to Invocation, make it accept Target, and making
it static.
Thus, in the prev revision, Target stays unchanged, and only its prepare
is dropped.
Invocation stays unchanged, and only
static InvocationBuilder prepare(Target)
is added.
Thus we have a flow for making perfect HTTP invocation, always ending at
Target.
And we can always do, when needed
Invocation.prepare(target).get().invoke();
Now, I've just seen Bill's latest proposal - so that may lead to a much
cleaner solution, can't handle analyzing it right now :-) - but just
wanted to dump at the moment what I was thinking and finally start
looking toward my weekends :-)
Sergey
>
> Marek
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com