Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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, 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 stateless/lightweight way for serving the choices. Both serve them with a request to the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? Yes. ((WebApplication))component.getApplication()).mountResource(...) But this may register/mount the resource many times - as many as this component is used. On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 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, 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 stateless/lightweight way for serving the choices. Both serve them with a request to the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? Yes. ((WebApplication))component.getApplication()).mountResource(...) But this may register/mount the resource many times - as many as this component is used. On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 = RequestCycle.get().urlFor(getSearchResultsResourcReference(), null); vars.put(sourceUrl, url); response.render(JavaScriptHeaderItem.forScript(template.asString(vars), jsId); where getSearchResultsResourcReference() creates (and saves in the app metadata) or retrieves the resource reference for searching. So I need a reference to the resource reference every time I use an autocomplete component. Am I missing something? Were you simply suggesting that instead of the resource I store the url in the app metadata? Does it make any difference? On Mon, Dec 15, 2014 at 10:36 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 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, 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 stateless/lightweight way for serving the choices. Both serve them with a request to the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? Yes. ((WebApplication))component.getApplication()).mountResource(...) But this may register/mount the resource many times - as many as this component is used. On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 = RequestCycle.get().urlFor(new MyResRef(), null); i.e. two different instances! They are matched by #equals(), not by identity Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Dec 15, 2014 at 10:46 PM, mscoon msc...@gmail.com wrote: 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 = RequestCycle.get().urlFor(getSearchResultsResourcReference(), null); vars.put(sourceUrl, url); response.render(JavaScriptHeaderItem.forScript(template.asString(vars), jsId); where getSearchResultsResourcReference() creates (and saves in the app metadata) or retrieves the resource reference for searching. So I need a reference to the resource reference every time I use an autocomplete component. Am I missing something? Were you simply suggesting that instead of the resource I store the url in the app metadata? Does it make any difference? On Mon, Dec 15, 2014 at 10:36 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 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, 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 stateless/lightweight way for serving the choices. Both serve them with a request to the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? Yes. ((WebApplication))component.getApplication()).mountResource(...) But this may register/mount the resource many times - as many as this component is used. On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 Grigorov mgrigo...@apache.org wrote: 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 = RequestCycle.get().urlFor(new MyResRef(), null); i.e. two different instances! They are matched by #equals(), not by identity Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Dec 15, 2014 at 10:46 PM, mscoon msc...@gmail.com wrote: 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 = RequestCycle.get().urlFor(getSearchResultsResourcReference(), null); vars.put(sourceUrl, url); response.render(JavaScriptHeaderItem.forScript(template.asString(vars), jsId); where getSearchResultsResourcReference() creates (and saves in the app metadata) or retrieves the resource reference for searching. So I need a reference to the resource reference every time I use an autocomplete component. Am I missing something? Were you simply suggesting that instead of the resource I store the url in the app metadata? Does it make any difference? On Mon, Dec 15, 2014 at 10:36 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 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, 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 stateless/lightweight way for serving the choices. Both serve them with a request to the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? Yes. ((WebApplication))component.getApplication()).mountResource(...) But this may register/mount the resource many times - as many as this component is used. On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 stateless/lightweight way for
serving the choices. Both serve them with a request to the page that
contains the autocomplete component. This provides flexibility (because you
can use the page state to adapt the returned choices) but also sounds quite
expensive.
Am I going too far here worrying about performance?
Also, if I wanted to use resources as Andrea suggested, the only way to
register them is via an initializer or at application start? Can't the
component register them?
Maybe register a resource that can be user tho dynamically register JSON
producers?
IJSONProducerT extend JSONABLE {
canHandle(Request request)
toJSON(T t)
}
the have an JSONProducersResource that:
1- allows to dynamically register IJSONProducer
2- Given a request determine if any of the JSON producers can handle the
request.
3- Use the one providing able to handle the request to serve it.
Component could register producers on demand.
On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org
wrote:
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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com
wrote:
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 produce JSON in output.
To configure them you might use a Wicket initializer:
http://wicket.apache.org/guide/guide/single.html#advanced_3
Hi all,
I am making an autocomplete component based on jquery-autocomplete.
I have currently implemented the data source using a stateless web
page
which writes the json response.
What I don't like about this is that it is a separate file/class from
my
autocomplete component. But I like that it's stateless.
Could I achieve the same effect (statelessness) using a dynamic
resource
registered/created from within the autocomplete component? In other
words
I
want the autocomplete component, upon creation, to register a resource
that
can be used to serve the autocomplete options. But I want the resource
to
be stateless and lightweight and the requests to return the
autocomplete
options should not have to go through the page that contains the
autocomplete component.
Furthermore, if I have the same autocomplete component twice in a
page,
the
resource should be registered only once and server requests for both
components.
Is this possible? Can you provide some guidelines?
Thanks
Marios
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Regards - Ernesto Reinaldo Barreiro
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 stateless/lightweight way for serving the choices. Both serve them with a request to the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? Yes. ((WebApplication))component.getApplication()).mountResource(...) But this may register/mount the resource many times - as many as this component is used. On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
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 the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: 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 13, 2014 at 7:50 PM, Andrea Del Bene an.delb...@gmail.com wrote: 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 produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
