session invalidateNow vs invalidate
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?
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 wrote: > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon 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 > > 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 > > > > wrote: > > > > > > > > Hi, > > > > > > > > I suggest you to use a resource instead of an adapted stateless page. > > > > Wicketstuff has a module with special Wicket resources to implement > > REST > > > > api: https://github.com/wicketstuff/core/tree/master/ > > > > jdk-1.7-parent/wicketstuff-restannotations-parent. Here you can find > > > > resources that already produce JSON in output. > > > > To configure them you might use a Wicket initializer: > > > > http://wicket.apache.org/guide/guide/single.html#advanced_3 > > > > > > > > Hi all, > > > >> > > > >> I am making an autocomplete component based on jquery-autocomplete. > > > >> > > > >> I have currently implemented the data source using a stateless web > > page > > > >> which writes the json response. > > > >> > > > >> What I don't like about this is that it is a separate file/class > from > > my > > > >> autocomplete component. But I like that it's stateless. > > > >> > > > >> Could I achieve the same effect (statelessness) using a dynamic > > resource > > > >> registered/created from within the autocomplete component? In other > > > words > > > >> I > > > >> want the autocomplete component, upon creation, to register a > resource > > > >> that > > > >> can be used to serve the autocomplete options. But I want the > resource > > > to > > > >> be stateless and lightweight and the requests to return the > > autocomplete > > > >> options should not have to go through the page that contains the > > > >> autocomplete component. > > > >> > > > >> Furthermore, if I have the same autocomplete component twice in a > > page, > > > >> the > > > >> resource should be registered only once and server requests for both > > > >> components. > > > >> > > > >> Is this possible? Can you provide some guidelines? > > > >> > > > >> Thanks > > > >> Marios > > > >> > > > >> > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > >
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
With proper synchronization - yes. But I think you won't need to retrieve it later at all. So just make sure it is not added several times Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Dec 15, 2014 at 10:31 PM, mscoon 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 > wrote: > > > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon wrote: > > > > > > Thank you both for your answers. > > > > > > I have reasons to roll my own autocomplete component. But I did take a > > look > > > at the way wiqiery and wicket-jquery are serving the choices. > > > > > > As far as I can tell neither is using a stateless/lightweight way for > > > serving the choices. Both serve them with a request to the page that > > > contains the autocomplete component. This provides flexibility (because > > you > > > can use the page state to adapt the returned choices) but also sounds > > quite > > > expensive. > > > > > > Am I going too far here worrying about performance? > > > > > > Also, if I wanted to use resources as Andrea suggested, the only way to > > > register them is via an initializer or at application start? Can't the > > > component register them? > > > > > > > Yes. > > ((WebApplication))component.getApplication()).mountResource(...) > > > > But this may register/mount the resource many times - as many as this > > component is used. > > > > > > > > > > > > > > > > > > > On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov < > mgrigo...@apache.org> > > > wrote: > > > > > > > > Hi, > > > > > > > > There are few very good integrations between Wicket and JQuery UI. > > > > Check https://github.com/sebfz1/wicket-jquery-ui and > > > > https://github.com/WiQuery/wiquery > > > > Both of them provide autocomplete component. > > > > > > > > Martin Grigorov > > > > Wicket Training and Consulting > > > > https://twitter.com/mtgrigorov > > > > > > > > On Sat, Dec 13, 2014 at 7:50 PM, Andrea Del Bene < > an.delb...@gmail.com > > > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I suggest you to use a resource instead of an adapted stateless > page. > > > > > Wicketstuff has a module with special Wicket resources to implement > > > REST > > > > > api: https://github.com/wicketstuff/core/tree/master/ > > > > > jdk-1.7-parent/wicketstuff-restannotations-parent. Here you can > find > > > > > resources that already produce JSON in output. > > > > > To configure them you might use a Wicket initializer: > > > > > http://wicket.apache.org/guide/guide/single.html#advanced_3 > > > > > > > > > > Hi all, > > > > >> > > > > >> I am making an autocomplete component based on > jquery-autocomplete. > > > > >> > > > > >> I have currently implemented the data source using a stateless web > > > page > > > > >> which writes the json response. > > > > >> > > > > >> What I don't like about this is that it is a separate file/class > > from > > > my > > > > >> autocomplete component. But I like that it's stateless. > > > > >> > > > > >> Could I achieve the same effect (statelessness) using a dynamic > > > resource > > > > >> registered/created from within the autocomplete component? In > other > > > > words > > > > >> I > > > > >> want the autocomplete component, upon creation, to register a > > resource > > > > >> that > > > > >> can be used to serve the autocomplete options. But I want the > > resource > > > > to > > > > >> be stateless and lightweight and the requests to return the > > > autocomplete > > > > >> options should not have to go through the page that contains the > > > > >> autocomplete component. > > > > >> > > > > >> Furthermore, if I have the same autocomplete component twice in a > > > page, > > > > >> the > > > > >> resource should be registered only once and server requests for > both > > > > >> components. > > > > >> > > > > >> Is this possible? Can you provide some guidelines? > > > > >> > > > > >> Thanks > > > > >> Marios > > > > >> > > > > >> > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > > > > > > > >
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
Hmm now I'm a bit confused.
I have a TextTemplate that generates the JQuery autocomplete javascript. I
need to pass it the url to retrieve the search results from. So I do:
HashMap 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
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 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
> > wrote:
> > >
> > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon 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
> >
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
1. Since you use the same ResRef for all autocompleters then you can just
mount it at start time within MyApp#init().
2. Wicket uses ResourceReference#equals() to find the mounted ResRef so you
can do:
- mountResource("/some/path/", new MyResRef())
- CharSequence url = RequestCycle.get().urlFor(new MyResRef(), null);
i.e. two different instances! They are matched by #equals(), not by identity
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Dec 15, 2014 at 10:46 PM, mscoon 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 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
> 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 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 >
> > > wrote:
> > > >
> > > > On Sun, Dec 14, 2014 at 12:08 AM, mscoon 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
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
I am not using the same ResourceReference.
getSearchResultsResourcReference() is overridden in subclasses to return a
different resource reference as needed.
Anyway I think now I understand how to mount the resource from within the
component.
Thanks!
On Mon, Dec 15, 2014 at 10:57 PM, Martin Grigorov
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 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 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
> > 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 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 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
Re: [SOLVED] how to write Form html in separate Form.html file
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
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
