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 <[email protected]>
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 <[email protected]> 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 <[email protected]>
> > wrote:
> > >
> > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon <[email protected]> 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 <
> > [email protected]>
> > > > 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 <
> > [email protected]
> > > >
> > > > > 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: [email protected]
> > > > > > For additional commands, e-mail: [email protected]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
