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

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 :)



> 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
Wicket-user mailing list

Reply via email to