Leveraging Wicket templates for offline viewing with Dreamweaver

One of the many great features about Wicket is that all its templates are plain XHTML, with only a handful of special, unobstrusive tags. This has a number of advantages over templating languages like JSP-taglibs or Smarty.

  • Viewable in any browser – offline, without running a server.
  • Wicket Tags don’t destroy markup, they are just added to provide hooks for the web application.
  • Editable with existing, powerful webdesign software like Dreamweaver.

In this article, I want to focus on the last point, showing how to get the most out of combining Dreamweaver and Wicket. The goal is to have a functional offline-version of our Wicket application. All layout and design changes will be made to the actual Wicket templates – no more copy & paste between what your web designer made, and what you use in your application.


Web applications are very often designed in a way that most, if not all pages share a common layout. E.g. you have a logo and the main navigation on the same spot on all pages. So when doing the basic webdesign for your page, one would usually create a HTML and CSS to display a sample page, and continue to work on that. Eventually, you have all your pages layed out as static HTML, and will develop the application accordingly.

Wicket markup inheritance

To cope with requirements like this, Wicket provides a feature called markup inheritance. You can read it all up on the Wiki, but to make it short you have a base WebPage with common markup, behavior and components, and subpages using this and extending it with their own. It assigns the idea of object inheritance (from OO programming) to markup.

Regarding previewability, the following facts are of importance:

  • In the base markup, there must be a block. Everything between these tags will be replaced by the markup from the extending page. Only markup outside will be in the rendered page.
  • The markup of the child pages must contain a block. Everything between these tags will be merged with the markup from the super page. Everything outside (except ) is ignored for rendered pages, and not even necessary.
  • Everything between is for preview only, and will never be shown in rendered pages.

So after the web designer finished his work, you would convert the basic design into a template for your base page, and for all sub pages accordingly. So far so good.

But what if it becomes necessary to do some changes to your basic layout, minor or major? Regarding rendered pages, it will be enough to change the markup of your base page. But all your subpages will still have the old markup – if any at all. Pages added after the initial design often contain only very basic markup, because as stated above, they don’t require anything but . This would break offline preview, or require a lot of work just to fix that.

Dreamweaver templates

If you have worked with Dreamweaver, you may know that it has a similar concept called Dreamweaver Templates, short DWTs. You can create a common markup for pages and define „editable regions“ for them. Outside of those regions, the markup of pages cannot be edited, it is copied from the template. Changes to the template can be applied automatically to all pages using it. Links in the DWT to other pages or images are changed in a way that they work in the actual pages. This feature probably by now that CS3 is out, but I was able to use it with my old Dreamweaver 8 copy.

Combine the two

So, now you have two solutions for coping with „common layout“ – one for static pages, one for dynamic web applications. Combining the two is quite easy.

  • Start a new site in Dreamweaver. If going with the standard Maven layout, set the base folder to the „main“ directory.
  • Create a Dreamweaver template for your base layout. Include necessary CSS and JavaScript,
  • Define an editable region where you want the content of your subpages to be.
  • Apply the DWT to the markup of your base page and to all subpages.
  • Make sure the markup of your base page has <wicket:child></wicket:child> in the editable region.
  • All other pages need to have <wicket:extend></wicket:extend> in the editable region.
  • In your main navigation (probably defined in the DWT), make links to your pages.

If you now need to change your basic layout, your designer can use the DWT to update the offline preview version of all pages. Browser compatibility and stuff like this can still be tested without any web application, and those changes don’t have to be manually applied to your web application.

If feedback justifies it, I will try to write more on that topic. A modified wicket-quickstart showing this technique comes to mind, or extending this to Wicket panels and Dreamweaver library items.

Overall I have to say that this worked very well for me with a current project. The web designer is able to work without having to know very much about Wicket, and I as a developer don’t have to transfer HTML into some kind of templating language, as we work on the same files. We can click through the whole site just using a browser – no servlet container, no database required, and no redeploy just to see some design changes.

8 Gedanken zu „Leveraging Wicket templates for offline viewing with Dreamweaver“

  1. Thans for these hints and the ideas. My biggest sorrow are the wicket panels thought. How to handle them. Like I now wicket for now it is possible to have only one extend reagion. So I think I will have one extend reagion and some further reagins with panels. How did your designer managed it?

    Vielen Dank und Gruesse aus den USA.


  2. All the pages using the template are automatically updated without you having to check and modify each page… Thus dreamweaver templates save a lot of precious development and maintenance time!!! It just requires a creative mind to design the web page using tools available and hence using dreamweaver templates is easy and simple….

  3. Nice and clean concept. Thanks for publishing it.

    In Wicket, managed HTML files are in a directory that is outside the static resources content root. Every time I edit an HTML file, I have to move it into the static resources content root. I would be interested to know whether you do this too or do you have a better method?

  4. My biggest sorrow are the wicket panels thought. How to handle them. Like I now wicket for now it is possible to have only one extend reagion. So I think I will have one extend reagion and some further reagins with panels. How did your designer managed it?

  5. Very great written Post, im learning german at this time and i come back very often to your blog, very helpfull the most time.
    regards from the uk

  6. Very good ideas! What I hate about wicket is its high learning curve. Component-based frameworks are more difficult to learn than controller-to-view based frameworks. This makes documentation more important, but the recommended book Wicket in Action doesn’t provide much inside in about how Wicket exactly works. This makes it difficult to do a bit more than standard stuff, when after you have read it.

    Fred Homes

Kommentare sind geschlossen.