You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by mscoon <ms...@gmail.com> on 2014/12/13 17:20:31 UTC
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?
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,
On Sat, Dec 13, 2014 at 11:08 PM, mscoon <ms...@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?
IJSONProducer<T 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 <mg...@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...@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-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@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?
Posted by mscoon <ms...@gmail.com>.
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 <mg...@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 <ms...@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:
> >
> > HashMap<String, 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 <mg...@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 <ms...@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 <
> mgrigorov@apache.org
> > >
> > > > wrote:
> > > > >
> > > > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon <ms...@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 <
> > > > mgrigorov@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.delbene@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-unsubscribe@wicket.apache.org
> > > > > > > > For additional commands, e-mail:
> users-help@wicket.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Should I use a (stateless) WebPage or a Resource to return a json
response for an autocomplete component?
Posted by Martin Grigorov <mg...@apache.org>.
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 <ms...@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:
>
> HashMap<String, 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 <mg...@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 <ms...@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 <mgrigorov@apache.org
> >
> > > wrote:
> > > >
> > > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon <ms...@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 <
> > > mgrigorov@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.delbene@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-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Should I use a (stateless) WebPage or a Resource to return a json
response for an autocomplete component?
Posted by mscoon <ms...@gmail.com>.
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:
HashMap<String, 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 <mg...@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 <ms...@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 <mg...@apache.org>
> > wrote:
> > >
> > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon <ms...@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 <
> > mgrigorov@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.delbene@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-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Should I use a (stateless) WebPage or a Resource to return a json
response for an autocomplete component?
Posted by Martin Grigorov <mg...@apache.org>.
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 <ms...@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 <mg...@apache.org>
> wrote:
> >
> > On Sun, Dec 14, 2014 at 12:08 AM, mscoon <ms...@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 <
> mgrigorov@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.delbene@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-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Should I use a (stateless) WebPage or a Resource to return a json
response for an autocomplete component?
Posted by mscoon <ms...@gmail.com>.
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 <mg...@apache.org>
wrote:
>
> On Sun, Dec 14, 2014 at 12:08 AM, mscoon <ms...@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 <mg...@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.delbene@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-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
Re: Should I use a (stateless) WebPage or a Resource to return a json
response for an autocomplete component?
Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Dec 14, 2014 at 12:08 AM, mscoon <ms...@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 <mg...@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...@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-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
Re: Should I use a (stateless) WebPage or a Resource to return a json
response for an autocomplete component?
Posted by mscoon <ms...@gmail.com>.
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 <mg...@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...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Should I use a (stateless) WebPage or a Resource to return a json
response for an autocomplete component?
Posted by Martin Grigorov <mg...@apache.org>.
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...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Should I use a (stateless) WebPage or a Resource to return a
json response for an autocomplete component?
Posted by Andrea Del Bene <an...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org