You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Stephan Windmüller <st...@tu-dortmund.de> on 2013/01/04 16:19:51 UTC
Best way to store AJAX-changes of a select component
Hi!
I am developing a search component similar to this page:
http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/select1
The textfield should provide autocompletion based on the selection of
the select component. In order to remember the current selection, I
write a field in the Java class during the "valueChanged" event:
-----
private MyObject object;
Object onValueChangedFromMySelect(MyObject object) {
selectedObject = object;
[...]
}
List<String> onProvideCompletionsFromSearchField(String query) {
return possibleValues(query, object);
}
-----
Unfortunately this does not work as expected. Even when the field is
marked for flash persistence, the "provideCompletions" event is only
able to read the value once, after that it is null.
Is there a "best way" to store changes made by AJAX requests in the page?
TIA
Stephan
Re: Best way to store AJAX-changes of a select component
Posted by Geoff Callender <ge...@gmail.com>.
On 07/01/2013, at 11:21 PM, Stephan Windmüller wrote:
> On 07.01.2013 12:07, Geoff Callender wrote:
>
>> ZoneUpdater does change the URL:
>> listenerURIWithValue = addRequestParameter('param', param, listenerURIWithValue);
>
> You are right, I focused on the Java part.
>
>> Yes, the example uses @Persist but your problem is different -
>> you could avoid @Persist by trying what I suggested earlier:
>
> As I explained in my reply to this e-mail of yours, I am unsure on how
> to extend the JavaScript code. Is it necessary to create my own
> AutoComplete component which extends the current one or how do I add the
> JavaScript code properly?
I think you can leave the existing Autocomplete and its javascript alone.
Start by adding a simple JavaScript to the page - it should observe the "change" event of the Select element and, on change, modify the autocomplete element's url, $T(spec.elementId).autocompleter.url, appending the selected value as a a query parameter. Here's an example of a simple observer that observes "keyup" (whereas you should observe "change"):
http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/javascript
Once that's working you could do a reusable one that receives the 2 element ids as parameters, more like these:
http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/reusable
http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/robust
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best way to store AJAX-changes of a select component
Posted by Stephan Windmüller <st...@tu-dortmund.de>.
On 07.01.2013 12:07, Geoff Callender wrote:
> ZoneUpdater does change the URL:
> listenerURIWithValue = addRequestParameter('param', param, listenerURIWithValue);
You are right, I focused on the Java part.
> Yes, the example uses @Persist but your problem is different -
> you could avoid @Persist by trying what I suggested earlier:
As I explained in my reply to this e-mail of yours, I am unsure on how
to extend the JavaScript code. Is it necessary to create my own
AutoComplete component which extends the current one or how do I add the
JavaScript code properly?
Regards
Stephan
Re: Best way to store AJAX-changes of a select component
Posted by Geoff Callender <ge...@gmail.com>.
ZoneUpdater does change the URL:
listenerURIWithValue = addRequestParameter('param', param, listenerURIWithValue);
Yes, the example uses @Persist but your problem is different - you could avoid @Persist by trying what I suggested earlier:
"Perhaps you could add some javascript of your own that watches for changes in the Select, and appends the selected option to the url as a query parameter:
$T(spec.elementId).autocompleter.url += "?" + "selected=" + selected_option;
In your PROVIDE_COMPLETIONS handler you'd get the query parameter, using either @ActivationRequestParameter or Request#getParameter(String name)."
Cheers,
Geoff
On 07/01/2013, at 9:37 PM, Stephan Windmüller wrote:
> On 07.01.2013 10:57, Geoff Callender wrote:
>
>>>> Would it be possible to add the selection to the URL of the page
>>>> containing the search field? I am not sure about changing the activation
>>>> context with AJAX calls.
>> There should be no problem adding request parameters to the URL (even though the AJAX request is a POST). ZoneUpdater does exactly that:
>> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/onevent
>
> As far as I understand this example, the URL is not changed but fields
> are persisted with the @Persist annotation.
>
> Regards
> Stephan
>
Re: Best way to store AJAX-changes of a select component
Posted by Stephan Windmüller <st...@tu-dortmund.de>.
On 07.01.2013 10:57, Geoff Callender wrote:
>> > Would it be possible to add the selection to the URL of the page
>> > containing the search field? I am not sure about changing the activation
>> > context with AJAX calls.
> There should be no problem adding request parameters to the URL (even though the AJAX request is a POST). ZoneUpdater does exactly that:
> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/onevent
As far as I understand this example, the URL is not changed but fields
are persisted with the @Persist annotation.
Regards
Stephan
Re: Best way to store AJAX-changes of a select component
Posted by Geoff Callender <ge...@gmail.com>.
On 07/01/2013, at 8:06 PM, Stephan Windmüller wrote:
> On 04.01.2013 17:43, Thiago H de Paula Figueiredo wrote:
>
>>> Is there a "best way" to store changes made by AJAX requests in the page?
>> Have you tried non-flash session persistence
>
> This would break tabbed browsing. If I change the selection in one tab,
> the search field in a second tab will also act differently.
>
>> and setting the field to null after you don't need it anymore?
>
> Even if I ignore the confusion with tabbed browsing, I am not sure how
> to detect that the search field is not needed anymore. If a user does
> not click on a search result but on another navigational element
> instead, the field would still be persisted.
>
> Would it be possible to add the selection to the URL of the page
> containing the search field? I am not sure about changing the activation
> context with AJAX calls.
There should be no problem adding request parameters to the URL (even though the AJAX request is a POST). ZoneUpdater does exactly that:
http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/onevent
>
> Regards
> Stephan
>
Re: Best way to store AJAX-changes of a select component
Posted by Stephan Windmüller <st...@tu-dortmund.de>.
On 04.01.2013 17:43, Thiago H de Paula Figueiredo wrote:
>> Is there a "best way" to store changes made by AJAX requests in the page?
> Have you tried non-flash session persistence
This would break tabbed browsing. If I change the selection in one tab,
the search field in a second tab will also act differently.
> and setting the field to null after you don't need it anymore?
Even if I ignore the confusion with tabbed browsing, I am not sure how
to detect that the search field is not needed anymore. If a user does
not click on a search result but on another navigational element
instead, the field would still be persisted.
Would it be possible to add the selection to the URL of the page
containing the search field? I am not sure about changing the activation
context with AJAX calls.
Regards
Stephan
Re: Best way to store AJAX-changes of a select component
Posted by Geoff Callender <ge...@gmail.com>.
I meant:
$T(spec.elementId).autocompleter.url += "?" + "selected=" + selected_option;
On 05/01/2013, at 9:14 PM, Geoff Callender wrote:
> Autocomplete adds a bit of javascript to the client:
>
> $T(spec.elementId).autocompleter = new Ajax.Autocompleter(spec.elementId, spec.menuId, spec.url, spec.config);
>
> Perhaps you could add some javascript of your own that watches for changes in the Select, and appends the selected option to the url as a query parameter.
>
> $T(spec.elementId).autocompleter.url = "?" + selected_option;
>
> In your PROVIDE_COMPLETIONS handler you'd get the query parameter, using either @ActivationRequestParameter or Request#getParameter(String name).
>
> Geoff
>
> On 05/01/2013, at 3:55 AM, Taha Siddiqi wrote:
>
>> If autoComplete was having a context parameter you could have used the context. :)
>>
>> something I have done here
>>
>> http://tawus.wordpress.com/2012/11/25/tapestry-and-editable-for-bootstrap/
>>
>> regards
>> Taha
>>
>> On Jan 4, 2013, at 10:13 PM, Thiago H de Paula Figueiredo wrote:
>>
>>> On Fri, 04 Jan 2013 13:19:51 -0200, Stephan Windmüller <st...@tu-dortmund.de> wrote:
>>>
>>>> Hi!
>>>
>>> Hi!
>>>
>>>> Unfortunately this does not work as expected. Even when the field is
>>>> marked for flash persistence, the "provideCompletions" event is only
>>>> able to read the value once, after that it is null.
>>>
>>> That's exactly what the flash persistence is supposed to do: once read, the value is removed from the session.
>>>
>>>> Is there a "best way" to store changes made by AJAX requests in the page?
>>>
>>> Have you tried non-flash session persistence and setting the field to null after you don't need it anymore?
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>
Re: Best way to store AJAX-changes of a select component
Posted by Stephan Windmüller <st...@tu-dortmund.de>.
On 05.01.2013 11:14, Geoff Callender wrote:
> Perhaps you could add some javascript of your own that watches for
> changes in the Select, and appends the selected option to the url as a
> query parameter.
>
> $T(spec.elementId).autocompleter.url = "?" + selected_option;
>
> In your PROVIDE_COMPLETIONS handler you'd get the query parameter,
> using either @ActivationRequestParameter or
> Request#getParameter(String name).
That sounds like the solution I searched for because it stores the
selection in the URL.
Can you tell me how to add extend the existing JavaScript? Do I have to
extend the AutoComplete component and provide my own autocomplete.js or
is there an easier way?
Regards
Stephan
Re: Best way to store AJAX-changes of a select component
Posted by Geoff Callender <ge...@gmail.com>.
Autocomplete adds a bit of javascript to the client:
$T(spec.elementId).autocompleter = new Ajax.Autocompleter(spec.elementId, spec.menuId, spec.url, spec.config);
Perhaps you could add some javascript of your own that watches for changes in the Select, and appends the selected option to the url as a query parameter.
$T(spec.elementId).autocompleter.url = "?" + selected_option;
In your PROVIDE_COMPLETIONS handler you'd get the query parameter, using either @ActivationRequestParameter or Request#getParameter(String name).
Geoff
On 05/01/2013, at 3:55 AM, Taha Siddiqi wrote:
> If autoComplete was having a context parameter you could have used the context. :)
>
> something I have done here
>
> http://tawus.wordpress.com/2012/11/25/tapestry-and-editable-for-bootstrap/
>
> regards
> Taha
>
> On Jan 4, 2013, at 10:13 PM, Thiago H de Paula Figueiredo wrote:
>
>> On Fri, 04 Jan 2013 13:19:51 -0200, Stephan Windmüller <st...@tu-dortmund.de> wrote:
>>
>>> Hi!
>>
>> Hi!
>>
>>> Unfortunately this does not work as expected. Even when the field is
>>> marked for flash persistence, the "provideCompletions" event is only
>>> able to read the value once, after that it is null.
>>
>> That's exactly what the flash persistence is supposed to do: once read, the value is removed from the session.
>>
>>> Is there a "best way" to store changes made by AJAX requests in the page?
>>
>> Have you tried non-flash session persistence and setting the field to null after you don't need it anymore?
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
Re: Best way to store AJAX-changes of a select component
Posted by Taha Siddiqi <ta...@gmail.com>.
If autoComplete was having a context parameter you could have used the context. :)
something I have done here
http://tawus.wordpress.com/2012/11/25/tapestry-and-editable-for-bootstrap/
regards
Taha
On Jan 4, 2013, at 10:13 PM, Thiago H de Paula Figueiredo wrote:
> On Fri, 04 Jan 2013 13:19:51 -0200, Stephan Windmüller <st...@tu-dortmund.de> wrote:
>
>> Hi!
>
> Hi!
>
>> Unfortunately this does not work as expected. Even when the field is
>> marked for flash persistence, the "provideCompletions" event is only
>> able to read the value once, after that it is null.
>
> That's exactly what the flash persistence is supposed to do: once read, the value is removed from the session.
>
>> Is there a "best way" to store changes made by AJAX requests in the page?
>
> Have you tried non-flash session persistence and setting the field to null after you don't need it anymore?
>
> --
> Thiago H. de Paula Figueiredo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: Best way to store AJAX-changes of a select component
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 04 Jan 2013 13:19:51 -0200, Stephan Windmüller
<st...@tu-dortmund.de> wrote:
> Hi!
Hi!
> Unfortunately this does not work as expected. Even when the field is
> marked for flash persistence, the "provideCompletions" event is only
> able to read the value once, after that it is null.
That's exactly what the flash persistence is supposed to do: once read,
the value is removed from the session.
> Is there a "best way" to store changes made by AJAX requests in the page?
Have you tried non-flash session persistence and setting the field to null
after you don't need it anymore?
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org