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, 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?

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 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?

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 =
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?

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 = 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?

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 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?

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 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?

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 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?

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 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?

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 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?

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 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