Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-15 Thread mscoon
Thanks Martin for your answer. Is storing the resource reference in the application metadata once it's created and retrieving it from the metadata on subsequent uses a safe way to create it only once? On Mon, Dec 15, 2014 at 9:19 AM, Martin Grigorov mgrigo...@apache.org wrote: On Sun, Dec 14,

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-15 Thread Martin Grigorov
With proper synchronization - yes. But I think you won't need to retrieve it later at all. So just make sure it is not added several times Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Dec 15, 2014 at 10:31 PM, mscoon msc...@gmail.com wrote: Thanks

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-15 Thread mscoon
Hmm now I'm a bit confused. I have a TextTemplate that generates the JQuery autocomplete javascript. I need to pass it the url to retrieve the search results from. So I do: HashMapString, CharSequence vars = new HashMap(); CharSequence url =

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-15 Thread Martin Grigorov
1. Since you use the same ResRef for all autocompleters then you can just mount it at start time within MyApp#init(). 2. Wicket uses ResourceReference#equals() to find the mounted ResRef so you can do: - mountResource(/some/path/, new MyResRef()) - CharSequence url =

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-15 Thread mscoon
I am not using the same ResourceReference. getSearchResultsResourcReference() is overridden in subclasses to return a different resource reference as needed. Anyway I think now I understand how to mount the resource from within the component. Thanks! On Mon, Dec 15, 2014 at 10:57 PM, Martin

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-14 Thread Ernesto Reinaldo Barreiro
Hi, On Sat, Dec 13, 2014 at 11:08 PM, mscoon msc...@gmail.com wrote: Thank you both for your answers. I have reasons to roll my own autocomplete component. But I did take a look at the way wiqiery and wicket-jquery are serving the choices. As far as I can tell neither is using a

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-14 Thread Martin Grigorov
On Sun, Dec 14, 2014 at 12:08 AM, mscoon msc...@gmail.com wrote: Thank you both for your answers. I have reasons to roll my own autocomplete component. But I did take a look at the way wiqiery and wicket-jquery are serving the choices. As far as I can tell neither is using a

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-13 Thread Andrea Del Bene
Hi, I suggest you to use a resource instead of an adapted stateless page. Wicketstuff has a module with special Wicket resources to implement REST api: https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/wicketstuff-restannotations-parent. Here you can find resources that already

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-13 Thread Martin Grigorov
Hi, There are few very good integrations between Wicket and JQuery UI. Check https://github.com/sebfz1/wicket-jquery-ui and https://github.com/WiQuery/wiquery Both of them provide autocomplete component. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Dec

Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?

2014-12-13 Thread mscoon
Thank you both for your answers. I have reasons to roll my own autocomplete component. But I did take a look at the way wiqiery and wicket-jquery are serving the choices. As far as I can tell neither is using a stateless/lightweight way for serving the choices. Both serve them with a request to