Re: Best way to store AJAX-changes of a select component
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best way to store AJAX-changes of a select component
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
smime.p7s
Description: S/MIME Kryptografische Unterschrift
Re: Best way to store AJAX-changes of a select component
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 smime.p7s Description: S/MIME Kryptografische Unterschrift
Re: Best way to store AJAX-changes of a select component
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 smime.p7s Description: S/MIME Kryptografische Unterschrift
Re: Best way to store AJAX-changes of a select component
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 smime.p7s Description: S/MIME Kryptografische Unterschrift
Re: Best way to store AJAX-changes of a select component
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 >>> 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-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >> >
Re: Best way to store AJAX-changes of a select component
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 >> 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-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >
Re: Best way to store AJAX-changes of a select component
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 > 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
Re: Best way to store AJAX-changes of a select component
On Fri, 04 Jan 2013 13:19:51 -0200, Stephan Windmüller 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
