jcompagner: > isVisible (and isEnabled) will never be made final. That will break many > things. > and sometimes isVisible must be completely dynamic. and can't be done > by a setVisible method (which can only be called in the event phase) > > for example if i just do a refresh in the browser of the current page. and > i have there > a listview that shows it self depending on the size of the list that it > has. This can be done in the isVisible method of that listview. I never can > set this myself anywhere > because i just rerendered the page.
matej: > Making isVisible and isEnabled final would be totally wrong. We would > lose a great deal of flexibility. "Pull" model is the wicket way. If > anything we could remove setVisible and setEnabled, but I can imagine > people wouldn't like it either. I wouldn't mind. setVisible can be also called in the onAttach method (which is now called always before the render phase) and so the visibility of a component can be made totally dynamic with no flexibility loss. I'm convinced that the visibility logic should be executed only once during a request processing just before the render phase. The reason is that the visibility logic will in most cases ask models, dataproviders and other components and will cause attaching of them. Since there is no contract when isVisible is invoked (in fact it is invoked several times during a request), attach/detach problems will probably occur. Remember that isVisible is actually called from Component#toString(). An example: The NavigationToolbar (from wicket-extensions) has overridden isVisible() that makes the toolbar invisible iff there are no records in the datatable. isVisible calls table.getRowCount() which asks the data provider and caches the number of rows until onDetach() is invoked. This works fine when isVisible is called only in the render phase. But when isVisible is called before the listener phase (e.g. when there is a submitted form inside the NavigationToolbar) the row count will be cached before the the form is submitted and the table will render wrong number of rows if the result set provided by the data provider changes as a result of form submission (e.g. some filtering or row insertion/deletion). Bendis
