Avoiding database operations during onActivate() phase is pretty obvious,
but it's not applicable here, because we need to handle database object
instantiation result (at least). As a simple example, if user doesn't have
access to an object requested, we need to redirect him to a login page. We
can
Caching is definitely possible. But during onActivate() we cannot reliably
determine whether it was caused by autocomplete event (thus we can use
cached data), or it was caused by any other event (in which case we can't
use cached data).
So separating suggestions data source completely from the pa
Most of the page requests are in fact AJAX (page contains a lot of zone
updates besides autocomplete events). So distinguishing by isXHR() doesn't
help.
On Thu, May 15, 2014 at 6:39 PM, Michael Gentry wrote:
> Hi Ilya,
>
> onActivate() gets called for both normal page render requests and AJAX/XH
That's why I advise the following:
http://jumpstart.doublenegative.com.au/jumpstart7/examples/navigation/onactivateandonpassivate/3
HTH,
Geoff
On 8 May 2014, at 10:33 pm, Ilya Obshadko wrote:
> It turns out that running an event handler (onProvideCompletionsFrom)
> in the same co
Hi Ilya,
onActivate() gets called for both normal page render requests and AJAX/XHR
requests (used by the autocomplete). Have you tried:
@Inject
private Request request;
and calling the isXHR() method in request in your onActivate() to determine
if the request is normal or AJAX?
onActivate()
{
Could you cache your hibernate results for subsequent calls?
- Original Message -
From: Ilya Obshadko
To: Tapestry users
Sent: Thursday, May 08, 2014 1:33 PM
Subject: autocomplete data source
It turns out that running an event handler (onProvideCompletionsFrom)
in the sa
