Sorry I couldn't resist, but... JSF's navigation model elegant? I really don't see that. Imo it is in fact one of the best proofs that JSF is ill designed.
First of all, there is abstraction. If you want a JSF like navigation model, please go ahead and implement that. A couple of classes are enough for that. Whereas JSF forces you into one navigation model, Wicket doesn't. Secondly, what exactly is navigation anyway? There are many ways to group your functionality. Using pages, also the top level approach for Wicket, is one of them. If you define different pages for all the combinations of components you'll use in your app, a page oriented flow mechanism might actually work. However, that way of looking at grouping functionality is a bit outdated. It is the traditional, document oriented approach, which is fine for ... document oriented sites. However, Wicket is a good choice for more complex applications that resemble desktop applications. If you take a step back and think about how you would code the application you're working on in Swing, it is quite unlikely that you would use a bunch of windows/ frames with a factored out navigation mechanism. More likely, you start with a window/ frame, and from an initial stack of component, you'll enable/ disable/ hide some component, replace (or stack) panels, etc. This you can do with Wicket too (and is actually my favorite approach with Wicket). Lastly, there is the issue of reusability. The application I'm currently working on has many components that are fully self contained, including it's 'navigation'. I think it is great to build components like that and use pages mainly as an entry point and to group larger/ high level blocks of functionality. A public example of this is the wizard component (in extensions, see the wizard example in wizard examples). That component will function on any page/ with any combination of components. There is no additional flow configuration you have to adhere to. A funny side effect of AJAX getting popular is that it proofs that forcing yourself into a page oriented flow model doesn't make sense. Look at GMail, Flickr, and all of those web 2.0 ajax driven apps... they surely don't use such a flow mechanism. Sometimes they replace 3/4 of a screen, sometimes just one widget, and sometimes they do replace a whole screen (though Gmail, really rarely does that). The good thing about Wicket is that you can structure your applications in exactly the same fashion as those app, and you can actually decide later on to ajax-ify or deajax-ify parts of it, without major restructuring. Instead of suddenly having another 'navigation approach' when you use ajax, with Wicket it all fits in the same approach. Ok, I'm rambling now. Consider this email as a long way of saying that what you want is fairly easy to implement yourself; just decide on the strategy you want to use, and write to 2-3 classes that will do the trick for you. But also of saying you might want to reconsider whether this really is the best way to build your applications or that it is time for a mind shift :) Eelco Eelco > 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... ------------------------------------------------------------------------- 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
