session invalidateNow vs invalidate

2014-12-15 Thread Francois Meillet
just a reminder 

session invalidateNow vs invalidate


if session#invalidateNow is called before a setResponsepage
then the application#sessionUnbound is called twice. 
as invalidateNow is invoked in session#detach.

ko
getSession().invalidateNow();
setResponsePage(Logout.class);

ok
# Invalidates this session at the end of the current request
getSession().invalidate();
setResponsePage(Logout.class);


Fran├žois Meillet



-
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
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: [SOLVED] how to write Form html in separate Form.html file

2014-12-15 Thread armandoxxx
have any other ideas how to mark topic as solved ? Would appreciate
suggestion!

regards
Armando

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/SOLVED-how-to-write-Form-html-in-separate-Form-html-file-tp4668691p4668782.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Reusable form fields ... the proper way disucssion

2014-12-15 Thread armandoxxx
Hey guys

I would like to know to properly do this in wicket. 

I have form fields that I would like to use in several forms ... 

lets say I want a model object for a 
SearchFields {country, language}   properties in brackets
and then I extend it with 
UserSearchFields {userTags}
and
CustomerSearchFields {customerTags}
and put it into models ... 
1. Model.of()
2. new PropertyModel(new {onOfTheseExtendedObjects}(), {propertyName});
3. new CompoundPropertyModel(new {onOfTheseExtendedObjects}())

so I create Common component with fields for country and language, then I
create separate components for UserTagsComponent (with userTags field) and
CustomerTagsComponent (with customerTags field). 

I create different forms:
UserForm  which adds model of new UserSearchFields object and both Common
and UserTagsComponent components .
CustomerForm which adds model of new CustomerSearchFields object and both
Common and CustomerTagsComponent.

my questions are:
1. what component to use to wrap fields to reuse them and add them to form? 
I tried FormComponentPanel but my model (CompoundPropertyModel) object did
not include the FormComponentPanel name property; for exmaple:
searchFields, so I changed my panel with fields to ordinary Panel (then
using my CompoundPropertyModel worked as expected)
2. what model implementation to use so Form would understand the fields in
sub components... I tried PropertyModel ... but I had a problem when I
called setDefaultModelObject(new CustomerSearchFields()) on my form ...
values were not set. 

I read reference and wicket book .. I understand how model implementations
work .. I'm just not sure how to make it work properly If I use sub
components for common fields ... 

regards

Armando


 














--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Reusable-form-fields-the-proper-way-disucssion-tp4668783.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org