My apologies if this is a topic that's been covered before on this list. I did a search on the admin page for URL, IPageLink, ILinkListener, etc, but came up with nothing. Perhaps the search engine is wanting... Anyhow, we're currently evaluating Wicket for use in developing a fairly large website.
The examples we've seen so far have navigation "rules" embedded directly in the page component definition, as such (from http://ensode.net/wicket_first_look_pg4.html <http://ensode.net/wicket_first_look_pg4.html> ): protected void onSubmit() { PizzaModel pizzaModel = (PizzaModel) getModelObject(); setResponsePage(new WicketTestConfPage(pizzaModel)); } The onSubmit handler here hard codes the response page for the form, directing the control to pass to WicketTestConfPage. In most cases, this is an acceptable approach. But it is often desireable to treat web pages as distinct, reusable modules. I may need to have a form providing some general functionality in several different sequences. In each case, the page's navigation logic would need to be specialized, since the page following will be different. I can see the obvious solution of subclassing and overriding the onSubmit method to provide specialized behavior. But this tends to bloat the object namespace, something I'd like to avoid. The other solution I've seen, using logic to conditionally instantiate the desired IPage based object within onSubmit, is equally undesireable. I understand the need to establish a programmatic means of switching pages in Wicket, as this facilitates passing a model from the current page to the next in line. I'm just hoping that there's something more dynamic than tight coupling between pages in the app. One of the most ideal solutions I've seen to date is the implementation of JSF, where navigation logic is defined in a separate descriptor. I know this is counter to the philosophy of Wicket, but in separating the navigation logic from the page definition, JSF achieves the goal of modular application architecture with elegance. I suppose a solution of this nature wouldn't be too difficult to implement, but why reinvent the wheel... My question is: Am I missing something here? What are the various strategies for navigation logic other than tight-coupling? Thanks in advance, Julian Klappenbach Ramp Technology Group Lead Developer / Architect mailto: [EMAIL PROTECTED] ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
