A problem we encountered when developing web applications is the bridge between design and the technical part of the web application. Especially building web applications which need to be implemented multiple times and every time with a new look and feel.
Many times the java code contains html and if you're lucky it is plain html with only css identifiers. But even then designers get frustrated cause the html isn't what they wished for. And to change this a developer needs to code, compile, test and deploy a whole application before the designer can continue designing. This circle frustrates the designers even more resulting in artists with a lack of inspiration for creating the new '
mona lisa' under the web applications.
Designers have some demands on how there work environment should perform.
- Working in a real time environment (so there sure what they create works)
- Quick feedback of there changes
- Complete freedom in creating / designing the html
Demand 1 looks easy deploy a working implementation on a server and give the designer access to the directory containing the web resources (html, css, images, jsp, etc.). This also solves demand 2 cause changes made to the web resources (if you don't work with precompiled jsp's :-)) are direct visible in the browser.
The problem occurs in demand 3. Jsp's contain logic which sometimes can be understood by a designer even if it's free of ugly scriplets. Jsp's also contain custom tag's replaced by html-code at runtime on which a designer has no influence what so ever.
A solution we use to give complete freedom to the designers is to develop a web application producing a xml result for every http request. The disadvantage of html over xml is that html forces some kind of designing skill on the java developers while xml only contains the content and no information of how to display the content.
There are some things to consider using a xml spitting application.
- You need a designer understanding xslt's.
- To meet up to the designer demand 2 the xslt's need to be reloaded whenever they are changed. This is not a real problem using client side parsing, but client side parsing give cross browser problems and isn't as powerful as server side parsing. (We use only server side parsing).
- The xml must have an easy and logical format so designers have no problem understanding them.
A extra advantage of a web applications returning xml is that you have a relative easy way to supply other clients than browsers with the same content, e.g. pdf, svg, mobile phones, etc.
A reminder for who ever was interested in reading this I don't talk about web services. Web services generally speak soap xml and that's xml with to much technical clutter in which a designer has no interest what so ever. They also need an other kind of client which is able to understand there language and browsers aren't one those clients.
