tags:

views:

285

answers:

1

I have a AjaxPagingNavigator. Basically on a certain condition, the list which the AjaxPagingNavigator pages is reloaded. When this happens I only want to render the navigator when the list contains more than 1 page.

So does anyone know where I can attach a handler so that I can check for a visibility condition in my AjaxPagingNavigator and enable/disable visibility so that when the navigator is updated via. ajax it is either visible or not?

Markup:

<div wicket:id="mainWrap">
    <div wicket:id="navigator"/>
    <div wicket:id="listWrap">
        <div wicket:id="list><!-- here be content --></div>
    </div>
</div>

So I have an ajax event which refreshes "mainWrap" which refreshes the "navigator" along with the "list" and wrappings.

this is the event that triggers the whole thing.

 protected void onSubmit(AjaxRequestTarget target, Form<?> form) {
     List foo = null; // do work to get list
     model.setFound(found); // update the model (thus updating "list")
     target.addComponent(mainWrap);
}

Edit: I know I can write

navigator.setVisibility(list.getPageCount() > 1);

after creating the navigator and after updating the model, but I was hoping to encapsulate that in a subclass of AjaxPagingNavigator.

+3  A: 

It's been a while since I touched Wicket, but if memory serves:

Can you not override the isVisible() method of your "navigator" object, such that it only displays under the condition you desire?

e.g. something like

.addComponent(new AjaxPagingNavigator(...) {
  @Override public boolean isVisible() { 
    return model.getFound().size() > 25;
  }
});
RenderIn
Ha! I feel so stupid. Here I looking through all sorts of crazy behaviors to attach and set visibility. Oy!BTW "return super.isVisible() " is probably better since we want to ensure if someone else sets us to invisible we respect it.
Dmitriy Likhten
Don't feel stupid... when I was developing Wicket applications I usually spent a lot of time looking for solutions to my various problems, and when I found them they were almost always much simpler than I expected.
RenderIn
I'll second that. I think the Wicket developers have done a great job, because usually as I look into an issue I realize how easy it was to solve/fix and more intuitive that I would have thought.
Matt