anymore which
means that every component, not only form components, need to use that
special method. I'm currently trying to find a way to avoid changing all
the
hundreds of add() calls in my project...
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Forms-in-a-base
trying to find a way to avoid changing all the
hundreds of add() calls in my project...
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Forms-in-a-base-class-tp1891692p2304644.html
Sent from the Wicket - User mailing list archive at Nabble.com
If you want to use inheritance:
Put your base form in a panel with the associated markup for the base
fields (making sure there is a wicket:child / tag in the correct
place). Then just extend this panel, adding the required child form
components and supplying the appropriate markup extension
Using the getForm().add(...) solves my problems and I have been able to get
really nice small and clean sub-classes that just have a few components
working in them.
The Feedback panel, save and cancel buttons along with the form and some
default formatting are supplied in the parent class, then
and description wicket
fields on each page that has that form, or is there a way to generalize it?
or should i just use the method defined in the thread above?
--
View this message in context:
http://old.nabble.com/Forms-in-a-base-class-tp27981164p28153812.html
Sent from the Wicket - User mailing list
I concur: the form fields need to be inside the form tag, otherwise
the browser will not send them to the server.
Martijn
On Mon, Mar 22, 2010 at 6:00 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
dont think that will work. it will work for rendering, but for
processing components it wont
Martijn, they would still be in the form tag when rendered - see the
placement of the wicket:child tag.
However, I think Igor is right - the transparent resolver may not work on a
form. I haven't used it for that, so I couldn't tell you.
What it really boils down to is that you need the
Hi all,
Before I go to far trying to prove I have a bug, I thought i'd crowd
source an answer.
We have a lot of Edit pages that have a lot of simmilar structure,
and what I wanted to do is create a BaseEditPage that contains the
form, the save/cancel buttons, some layout stuff and a
you need to be adding the components to the form. you're currently adding
them to the page itself. the component hierarchy is thus broken. on your
child page, either do getForm().add(foo) [you'll need to expose a getForm
method that returns the form from the parent page] or else on your parent
@wicket.apache.org
Subject: Re: Forms in a base class
you need to be adding the components to the form. you're currently adding
them to the page itself. the component hierarchy is thus broken. on your
child page, either do getForm().add(foo) [you'll need to expose a getForm
method that returns the form
Excellent,
My simple test now seems to work if I do a getForm().
Although I really like the thought of setTransparentResolver(), but as
with Josh, I can't find it in 1.4.7..
I also have this problem with a Border object, I'll have to look into
seeing if I can get around the same problem by
Sorry, override isTransparentResolver. The set method is only on Border.
--
Jeremy Thomerson
http://www.wickettraining.com
On Sun, Mar 21, 2010 at 8:00 PM, Steve Mactaggart
steve.mactagg...@gmail.com wrote:
Excellent,
My simple test now seems to work if I do a getForm().
Although I
dont think that will work. it will work for rendering, but for
processing components it wont work because they really need to be
descendants of the form.
-igor
On Sun, Mar 21, 2010 at 7:08 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
Sorry, override isTransparentResolver. The set
13 matches
Mail list logo