On Page Navigation

We had a post on the wicket-user list earlier this week, where the author of the post asked how to use a more fixed navigation model for Wicket.

First, let me state that any navigation model is entirely doable (and even enforcible if you want to go through the effort) with just a couple of simple classes. Wicket does not enforce any navigation model on you, and leaves the door open for you to decide on this. That seems to confuse people every now and then, especially those programmers that have been using other web frameworks in the past.

This remark in that email is what triggered me to write back a lengthy response:

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.

Here is my slightly modified reply, saying I disagree because:

‘First of all, there is the matter of 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 page navigation anyway? There are many ways to
group your functionality. Using pages, Wicket’s top-level component, is one of them. If you define different pages for all the combinations of components you’ll use in your application, 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. Wicket is a good choice for more complex user interfaces that resemble desktop applications. If you take a step back and think about how you would code the application you’re working on e.g. using Swing, it is quite unlikely that you would use a bunch of windows/ frames with a factored out navigation mechanism. More likely, you would start with a window/ frame, and from an initial stack of components, you would enable/ disable/ hide some components, replace (or stack) panels, etc. This is in fact my favorite approach for Wicket, with the exception of where locations should be bookmarkable.

Lastely, there is the issue of reusability. The application I currently am 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, which can be found in the wicket-extensions project. That component will function on any page/ with any combination of components. And with 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 applications, and you can decide later on to ajax-ify or de-ajax-ify parts of it, without major restructuring. So instead of suddenly having another ‘navigation approach’ when you use ajax, with Wicket it all fits in the same approach.’

Basically my point is – in case that wasn’t clear yet from the above reply – that declarative page navigation is a bad idea that is in 3/4 of web frameworks because people are either blindly following old ideas, or they like to build stuff without thinking first why they would need it and whether they choose the best abstraction.

One of the worst things of model 2, but also any ‘flow driven’ approach, is that it is very procedural. Rather than trying to define what objects you have, and how they should interact (OO), you’ll be focussed on how to do stuff (if this, then that, if that then foo) And if procedural programming is your thing, why would you pick Java?

By pulling the navigation out of components, you’ll loose the ability to make that navigation an implementation detail of that component (like the wizard does). And as the navigation will be handled by some intermediate piece of software, you’ll open up a whole can of worms like how to pass information between steps, how to conditially make transations, etc. Before you know it, you’ll need a seperate framework for this, with it’s own DSL, tooling and fame-aspiring authors ;)

A final remark about ‘flow’ is that lots of people probably confuse workflow/ business process management (BPM) approaches with the kind of flow that is regularly promoted in user interface frameworks. They should be regarded different things. If you choose a BPM driven approach for your project, your user interface, or at least parts of it, should be driven by the BPM engine. I haven’t looked into Seam in regards to how it integrates with jBPM (which btw is one of my favorite open source frameworks), but I’m suspicious that they promote BPM for the wrong reasons. If workflow is not a major business concern in your project, you’re probably using a domain driven approach. It that is the case, think twice whether you really need formalized flow.

17 thoughts on “On Page Navigation

  1. n8han says:

    Now I can add “page flow” to the pile of overblown concepts that I’ve never had much use for and you’ve thoroughly dismantled. If you’d post more often, JSF might just collapse into itself. (Sadly, thousands of overpaid J2EE architects would then be unemployed.)

    By the way, I’m integrating jBPM into our Wicket app here at work and it’s smooth as silk. I was kicking-and-screaming trying to get out of using any workflow-type package (having been permanently scarred by Documentum a few years back) but this thing is pretty pleasant. After a week it’s already helping more than it’s hurting.

  2. I used jBPM on a project for a bank last year. I especially liked the fact that it can just be included as a jar and it works. And the API was quite clear to program to.

  3. Btw, JSF certainly isn’t the only ‘offender’ here :)

  4. What Eelco said. But I think this whole mistake of “abstracting” or “factoring out” page flow is just a microcosm of a larger set of mistakes being made at present. There is a very important distinction between markup and code. We don’t need frameworks that turn /behavior/ into a big pile of incomprehensible XML /markup/ that we then need tools to manipulate. Java IS behavior. Markup IS data (or metadata). Getting those two things straight is an important first step in digging ourselves out of the mess that is J2EE.

    BTW, if we have “thousands of overpaid J2EE architects” and Wicket is a superior approach, that would seem to imply that there are at least a few UNDERPAID Wicket architects! ;-)

  5. Mats says:

    Funny, I’ve been using Wicket and JBPM for about a eight months in project for a swedish municipality. It seems that Wicket and JBPM are a good match for developers out there :)

  6. Ha Vo says:

    Hi Eelco, thnx for providing your answer on my LinkedIn question

    I think the choice is made :)

  7. Rafael Ponte says:

    Interesting, and I agree with you!

    The “old-school” always used the “page navigation” approach for a long time, but actually it’s not the best way to develop rich-application, mainly with JSF or any component-based framework.

    Nowadays JSF has a lot of ajax-components and is really simple navigates through “views” by means of “state driven navigation” approach, but the most of people doesn’t know anything about that and they finish up prefering the “old-school” way.

    I agree with above comment too, and I know that it’s necessary to clear up this idea for most of developers.

    So, I wrote a simple post about that [state driven navigation], however it was written in portuguese (because i’m brazilian, rs),

    Great post!

  8. Eman says:

    Hello Eelco,

    My boss want to implement jbpm in wicket. Can you have some pointers or codes to share? im actually familiarizing jBPM, how it works and etc… and after that I will integrate it to wicket. It i nice to have a headstart.
    Thanks a lot. Cheers.

  9. Venu says:

    I need Some info about to using JBPM and Wicket

  10. Eman says:

    you can checkout this project http://code.google.com/p/wicket-jbpm/ im almost done with this project.


    • Cool Eman. Sorry I didn’t get to reply earlier. I wouldn’t have been much help to you, because I’m not using jBPM, and while I’ve used it in the past for a prototype, that knowledge is a bit stale by now :-)

  11. Eman says:

    Thats okie. no problem :) hope someone will be able to find that project useful. I will continue the development of wicket-jbpm every weekend.

  12. Frank Silbermann says:

    Pure, static HTML websites use page-based navigation implemented by page links. The average web programmer thinks, “I’m using programming code to make my web site dynamic! Isn’t it neat that this framework centralizes control over my page navigation?”

    In promoting Wicket (and we _must_ promote Wicket if it is not to be drowned out by inferior but better funded technology; there are plenty of historical examples of this occurring) — we have to emphasize that web programming is no longer merely about adding dynamic aspects to websites, but rather it is about creating multi-user computer applications that use web browsers as remote graphical dumb terminals (or, with AJAX, as _enhanced_ graphical dumb terminals).

    I think the reason Wicket is under-appreciated by the masses is that most articles introducing Wicket provide a tutorial on building a simple form display that’s equally easy to build in any other framework — as though the reader has already determined to use Wicket and just needs help learning how to do it. What would be better is to come up with a small sample application that could be easily implemented with a single Swing frame whose components change as users do things but where the user has lots of choice as to his order of doing things. It should be an application that would be extremely stupid to build as a navigation between static frames because every path might require a different permutation of visible components — and therefore you would need a huge number of static frames.

    Then we could have an article comparing implementations in Wicket versus Struts versus JSF/Seam. The code in each framework would appear in pop-up links, with the Wicket code being a few pages long, and each other frameworks’ code being a few dozen repetitive pages long.

  13. Frank Silbermann says:

    PS. Maybe a Tic-Tac-Toe program in Wicket versus JSF or Struts.

  14. lkafle says:

    great article !!

  15. fsilber says:

    To all those who harp on the importance of a declarative means of specifying “page flow” I would ask why fat-client developers (Swing, VB, Delphi, PowerBuilder) didn’t require a declarative means of specifying FRAME FLOW for their applications.

Comments are closed.


Get every new post delivered to your Inbox.

%d bloggers like this: