wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Compagner <jcompag...@gmail.com>
Subject disabled components/behaviors fixes of WICKET-3098
Date Tue, 23 Nov 2010 08:42:32 GMT
hi,

i suddenly bump big time into this issue that is fixed.
( https://issues.apache.org/jira/browse/WICKET-3098 )

I get that disabled behaviors can't be used to do respond, because
that behavior shouldnt be rendered in the first place.

But the fix also goes one step deeper... It also blocks if the
component is disabled.. That is a big problem

Because a disabled component is rendered, and all the behaviors are
accepted and rendered also so now suddenly a behavior is rendered
(because the behavior is not disabled)
but a callback will fail...

thats something i dont like...because now i get loads of these in the log:

2010-11-23 09:10:57,934 WARN [http-8080-1]
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget
- component not enabled or visible; ignoring call. Component:
[MarkupContainer [Component id = View]]


and the worse thing is if the behavior blocks like that it fall backs
to a IRedirectListener so it rerenders the whole page and that again
renders the disabled component with its behavior and it starts all
over again and again and again.

the example i have here is that we have a ListView/Repeater with some
paging component and that listview has a behavior attached that does a
call back when it got first rendered to give us back the sizes it has
in the browser
and if we see that it has way more space then it currently shows (if
it now shows 10 rows and it has space for 20) we rerender the ListView
again but then with a bigger visible row count.
that is a behavior of the ListView, but the listview can be in a
disabled state (because a user first have to press a button of "edit"
or something like that) but that resizing i still want to happen if if
the ListView is disabled...

So i like to some how tell that that this behavior should be called.
Now we do this:


test component enablement
test behavior id
test behaviors
test behaviors enabledment.
call behavior

i like to turn that around

test behavior id
test behaviors
test behaviors enabledment.
test component enablement IF behavior doesnt implement IWorkForDisabledComponent
call behavior

So that a developer can be explicit in that check..

We could also introduce a public method on Component:
isEnabledFor(IBehavior) which returns defaults its own enable state.

johan

Mime
View raw message