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.
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.
- 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.