from the outside it seems like a rather complex and rare usecase. you
are welcome to create a jira issue with the hooks you need to
implement this in the channel manager js class. preferrably with a
patch.

-igor

On Mon, Jan 17, 2011 at 10:49 PM, Frank van Lankvelt
<[email protected]> wrote:
> I can, and generally I'm able to resolve the race between multiple xhr
> requests.  But only by using synchronous requests.  I was hoping to be
> able to do it using async only (synchronous xhr is evil, as I've seen
> Mathej remark in an old thread).  So being able to schedule a request
> on a channel, before the call that invokes the pre-call listener is
> sent, would be the perfect solution.
>
> Perhaps hooking the channel manager would provide a way to schedule a
> flush before the actual call is made?  Should at least keep everything
> async, so UI responsive.
>
> Thanks for reading my rambling,
> Cheers, Frank
>
>
> Op 18 jan. 2011 om 01:35 heeft Igor Vaynberg <[email protected]>
> het volgende geschreven:
>
>> can you do the flushing yourself by registering a 
>> wicket.ajax.pre-call-handler?
>>
>> -igor
>>
>> On Mon, Jan 17, 2011 at 2:57 AM, Frank van Lankvelt
>> <[email protected]> wrote:
>>> I'm regularly running into problems when integrating client-side ajax code.
>>>  The issue is that the client-side code is doing throttled asynchronous
>>> calls to wicket ajax behaviors.
>>> Now, this generally works fine until I want to integrate this with native
>>> wicket calls (links, buttons).  Then, such throttled calls should be flushed
>>> before the native request is sent to the server.
>>>
>>> The only way I can see/make this work is by registering pre-call handlers
>>> and doing the requests synchronously from the pre-call handler.
>>> A short explanation; the request cannot be done asynchronously as there is
>>> no guarantee that it will arrive at the server before the original call
>>> (that triggered the pre-call handler) arrives.
>>> This is clumsy and, generally, error-prone.
>>>
>>> It also appears to be partly re-doing what Wicket's channels already do, as
>>> channels take care of request ordering.  So I wonder whether I am
>>> overlooking something.  How do you guys handle this?
>>>
>>> Thinking out loud: would it be possible to have a 'throttled' channel that
>>> is flushed whenever a request is scheduled on the default channel ("0|s")?
>>> That way, third-party JS lib integrations could schedule calls to this
>>> channel on every key-stroke, having the synchronization handled
>>> automatically.
>>>
>>> cheers, Frank
>>>
>>>
>>> --
>>> Hippo Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20
>>> 522 4466
>>> USA  • San Francisco 755 Baywood Drive, Second Floor •  Petaluma, CA. 94954
>>> •  +1 877 414 4776 (toll free)
>>> Canada    •   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC H2T
>>> 1S5  •  +1 (514) 316 8966
>>> www.onehippo.com  •  www.onehippo.org  •  [email protected]
>>> ________________________________________________________________
>>> This e-mail may be privileged and/or confidential, and the sender does
>>> not waive any related rights and obligations. Any distribution, use or
>>> copying of this e-mail or the information it contains by other than an
>>> intended recipient is unauthorized. If you received this e-mail in
>>> error, please advise me (by return e-mail or otherwise) immediately.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to