You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by William Speirs <ws...@apache.org> on 2013/06/26 03:14:46 UTC
DI Through Constructors w/Wicket
I think I know the answer before I ask, but is there any way to do
constructor injection with Wicket? Say I have a web page and an email
service. I need the email service in the web page. Now everyone is
going to say, "Simply use field injection." That will work, but makes
unit testing a real pain because now I have to setup injection for my
unit test (or add additional methods to all of my pages so I can
manually set these field, or additional constructors that set these
fields). I should be able to unit test a class without needing
injection, but instead passing mocks through the constructor.
I feel like this is impossible in Wicket currently because the
DefaultPageFactory is using reflection to create the page instances
instead of the injector (Guice in my case). It would be easy enough to
get the injector and call getInstance() to obtain a page instance. The
problem is when you need to pass in parameters. There is no concept of
parameters for a page other than what is passed via the constructor,
so you cannot call something like setPageParameters because it doesn't
exist. If using Guice, you could create an @Assisted injection, and
have a factory.
Has anyone tried creating this type of IPageFactory -- a
GuicePageFactory? What kind of pitfalls would exist if I attempted
such a thing? Am I being stupid and missing something? Thoughts?
Thanks...
Bill-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: DI Through Constructors w/Wicket
Posted by uwe schaefer <uw...@codesmell.de>.
On 06/29/2013 03:13 PM, William Speirs wrote:
Hi Bill,
> I'm strongly leaning towards the best practice of: If you're having to
> create an injector in your unit test, then you're doing it wrong.
me too. well, normally.
i came to the idea, that UI-Tests are not stricly unit-tests in most of
the cases anyway, so i'd consinder this rule to be in the "depends"-area.
anyway, what you could do is to have constructor-"injection" for your
tests while using the guice-provided at runtime. on the other hand,
you certainly dont want have this in your code everywhere:
new Link<Void>("link",someServiceInstance){...}
as this makes you code hard to change.
if you'd test the Link in isolation that'd be perfect, but given this
link is in a panel, in a panel, in a panel, in a panel of your page,
dependency passing becomes ridiculous...
> Am I totally wrong here? Am I missing something? I'd love people's
> feedback on this!
stomach feeling: i am with you avoiding guice in unit tests. for
wicket-tests it is hard, and pollutes the production code more than it
helps, imho.
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: DI Through Constructors w/Wicket
Posted by William Speirs <ws...@apache.org>.
There are a few of these libraries to make running Guice in JUnit easier,
Onami is another: http://onami.apache.org/test/
However, if you have to add all of this extra stuff to your unit test, is
it really worth it?
Still struggling with all of this... but starting to hone in on my
project's best practices.
Bill-
On Mon, Jul 1, 2013 at 12:44 PM, uwe schaefer <uw...@codesmell.de> wrote:
> On 06/29/2013 03:13 PM, William Speirs wrote:
>
> I'm strongly leaning towards the best practice of: If you're having to
>> create an injector in your unit test, then you're doing it wrong.
>>
>
> maybe it makes it worse in your perspective, but yuo might want to have a
> look at jukito.
>
> https://code.google.com/p/**jukito/ <https://code.google.com/p/jukito/>
>
> at least it makes it easy to combine mockito&guice
>
> cu uwe
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: DI Through Constructors w/Wicket
Posted by uwe schaefer <uw...@codesmell.de>.
On 06/29/2013 03:13 PM, William Speirs wrote:
> I'm strongly leaning towards the best practice of: If you're having to
> create an injector in your unit test, then you're doing it wrong.
maybe it makes it worse in your perspective, but yuo might want to have
a look at jukito.
https://code.google.com/p/jukito/
at least it makes it easy to combine mockito&guice
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: DI Through Constructors w/Wicket
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sat, Jun 29, 2013 at 4:13 PM, William Speirs <ws...@apache.org> wrote:
> I'm just getting to this now... weekend coder.
>
> @MartinGrigorov - this looks exactly like what I want, or parts of it
> at least... I'll certainly check it out. And you're right, I shouldn't
> be so skeptical, you Wicket folks seem to always come through with
> some library when I ask a question :-)
>
> @DanielWatrous - your blog is helpful, except that you instantiate a
> Guice instance in your unit test. I'm still wrestling with what I
> consider "best practices" with respect to Guice/DI and Unit Tests, but
> I'm strongly leaning towards the best practice of: If you're having to
> create an injector in your unit test, then you're doing it wrong.
>
I cannot say that.
WicketTester tests are not exactly unit tests.
I use DI in my tests all the time. I just try to create as minimal
applicationContent (Spring) as possible for a given test. There is no need
to bind all services when just one or two are used in the tests.
For me it is more wrong to the testing to drive the architecture of the
main functionality.
When developing the main functionality you should think how to make it
reusable. The first time when you reuse some functionality is in the tests.
When you have a second use case where you need to use this
component/service/... then you will see how good you made it before. If you
need to refactor it then the tests will protect you from regressions for
your first use case, and you'll have to add tests for the second.
If it is easy to add your second use case and second test then your design
is good enough. If it is not then you should think harder.
>
> Dependencies should come in through the constructor and constructor
> only. In the unit test, mocked instances of those dependencies should
> be passed in through the constructor after you've called new to create
> the object itself. This ensures you're ONLY testing the object, and
> none of its dependencies in that unit test. If you cannot pass your
> dependencies through the constructor, it's most likely because you're
> not letting the framework create the instance for you, and this
> exposes a deficiency in your implementation. This is the problem with
> Wicket, it creates the pages for you (unless you implement your own
> IPageFactory like in the library Martin linked), which forces you to
> use field injection like you did in your blog example.
>
> Draconian "best practice"? Maybe, but when working with a number of
> developers on a project, I find it best to keep strict but simple
> rules; even better when they can be enforced with things like
> Checkstyle.
>
> Am I totally wrong here? Am I missing something? I'd love people's
> feedback on this!
>
> Bill-
>
> On Tue, Jun 25, 2013 at 10:38 PM, Daniel Watrous <dw...@gmail.com>
> wrote:
> > I worked out this process:
> > http://software.danielwatrous.com/wicket-guice-including-unittests/
> >
> > It enables unittests and may help you toward your goal.
> >
> > Daniel
> >
> >
> > On Tue, Jun 25, 2013 at 7:14 PM, William Speirs <ws...@apache.org>
> wrote:
> >
> >> I think I know the answer before I ask, but is there any way to do
> >> constructor injection with Wicket? Say I have a web page and an email
> >> service. I need the email service in the web page. Now everyone is
> >> going to say, "Simply use field injection." That will work, but makes
> >> unit testing a real pain because now I have to setup injection for my
> >> unit test (or add additional methods to all of my pages so I can
> >> manually set these field, or additional constructors that set these
> >> fields). I should be able to unit test a class without needing
> >> injection, but instead passing mocks through the constructor.
> >>
> >> I feel like this is impossible in Wicket currently because the
> >> DefaultPageFactory is using reflection to create the page instances
> >> instead of the injector (Guice in my case). It would be easy enough to
> >> get the injector and call getInstance() to obtain a page instance. The
> >> problem is when you need to pass in parameters. There is no concept of
> >> parameters for a page other than what is passed via the constructor,
> >> so you cannot call something like setPageParameters because it doesn't
> >> exist. If using Guice, you could create an @Assisted injection, and
> >> have a factory.
> >>
> >> Has anyone tried creating this type of IPageFactory -- a
> >> GuicePageFactory? What kind of pitfalls would exist if I attempted
> >> such a thing? Am I being stupid and missing something? Thoughts?
> >>
> >> Thanks...
> >>
> >> Bill-
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: DI Through Constructors w/Wicket
Posted by William Speirs <ws...@apache.org>.
I'm just getting to this now... weekend coder.
@MartinGrigorov - this looks exactly like what I want, or parts of it
at least... I'll certainly check it out. And you're right, I shouldn't
be so skeptical, you Wicket folks seem to always come through with
some library when I ask a question :-)
@DanielWatrous - your blog is helpful, except that you instantiate a
Guice instance in your unit test. I'm still wrestling with what I
consider "best practices" with respect to Guice/DI and Unit Tests, but
I'm strongly leaning towards the best practice of: If you're having to
create an injector in your unit test, then you're doing it wrong.
Dependencies should come in through the constructor and constructor
only. In the unit test, mocked instances of those dependencies should
be passed in through the constructor after you've called new to create
the object itself. This ensures you're ONLY testing the object, and
none of its dependencies in that unit test. If you cannot pass your
dependencies through the constructor, it's most likely because you're
not letting the framework create the instance for you, and this
exposes a deficiency in your implementation. This is the problem with
Wicket, it creates the pages for you (unless you implement your own
IPageFactory like in the library Martin linked), which forces you to
use field injection like you did in your blog example.
Draconian "best practice"? Maybe, but when working with a number of
developers on a project, I find it best to keep strict but simple
rules; even better when they can be enforced with things like
Checkstyle.
Am I totally wrong here? Am I missing something? I'd love people's
feedback on this!
Bill-
On Tue, Jun 25, 2013 at 10:38 PM, Daniel Watrous <dw...@gmail.com> wrote:
> I worked out this process:
> http://software.danielwatrous.com/wicket-guice-including-unittests/
>
> It enables unittests and may help you toward your goal.
>
> Daniel
>
>
> On Tue, Jun 25, 2013 at 7:14 PM, William Speirs <ws...@apache.org> wrote:
>
>> I think I know the answer before I ask, but is there any way to do
>> constructor injection with Wicket? Say I have a web page and an email
>> service. I need the email service in the web page. Now everyone is
>> going to say, "Simply use field injection." That will work, but makes
>> unit testing a real pain because now I have to setup injection for my
>> unit test (or add additional methods to all of my pages so I can
>> manually set these field, or additional constructors that set these
>> fields). I should be able to unit test a class without needing
>> injection, but instead passing mocks through the constructor.
>>
>> I feel like this is impossible in Wicket currently because the
>> DefaultPageFactory is using reflection to create the page instances
>> instead of the injector (Guice in my case). It would be easy enough to
>> get the injector and call getInstance() to obtain a page instance. The
>> problem is when you need to pass in parameters. There is no concept of
>> parameters for a page other than what is passed via the constructor,
>> so you cannot call something like setPageParameters because it doesn't
>> exist. If using Guice, you could create an @Assisted injection, and
>> have a factory.
>>
>> Has anyone tried creating this type of IPageFactory -- a
>> GuicePageFactory? What kind of pitfalls would exist if I attempted
>> such a thing? Am I being stupid and missing something? Thoughts?
>>
>> Thanks...
>>
>> Bill-
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: DI Through Constructors w/Wicket
Posted by Daniel Watrous <dw...@gmail.com>.
I worked out this process:
http://software.danielwatrous.com/wicket-guice-including-unittests/
It enables unittests and may help you toward your goal.
Daniel
On Tue, Jun 25, 2013 at 7:14 PM, William Speirs <ws...@apache.org> wrote:
> I think I know the answer before I ask, but is there any way to do
> constructor injection with Wicket? Say I have a web page and an email
> service. I need the email service in the web page. Now everyone is
> going to say, "Simply use field injection." That will work, but makes
> unit testing a real pain because now I have to setup injection for my
> unit test (or add additional methods to all of my pages so I can
> manually set these field, or additional constructors that set these
> fields). I should be able to unit test a class without needing
> injection, but instead passing mocks through the constructor.
>
> I feel like this is impossible in Wicket currently because the
> DefaultPageFactory is using reflection to create the page instances
> instead of the injector (Guice in my case). It would be easy enough to
> get the injector and call getInstance() to obtain a page instance. The
> problem is when you need to pass in parameters. There is no concept of
> parameters for a page other than what is passed via the constructor,
> so you cannot call something like setPageParameters because it doesn't
> exist. If using Guice, you could create an @Assisted injection, and
> have a factory.
>
> Has anyone tried creating this type of IPageFactory -- a
> GuicePageFactory? What kind of pitfalls would exist if I attempted
> such a thing? Am I being stupid and missing something? Thoughts?
>
> Thanks...
>
> Bill-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Graying Out Disabled Buttons/Controls
Posted by Joachim Schrod <js...@acm.org>.
Timo Schmidt wrote:
> On Wed 26.06.2013 07:30, Richard W. Adams wrote:
>>
>> We have a customer requirement that disabled form buttons be grayed out
>> rather than Wicket's default behavior of making them invisible.
>
> In my experience, disabled form elements are rendered with the disabled
> attribute. They are not invisible.
And the rest of the thread tracks the problem that that's not the
case with your example.
But I'd like to add information about "graying out":
>> Google has a lot of discussion on the topic, but I didn't see
>> a "best practice" solution. Does Wicket provide a way to gray
>> out buttons (or any form control, for that matter)?
>>
>> If we have to override something like onRender(),
>> onBeforeRender(), etc. where would be the best place to do
>> this?
>
> By using CSS yoy may style disabled elements as you like:
>
> button[disabled], input[disabled], select[disabled], textarea[disabled] {
> ...
> }
If you've got CSS predefined and can't change it, there's the
callback method onDisable(ComponentTag) on your form components
that can be overriden to change CSS class of the emittet markup.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jschrod@acm.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Graying Out Disabled Buttons/Controls
Posted by Timo Schmidt <wi...@xomit.de>.
On Wed 26.06.2013 07:30, Richard W. Adams wrote:
>
> We have a customer requirement that disabled form buttons be grayed out
> rather than Wicket's default behavior of making them invisible.
In my experience, disabled form elements are rendered with the disabled
attribute. They are not invisible.
> Google has a lot of discussion on the topic, but I didn't see
> a "best practice" solution. Does Wicket provide a way to gray
> out buttons (or any form control, for that matter)?
>
> If we have to override something like onRender(),
> onBeforeRender(), etc. where would be the best place to do
> this?
By using CSS yoy may style disabled elements as you like:
button[disabled], input[disabled], select[disabled], textarea[disabled] {
...
}
-Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Graying Out Disabled Buttons/Controls
Posted by "Richard W. Adams" <RW...@UP.COM>.
I have egg on my face. After delving into this more deeply, I discovered
our corporate framework "helpfully" removes disabled buttons before they
get to the browser. Don't agree with the approach, but it is what it is.
(slinks away with tail between legs...)
From: Paul Bors <pa...@bors.ws>
To: <us...@wicket.apache.org>
Date: 06/26/2013 11:18 AM
Subject: RE: Graying Out Disabled Buttons/Controls
Create a quick-start attach it to your e-mail and we'll look it over.
Feel free to use drop box or some other file sharing server.
You're doing something wrong...
~ Thank you,
Paul Bors
-----Original Message-----
From: Richard W. Adams [mailto:RWADAMS1@UP.COM]
Sent: Wednesday, June 26, 2013 11:41 AM
To: users@wicket.apache.org
Subject: RE: Graying Out Disabled Buttons/Controls
Wow. Now it gets even stranger. I modified the code as follows:
public DisabledButtonPage() {
final Form<?> form = new Form<Object>("myForm");
add(form);
final Button enabledButton = new Button("enabled-button");
boolean visible = enabledButton.isVisibleInHierarchy();
System.out.printf("Enabled button visible? %s%n", visible ? "Yes"
: "No");
System.out.printf("Enabled button's ID: %s%n",
enabledButton.getMarkupId());
final Button disabledButton = createDisabledButton();
visible = disabledButton.isVisibleInHierarchy();
System.out.printf("Disabled button visible? %s%n", visible ? "Yes"
: "No");
System.out.printf("Disabled button's ID: %s%n",
disabledButton.getMarkupId());
form.add(enabledButton);
form.add(disabledButton);
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button") ;
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
Strangely, the output says:
Enabled button visible? Yes
Enabled button's ID: id5
Disabled button visible? Yes
Disabled button's ID: id6
But the generated HTML (snippet below) does NOT show the disabled button;
it
SHOULD be right after the enabled button
<form id="idb" method="post" action="
?wicket:interface=:1:myForm::IFormSubmitListener::"><div
style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflo
w:hidden"><input
type="hidden" name="idb_hf_0" id="idb_hf_0" /></div> <button
value="Enabled
Button" name="enabled-button" id="id5"
xmlns:wicket="http://wicket.apache.org">Enabled Button</button>
</form>
From: Paul Bors <pa...@bors.ws>
To: <us...@wicket.apache.org>
Date: 06/26/2013 09:48 AM
Subject: RE: Graying Out Disabled Buttons/Controls
Button -> FormComponent -> WebMarkupContainer -> WebMarkupContainer ->
MarkupContainer -> Component
Inside Component:
/**
* Gets whether this component and any children are
visible.
* <p>
* WARNING: this method can be called multiple times
during
a request. If you override this
* method, it is a good idea to keep it cheap in terms of
processing. Alternatively, you can
* call {@link #setVisible(boolean)}.
* <p>
*
* @return True if component and any children are visible
*/
public boolean isVisible()
{
return getFlag(FLAG_VISIBLE);
}
So calling isVisible() on any component would only report the current
state
for the visible flag but not that of the parent.
Try calling isVisibleInHierarchy() instead:
/**
* Checks if the component itself and all its parents are
visible.
*
* @return true if the component and all its parents are
visible.
*/
public final boolean isVisibleInHierarchy()
{
Component parent = getParent();
if (parent != null &&
!parent.isVisibleInHierarchy())
{
return false;
}
else
{
return
determineVisibility();
}
}
Second, why would you have a button attached to a page directly? Isn't
that
invalid HTML?
I through all form components should be inside a <form> (even w/o a
wicket:id) otherwise the browser might choke on it...
~ Thank you,
Paul Bors
-----Original Message-----
From: Richard W. Adams [mailto:RWADAMS1@UP.COM]
Sent: Wednesday, June 26, 2013 9:42 AM
To: users@wicket.apache.org
Subject: Re: Graying Out Disabled Buttons/Controls
I believe the parent component (the page itself) is visible. My test page
is
very simple, with only two buttons, one enabled & the other disabled; both
buttons are children of the page itself. However, only the enabled button
appears in the generated HTML. I've tried changing the order of the
various
method calls in createDisabledButton(), tried overriding
isVisible() with return true, etc. No matter what I do, though, the the
generated HTML does not include the disabled button.
I'm out of ideas. Does this work in a later version of Wicket (after
1.14.17)?
_________________________________
The source HTML (extends a generic page type, whose header/footer display
correctly):
<wicket:extend xmlns:wicket="http://wicket.apache.org">
<p>This page demonstrates the inability to make disabled buttons visible,
but grayed out.</p>
<button value="Enabled Button" wicket:id="enabled-button"></button>
<button value="Disabled Button" wicket:id="disabled-button"></button>
</wicket:extend>
_________________________________
The source code:
_________________________________
public DisabledButtonPage() {
add(new Button("enabled-button"));
add(createDisabledButton());
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button");
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
From: Paul Bors <pa...@bors.ws>
To: users@wicket.apache.org
Date: 06/26/2013 08:30 AM
Subject: Re: Graying Out Disabled Buttons/Controls
You need to make sure all of your component parents are also visible.
Remeber that wicket uses a component tree (you can see it in your
DebugToolbar if you add it to your pages).
The inspector looks something like this:
http://www.wicket-library.com/wicket-examples-6.0.x/spring/wicket/bookmarkab
le/org.apache.wicket.devutils.inspector.InspectorPage;jsessionid=76EE1D9ED70
B7660542E78B4C1333951?0&pageId=0
On Wed, Jun 26, 2013 at 9:16 AM, Richard W. Adams <RW...@up.com> wrote:
> We tried that (code below), but the button does not appear in the
> generated HTML. We're using Wicket 1.4.17. Do later versions of Wicket
> render a grayed out (vice invisible) button?
>
> private Button createDisabledButton() {
>
> final Button button = new Button("disabled-button");
> button.setEnabled(false);
> button.setVisible(true);
> return button;
> }
>
>
>
>
> From: Thomas Matthijs <li...@selckin.be>
> To: users@wicket.apache.org
> Date: 06/26/2013 07:45 AM
> Subject: Re: Graying Out Disabled Buttons/Controls
>
>
>
> On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com>
wrote:
>
> > We have a customer requirement that disabled form buttons be grayed
out
> > rather than Wicket's default behavior of making them invisible.
> > Google
> has
> > a lot of discussion on the topic, but I didn't see a "best practice"
> > solution. Does Wicket provide a way to gray out buttons (or any form
> > control, for that matter)?
> >
>
>
> Use setEnabled(false) instead of setVisible()
>
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
recipient.
> Any use, review, disclosure, copying, distribution or reliance by
others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are
> not
the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
**
This email and any attachments may contain information that is
confidential
and/or privileged for the sole use of the intended recipient. Any use,
review, disclosure, copying, distribution or reliance by others, and any
forwarding of this email or its contents, without the express permission
of
the sender is strictly prohibited by law. If you are not the intended
recipient, please contact the sender immediately, delete the e-mail and
destroy all copies.
**
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
**
This email and any attachments may contain information that is
confidential
and/or privileged for the sole use of the intended recipient. Any use,
review, disclosure, copying, distribution or reliance by others, and any
forwarding of this email or its contents, without the express permission
of
the sender is strictly prohibited by law. If you are not the intended
recipient, please contact the sender immediately, delete the e-mail and
destroy all copies.
**
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
RE: Graying Out Disabled Buttons/Controls
Posted by Paul Bors <pa...@bors.ws>.
Create a quick-start attach it to your e-mail and we'll look it over.
Feel free to use drop box or some other file sharing server.
You're doing something wrong...
~ Thank you,
Paul Bors
-----Original Message-----
From: Richard W. Adams [mailto:RWADAMS1@UP.COM]
Sent: Wednesday, June 26, 2013 11:41 AM
To: users@wicket.apache.org
Subject: RE: Graying Out Disabled Buttons/Controls
Wow. Now it gets even stranger. I modified the code as follows:
public DisabledButtonPage() {
final Form<?> form = new Form<Object>("myForm");
add(form);
final Button enabledButton = new Button("enabled-button");
boolean visible = enabledButton.isVisibleInHierarchy();
System.out.printf("Enabled button visible? %s%n", visible ? "Yes"
: "No");
System.out.printf("Enabled button's ID: %s%n",
enabledButton.getMarkupId());
final Button disabledButton = createDisabledButton();
visible = disabledButton.isVisibleInHierarchy();
System.out.printf("Disabled button visible? %s%n", visible ? "Yes"
: "No");
System.out.printf("Disabled button's ID: %s%n",
disabledButton.getMarkupId());
form.add(enabledButton);
form.add(disabledButton);
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button") ;
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
Strangely, the output says:
Enabled button visible? Yes
Enabled button's ID: id5
Disabled button visible? Yes
Disabled button's ID: id6
But the generated HTML (snippet below) does NOT show the disabled button; it
SHOULD be right after the enabled button
<form id="idb" method="post" action="
?wicket:interface=:1:myForm::IFormSubmitListener::"><div
style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflo
w:hidden"><input
type="hidden" name="idb_hf_0" id="idb_hf_0" /></div> <button value="Enabled
Button" name="enabled-button" id="id5"
xmlns:wicket="http://wicket.apache.org">Enabled Button</button>
</form>
From: Paul Bors <pa...@bors.ws>
To: <us...@wicket.apache.org>
Date: 06/26/2013 09:48 AM
Subject: RE: Graying Out Disabled Buttons/Controls
Button -> FormComponent -> WebMarkupContainer -> WebMarkupContainer ->
MarkupContainer -> Component
Inside Component:
/**
* Gets whether this component and any children are
visible.
* <p>
* WARNING: this method can be called multiple times during
a request. If you override this
* method, it is a good idea to keep it cheap in terms of
processing. Alternatively, you can
* call {@link #setVisible(boolean)}.
* <p>
*
* @return True if component and any children are visible
*/
public boolean isVisible()
{
return getFlag(FLAG_VISIBLE);
}
So calling isVisible() on any component would only report the current state
for the visible flag but not that of the parent.
Try calling isVisibleInHierarchy() instead:
/**
* Checks if the component itself and all its parents are
visible.
*
* @return true if the component and all its parents are
visible.
*/
public final boolean isVisibleInHierarchy()
{
Component parent = getParent();
if (parent != null &&
!parent.isVisibleInHierarchy())
{
return false;
}
else
{
return
determineVisibility();
}
}
Second, why would you have a button attached to a page directly? Isn't that
invalid HTML?
I through all form components should be inside a <form> (even w/o a
wicket:id) otherwise the browser might choke on it...
~ Thank you,
Paul Bors
-----Original Message-----
From: Richard W. Adams [mailto:RWADAMS1@UP.COM]
Sent: Wednesday, June 26, 2013 9:42 AM
To: users@wicket.apache.org
Subject: Re: Graying Out Disabled Buttons/Controls
I believe the parent component (the page itself) is visible. My test page is
very simple, with only two buttons, one enabled & the other disabled; both
buttons are children of the page itself. However, only the enabled button
appears in the generated HTML. I've tried changing the order of the various
method calls in createDisabledButton(), tried overriding
isVisible() with return true, etc. No matter what I do, though, the the
generated HTML does not include the disabled button.
I'm out of ideas. Does this work in a later version of Wicket (after
1.14.17)?
_________________________________
The source HTML (extends a generic page type, whose header/footer display
correctly):
<wicket:extend xmlns:wicket="http://wicket.apache.org">
<p>This page demonstrates the inability to make disabled buttons visible,
but grayed out.</p>
<button value="Enabled Button" wicket:id="enabled-button"></button>
<button value="Disabled Button" wicket:id="disabled-button"></button>
</wicket:extend>
_________________________________
The source code:
_________________________________
public DisabledButtonPage() {
add(new Button("enabled-button"));
add(createDisabledButton());
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button");
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
From: Paul Bors <pa...@bors.ws>
To: users@wicket.apache.org
Date: 06/26/2013 08:30 AM
Subject: Re: Graying Out Disabled Buttons/Controls
You need to make sure all of your component parents are also visible.
Remeber that wicket uses a component tree (you can see it in your
DebugToolbar if you add it to your pages).
The inspector looks something like this:
http://www.wicket-library.com/wicket-examples-6.0.x/spring/wicket/bookmarkab
le/org.apache.wicket.devutils.inspector.InspectorPage;jsessionid=76EE1D9ED70
B7660542E78B4C1333951?0&pageId=0
On Wed, Jun 26, 2013 at 9:16 AM, Richard W. Adams <RW...@up.com> wrote:
> We tried that (code below), but the button does not appear in the
> generated HTML. We're using Wicket 1.4.17. Do later versions of Wicket
> render a grayed out (vice invisible) button?
>
> private Button createDisabledButton() {
>
> final Button button = new Button("disabled-button");
> button.setEnabled(false);
> button.setVisible(true);
> return button;
> }
>
>
>
>
> From: Thomas Matthijs <li...@selckin.be>
> To: users@wicket.apache.org
> Date: 06/26/2013 07:45 AM
> Subject: Re: Graying Out Disabled Buttons/Controls
>
>
>
> On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com>
wrote:
>
> > We have a customer requirement that disabled form buttons be grayed
out
> > rather than Wicket's default behavior of making them invisible.
> > Google
> has
> > a lot of discussion on the topic, but I didn't see a "best practice"
> > solution. Does Wicket provide a way to gray out buttons (or any form
> > control, for that matter)?
> >
>
>
> Use setEnabled(false) instead of setVisible()
>
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
recipient.
> Any use, review, disclosure, copying, distribution or reliance by
others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are
> not
the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
**
This email and any attachments may contain information that is confidential
and/or privileged for the sole use of the intended recipient. Any use,
review, disclosure, copying, distribution or reliance by others, and any
forwarding of this email or its contents, without the express permission of
the sender is strictly prohibited by law. If you are not the intended
recipient, please contact the sender immediately, delete the e-mail and
destroy all copies.
**
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
**
This email and any attachments may contain information that is confidential
and/or privileged for the sole use of the intended recipient. Any use,
review, disclosure, copying, distribution or reliance by others, and any
forwarding of this email or its contents, without the express permission of
the sender is strictly prohibited by law. If you are not the intended
recipient, please contact the sender immediately, delete the e-mail and
destroy all copies.
**
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Graying Out Disabled Buttons/Controls
Posted by "Richard W. Adams" <RW...@UP.COM>.
Wow. Now it gets even stranger. I modified the code as follows:
public DisabledButtonPage() {
final Form<?> form = new Form<Object>("myForm");
add(form);
final Button enabledButton = new Button("enabled-button");
boolean visible = enabledButton.isVisibleInHierarchy();
System.out.printf("Enabled button visible? %s%n", visible ? "Yes"
: "No");
System.out.printf("Enabled button's ID: %s%n",
enabledButton.getMarkupId());
final Button disabledButton = createDisabledButton();
visible = disabledButton.isVisibleInHierarchy();
System.out.printf("Disabled button visible? %s%n", visible ? "Yes"
: "No");
System.out.printf("Disabled button's ID: %s%n",
disabledButton.getMarkupId());
form.add(enabledButton);
form.add(disabledButton);
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button") ;
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
Strangely, the output says:
Enabled button visible? Yes
Enabled button's ID: id5
Disabled button visible? Yes
Disabled button's ID: id6
But the generated HTML (snippet below) does NOT show the disabled button;
it SHOULD be right after the enabled button
<form id="idb" method="post" action="
?wicket:interface=:1:myForm::IFormSubmitListener::"><div
style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden"><input
type="hidden" name="idb_hf_0" id="idb_hf_0" /></div>
<button value="Enabled Button" name="enabled-button" id="id5"
xmlns:wicket="http://wicket.apache.org">Enabled Button</button>
</form>
From: Paul Bors <pa...@bors.ws>
To: <us...@wicket.apache.org>
Date: 06/26/2013 09:48 AM
Subject: RE: Graying Out Disabled Buttons/Controls
Button -> FormComponent -> WebMarkupContainer -> WebMarkupContainer ->
MarkupContainer -> Component
Inside Component:
/**
* Gets whether this component and any children are
visible.
* <p>
* WARNING: this method can be called multiple times
during a
request. If you override this
* method, it is a good idea to keep it cheap in terms of
processing. Alternatively, you can
* call {@link #setVisible(boolean)}.
* <p>
*
* @return True if component and any children are visible
*/
public boolean isVisible()
{
return getFlag(FLAG_VISIBLE);
}
So calling isVisible() on any component would only report the current
state
for the visible flag but not that of the parent.
Try calling isVisibleInHierarchy() instead:
/**
* Checks if the component itself and all its parents are
visible.
*
* @return true if the component and all its parents are
visible.
*/
public final boolean isVisibleInHierarchy()
{
Component parent = getParent();
if (parent != null &&
!parent.isVisibleInHierarchy())
{
return false;
}
else
{
return
determineVisibility();
}
}
Second, why would you have a button attached to a page directly? Isn't
that
invalid HTML?
I through all form components should be inside a <form> (even w/o a
wicket:id) otherwise the browser might choke on it...
~ Thank you,
Paul Bors
-----Original Message-----
From: Richard W. Adams [mailto:RWADAMS1@UP.COM]
Sent: Wednesday, June 26, 2013 9:42 AM
To: users@wicket.apache.org
Subject: Re: Graying Out Disabled Buttons/Controls
I believe the parent component (the page itself) is visible. My test page
is
very simple, with only two buttons, one enabled & the other disabled; both
buttons are children of the page itself. However, only the enabled button
appears in the generated HTML. I've tried changing the order of the
various
method calls in createDisabledButton(), tried overriding
isVisible() with return true, etc. No matter what I do, though, the the
generated HTML does not include the disabled button.
I'm out of ideas. Does this work in a later version of Wicket (after
1.14.17)?
_________________________________
The source HTML (extends a generic page type, whose header/footer display
correctly):
<wicket:extend xmlns:wicket="http://wicket.apache.org">
<p>This page demonstrates the inability to make disabled buttons visible,
but grayed out.</p>
<button value="Enabled Button" wicket:id="enabled-button"></button>
<button value="Disabled Button" wicket:id="disabled-button"></button>
</wicket:extend>
_________________________________
The source code:
_________________________________
public DisabledButtonPage() {
add(new Button("enabled-button"));
add(createDisabledButton());
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button");
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
From: Paul Bors <pa...@bors.ws>
To: users@wicket.apache.org
Date: 06/26/2013 08:30 AM
Subject: Re: Graying Out Disabled Buttons/Controls
You need to make sure all of your component parents are also visible.
Remeber that wicket uses a component tree (you can see it in your
DebugToolbar if you add it to your pages).
The inspector looks something like this:
http://www.wicket-library.com/wicket-examples-6.0.x/spring/wicket/bookmarkab
le/org.apache.wicket.devutils.inspector.InspectorPage;jsessionid=76EE1D9ED70
B7660542E78B4C1333951?0&pageId=0
On Wed, Jun 26, 2013 at 9:16 AM, Richard W. Adams <RW...@up.com> wrote:
> We tried that (code below), but the button does not appear in the
> generated HTML. We're using Wicket 1.4.17. Do later versions of Wicket
> render a grayed out (vice invisible) button?
>
> private Button createDisabledButton() {
>
> final Button button = new Button("disabled-button");
> button.setEnabled(false);
> button.setVisible(true);
> return button;
> }
>
>
>
>
> From: Thomas Matthijs <li...@selckin.be>
> To: users@wicket.apache.org
> Date: 06/26/2013 07:45 AM
> Subject: Re: Graying Out Disabled Buttons/Controls
>
>
>
> On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com>
wrote:
>
> > We have a customer requirement that disabled form buttons be grayed
out
> > rather than Wicket's default behavior of making them invisible.
> > Google
> has
> > a lot of discussion on the topic, but I didn't see a "best practice"
> > solution. Does Wicket provide a way to gray out buttons (or any form
> > control, for that matter)?
> >
>
>
> Use setEnabled(false) instead of setVisible()
>
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
recipient.
> Any use, review, disclosure, copying, distribution or reliance by
others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are
> not
the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
**
This email and any attachments may contain information that is
confidential
and/or privileged for the sole use of the intended recipient. Any use,
review, disclosure, copying, distribution or reliance by others, and any
forwarding of this email or its contents, without the express permission
of
the sender is strictly prohibited by law. If you are not the intended
recipient, please contact the sender immediately, delete the e-mail and
destroy all copies.
**
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
RE: Graying Out Disabled Buttons/Controls
Posted by Paul Bors <pa...@bors.ws>.
Button -> FormComponent -> WebMarkupContainer -> WebMarkupContainer ->
MarkupContainer -> Component
Inside Component:
/**
* Gets whether this component and any children are visible.
* <p>
* WARNING: this method can be called multiple times during a
request. If you override this
* method, it is a good idea to keep it cheap in terms of
processing. Alternatively, you can
* call {@link #setVisible(boolean)}.
* <p>
*
* @return True if component and any children are visible
*/
public boolean isVisible()
{
return getFlag(FLAG_VISIBLE);
}
So calling isVisible() on any component would only report the current state
for the visible flag but not that of the parent.
Try calling isVisibleInHierarchy() instead:
/**
* Checks if the component itself and all its parents are visible.
*
* @return true if the component and all its parents are visible.
*/
public final boolean isVisibleInHierarchy()
{
Component parent = getParent();
if (parent != null && !parent.isVisibleInHierarchy())
{
return false;
}
else
{
return determineVisibility();
}
}
Second, why would you have a button attached to a page directly? Isn't that
invalid HTML?
I through all form components should be inside a <form> (even w/o a
wicket:id) otherwise the browser might choke on it...
~ Thank you,
Paul Bors
-----Original Message-----
From: Richard W. Adams [mailto:RWADAMS1@UP.COM]
Sent: Wednesday, June 26, 2013 9:42 AM
To: users@wicket.apache.org
Subject: Re: Graying Out Disabled Buttons/Controls
I believe the parent component (the page itself) is visible. My test page is
very simple, with only two buttons, one enabled & the other disabled; both
buttons are children of the page itself. However, only the enabled button
appears in the generated HTML. I've tried changing the order of the various
method calls in createDisabledButton(), tried overriding
isVisible() with return true, etc. No matter what I do, though, the the
generated HTML does not include the disabled button.
I'm out of ideas. Does this work in a later version of Wicket (after
1.14.17)?
_________________________________
The source HTML (extends a generic page type, whose header/footer display
correctly):
<wicket:extend xmlns:wicket="http://wicket.apache.org">
<p>This page demonstrates the inability to make disabled buttons visible,
but grayed out.</p>
<button value="Enabled Button" wicket:id="enabled-button"></button>
<button value="Disabled Button" wicket:id="disabled-button"></button>
</wicket:extend>
_________________________________
The source code:
_________________________________
public DisabledButtonPage() {
add(new Button("enabled-button"));
add(createDisabledButton());
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button");
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
From: Paul Bors <pa...@bors.ws>
To: users@wicket.apache.org
Date: 06/26/2013 08:30 AM
Subject: Re: Graying Out Disabled Buttons/Controls
You need to make sure all of your component parents are also visible.
Remeber that wicket uses a component tree (you can see it in your
DebugToolbar if you add it to your pages).
The inspector looks something like this:
http://www.wicket-library.com/wicket-examples-6.0.x/spring/wicket/bookmarkab
le/org.apache.wicket.devutils.inspector.InspectorPage;jsessionid=76EE1D9ED70
B7660542E78B4C1333951?0&pageId=0
On Wed, Jun 26, 2013 at 9:16 AM, Richard W. Adams <RW...@up.com> wrote:
> We tried that (code below), but the button does not appear in the
> generated HTML. We're using Wicket 1.4.17. Do later versions of Wicket
> render a grayed out (vice invisible) button?
>
> private Button createDisabledButton() {
>
> final Button button = new Button("disabled-button");
> button.setEnabled(false);
> button.setVisible(true);
> return button;
> }
>
>
>
>
> From: Thomas Matthijs <li...@selckin.be>
> To: users@wicket.apache.org
> Date: 06/26/2013 07:45 AM
> Subject: Re: Graying Out Disabled Buttons/Controls
>
>
>
> On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com>
wrote:
>
> > We have a customer requirement that disabled form buttons be grayed
out
> > rather than Wicket's default behavior of making them invisible.
> > Google
> has
> > a lot of discussion on the topic, but I didn't see a "best practice"
> > solution. Does Wicket provide a way to gray out buttons (or any form
> > control, for that matter)?
> >
>
>
> Use setEnabled(false) instead of setVisible()
>
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
recipient.
> Any use, review, disclosure, copying, distribution or reliance by
others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are
> not
the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
**
This email and any attachments may contain information that is confidential
and/or privileged for the sole use of the intended recipient. Any use,
review, disclosure, copying, distribution or reliance by others, and any
forwarding of this email or its contents, without the express permission of
the sender is strictly prohibited by law. If you are not the intended
recipient, please contact the sender immediately, delete the e-mail and
destroy all copies.
**
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Graying Out Disabled Buttons/Controls
Posted by "Richard W. Adams" <RW...@UP.COM>.
I believe the parent component (the page itself) is visible. My test page
is very simple, with only two buttons, one enabled & the other disabled;
both buttons are children of the page itself. However, only the enabled
button appears in the generated HTML. I've tried changing the order of the
various method calls in createDisabledButton(), tried overriding
isVisible() with return true, etc. No matter what I do, though, the the
generated HTML does not include the disabled button.
I'm out of ideas. Does this work in a later version of Wicket (after
1.14.17)?
_________________________________
The source HTML (extends a generic page type, whose header/footer display
correctly):
<wicket:extend xmlns:wicket="http://wicket.apache.org">
<p>This page demonstrates the inability to make disabled buttons visible,
but grayed out.</p>
<button value="Enabled Button" wicket:id="enabled-button"></button>
<button value="Disabled Button" wicket:id="disabled-button"></button>
</wicket:extend>
_________________________________
The source code:
_________________________________
public DisabledButtonPage() {
add(new Button("enabled-button"));
add(createDisabledButton());
}
private Button createDisabledButton() {
final Button button = new Button("disabled-button");
button.setVisibilityAllowed(true);
button.setVisible(true);
button.setEnabled(false);
return button;
}
From: Paul Bors <pa...@bors.ws>
To: users@wicket.apache.org
Date: 06/26/2013 08:30 AM
Subject: Re: Graying Out Disabled Buttons/Controls
You need to make sure all of your component parents are also visible.
Remeber that wicket uses a component tree (you can see it in your
DebugToolbar if you add it to your pages).
The inspector looks something like this:
http://www.wicket-library.com/wicket-examples-6.0.x/spring/wicket/bookmarkable/org.apache.wicket.devutils.inspector.InspectorPage;jsessionid=76EE1D9ED70B7660542E78B4C1333951?0&pageId=0
On Wed, Jun 26, 2013 at 9:16 AM, Richard W. Adams <RW...@up.com> wrote:
> We tried that (code below), but the button does not appear in the
> generated HTML. We're using Wicket 1.4.17. Do later versions of Wicket
> render a grayed out (vice invisible) button?
>
> private Button createDisabledButton() {
>
> final Button button = new Button("disabled-button");
> button.setEnabled(false);
> button.setVisible(true);
> return button;
> }
>
>
>
>
> From: Thomas Matthijs <li...@selckin.be>
> To: users@wicket.apache.org
> Date: 06/26/2013 07:45 AM
> Subject: Re: Graying Out Disabled Buttons/Controls
>
>
>
> On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com>
wrote:
>
> > We have a customer requirement that disabled form buttons be grayed
out
> > rather than Wicket's default behavior of making them invisible. Google
> has
> > a lot of discussion on the topic, but I didn't see a "best practice"
> > solution. Does Wicket provide a way to gray out buttons (or any form
> > control, for that matter)?
> >
>
>
> Use setEnabled(false) instead of setVisible()
>
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
recipient.
> Any use, review, disclosure, copying, distribution or reliance by
others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are not
the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
Re: Graying Out Disabled Buttons/Controls
Posted by Paul Bors <pa...@bors.ws>.
You need to make sure all of your component parents are also visible.
Remeber that wicket uses a component tree (you can see it in your
DebugToolbar if you add it to your pages).
The inspector looks something like this:
http://www.wicket-library.com/wicket-examples-6.0.x/spring/wicket/bookmarkable/org.apache.wicket.devutils.inspector.InspectorPage;jsessionid=76EE1D9ED70B7660542E78B4C1333951?0&pageId=0
On Wed, Jun 26, 2013 at 9:16 AM, Richard W. Adams <RW...@up.com> wrote:
> We tried that (code below), but the button does not appear in the
> generated HTML. We're using Wicket 1.4.17. Do later versions of Wicket
> render a grayed out (vice invisible) button?
>
> private Button createDisabledButton() {
>
> final Button button = new Button("disabled-button");
> button.setEnabled(false);
> button.setVisible(true);
> return button;
> }
>
>
>
>
> From: Thomas Matthijs <li...@selckin.be>
> To: users@wicket.apache.org
> Date: 06/26/2013 07:45 AM
> Subject: Re: Graying Out Disabled Buttons/Controls
>
>
>
> On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com> wrote:
>
> > We have a customer requirement that disabled form buttons be grayed out
> > rather than Wicket's default behavior of making them invisible. Google
> has
> > a lot of discussion on the topic, but I didn't see a "best practice"
> > solution. Does Wicket provide a way to gray out buttons (or any form
> > control, for that matter)?
> >
>
>
> Use setEnabled(false) instead of setVisible()
>
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended recipient.
> Any use, review, disclosure, copying, distribution or reliance by others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are not the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
Re: Graying Out Disabled Buttons/Controls
Posted by "Richard W. Adams" <RW...@UP.COM>.
We tried that (code below), but the button does not appear in the
generated HTML. We're using Wicket 1.4.17. Do later versions of Wicket
render a grayed out (vice invisible) button?
private Button createDisabledButton() {
final Button button = new Button("disabled-button");
button.setEnabled(false);
button.setVisible(true);
return button;
}
From: Thomas Matthijs <li...@selckin.be>
To: users@wicket.apache.org
Date: 06/26/2013 07:45 AM
Subject: Re: Graying Out Disabled Buttons/Controls
On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com> wrote:
> We have a customer requirement that disabled form buttons be grayed out
> rather than Wicket's default behavior of making them invisible. Google
has
> a lot of discussion on the topic, but I didn't see a "best practice"
> solution. Does Wicket provide a way to gray out buttons (or any form
> control, for that matter)?
>
Use setEnabled(false) instead of setVisible()
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
Re: Graying Out Disabled Buttons/Controls
Posted by Thomas Matthijs <li...@selckin.be>.
On Wed, Jun 26, 2013 at 2:30 PM, Richard W. Adams <RW...@up.com> wrote:
> We have a customer requirement that disabled form buttons be grayed out
> rather than Wicket's default behavior of making them invisible. Google has
> a lot of discussion on the topic, but I didn't see a "best practice"
> solution. Does Wicket provide a way to gray out buttons (or any form
> control, for that matter)?
>
Use setEnabled(false) instead of setVisible()
Graying Out Disabled Buttons/Controls
Posted by "Richard W. Adams" <RW...@UP.COM>.
We have a customer requirement that disabled form buttons be grayed out
rather than Wicket's default behavior of making them invisible. Google has
a lot of discussion on the topic, but I didn't see a "best practice"
solution. Does Wicket provide a way to gray out buttons (or any form
control, for that matter)?
If we have to override something like onRender(), onBeforeRender(), etc.
where would be the best place to do this?
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
Re: DI Through Constructors w/Wicket
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Wed, Jun 26, 2013 at 4:14 AM, William Speirs <ws...@apache.org> wrote:
> I think I know the answer before I ask, but is there any way to do
> constructor injection with Wicket? Say I have a web page and an email
>
Don't be sceptic ;-)
Here is some code that has been used with Wicket 1.4 -
https://github.com/jolira/wicket-guicier.
You can use it or at least be inspired by it.
> service. I need the email service in the web page. Now everyone is
> going to say, "Simply use field injection." That will work, but makes
> unit testing a real pain because now I have to setup injection for my
> unit test (or add additional methods to all of my pages so I can
> manually set these field, or additional constructors that set these
> fields). I should be able to unit test a class without needing
> injection, but instead passing mocks through the constructor.
>
> I feel like this is impossible in Wicket currently because the
> DefaultPageFactory is using reflection to create the page instances
>
The first thing I'd try is to use custom IPageFactory.
> instead of the injector (Guice in my case). It would be easy enough to
> get the injector and call getInstance() to obtain a page instance. The
> problem is when you need to pass in parameters. There is no concept of
> parameters for a page other than what is passed via the constructor,
> so you cannot call something like setPageParameters because it doesn't
> exist. If using Guice, you could create an @Assisted injection, and
> have a factory.
>
> Has anyone tried creating this type of IPageFactory -- a
> GuicePageFactory? What kind of pitfalls would exist if I attempted
> such a thing? Am I being stupid and missing something? Thoughts?
>
> Thanks...
>
> Bill-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>