Thanks - that's very neat. It also made me spend some time looking at
that area of the framework, which will be useful in the future.
With that strategey and annotation, handling nullable data is a
non-issue when a component uses a model for all its data requirements.
There are obviously
Thanks for the reply - I think I'm perhaps trying to bend the framework rather
than work with it.
I suppose I'm really wondering about the following kind of thing, and whether
it's worth trying to build similar re-usable components:
public class NullableLabel extends Label {
private boolean
Absolutely. It's one of wickets many strong points.
Regards,
Antony Stubbs
website: sharca.com
On 1/08/2009, at 1:39 AM, Iain Reddick iain.redd...@beatsystems.com
wrote:
Thanks for the reply - I think I'm perhaps trying to bend the
framework rather than work with it.
I suppose I'm
instead of creating a lot of subclasses you can use the
iauthorizationstrategy to do this:
onaction(component, action) {
if (action==component.render) {
if (component.hasannotation(@HideIfModelIsNull)) {
return false;
}
}
return true;
}
you get this behavior for any
Hi all,
One of the difficulties I am finding with wicket is the best practice
when displaying/using data that is potentially null.
Example:
I have a user object which has a nullable group property. I want to
show a link to the group details page when the group property is not
null, but
add(new LinkUser(editgroup, user) {
onclick() {
...
}
isvisible() {
return user.getgroup()!=null;
}
}
?
-igor
2009/7/30 Iain Reddick iain.redd...@beatsystems.com:
Hi all,
One of the difficulties I am finding with wicket is the best practice when
displaying/using data that is