Jacob Hookom's Blog

Programmer Friendly Pages

Let's first start by talking about development roles and concerns. MVC has taught us how to separate our application into managable layers. We have the Model and Controller which are under the programmer's ownership, then we have the View which is under both the programmer's and designer's ownership. This is where issues arise as both the programmer and the designer wish to implement their concerns in the cleanest way possible within the same document or page.

Your programmers' goals are to provide structure and data to web pages; really they shouldn't care how the data is presented, only that it's there and functions within the application requirements. The designers' goals are to properly present information in a meaningful manner and should not concern themselves with knowing any server technologies such as tag libraries or the application's Java model.

Semantic contracts are the key. This is as simple as agreeing on ways of structuring the menu or providing a specific attribute such as an 'id' or 'class' in the rendered output. Unless you've been hiding from the web for the past few years, you know I'm hinting at using Cascading Style Sheets (CSS) and externalizing JavaScript behavior.

Early in the development process, designers and programmers can agree on how the documents are structured and what ids and classes are expected. These discussions will probably continue throughout the development process, but the point is to allow a degree of separation such that the programmer is no longer reliant on the designer to publish their data into documents.

If I were ask you to program the domain model for a large project, you would probably approach the problem using object oriented principles, emphasising reuse and maintainability. Now apply that same programmer mindset to developing your views with components. Let the designer mock up their own pages for developing the common CSS and JavaScript resources.

As long as the contract stays in place, the programmer can write highly reusable JSF components that aren't tied at all to the concept of a page. In some cases it might be ultimately faster to deliver the XML content right from Java code. After all, you are no longer attempting to cater to the designer's tools and you are still meeting the semantic contract everyone agreed upon.

With CSS use, the required markup becomes much lighter. This only encourages taking the ideal case for a programmer to be able to compose components that deliver huge amounts of data in a highly efficient and maintainable manner. At the same time, the programmer caters to the designer by providing CSS attributes on their components, such as id, class, and style.

You can deploy your component and use it in multiple places and the designer can, at any time into development or production, change the way your component looks on the page (or behaves in some cases) because of CSS and JavaScript standards.

In summary, programmers should be able to get the 'traditional' need for page-based development out of their heads. There's always middle ground for efficiency in projects, but after you find yourself maintaining forty or fifty pages and their associated actions in MVC 2, you will probably be looking for better methodologies. Having the designers and programmers agree on semantics early in the project opens up a lot of flexability in delivering maintainable solutions for both parties.

Here's a (sample) list of popular web sites that are using these new standards:

• ABC News.com
• Yahoo!
• MSN
• MapQuest
• CSS Zen Garden (Examples)

Comments

• Hi there Jacob,

  I agree completely with your point but one should also note that CSS's support in today's browsers is still lacking to provide a clean separation.

  
  Being involved at the moment in the creation of WAI fully compliant pages (AA), I'm seeing that there's still a limit on what you can modify afterwards using CSS... and doing it in a cross-browser way is a project on its own ;).
  So we start doing the static HTML mock up, decide how that "simple HTML" is going to be and then agree upon that. Sounds obviuos, but if you start with a logically clean HTML, you might find out later that you need some extra div's to be able to align things properly, or create them in a specific order etc.

  
  And one could say we use an extra layer, as we have Business Logic programmers providing XML (one contract) to the Presentation programmers who use XSL to provide the "simple" HTML (another contract) to the Designers who use CSS to beautify the HTML.

  
  In Spain, and in Europe, WAI compliance is supposedly going to be mandatory soon (as in January next year in Spain) for public institutions and the like, so we are going to see much CSS in the near future. Right now, it's a trial-and-error, handcrafted pain... but such is life on the edge, right? ;)

  
  Cheers

  Posted by: greeneyed on July 27, 2005 at 11:42 PM

• You are right in saying that creating that separation in structure and presentation is initially hard (especially planning the layout). But the long term benefits of maintaining such an application are worth it.

  I'm not suggesting an extra transformation layer (XML & XSL), as XHTML from your JSF Renderers or UIComponents does just fine in combination with CSS.

  Posted by: jhook on July 28, 2005 at 05:41 AM

• Oh, I'm not saying you are suggesting an extra transformation layer, I mean WE are using it.
  It's not for all the teams, but for ours it works pretty well.
  
  Let's just hope CSS support keeps improving in browsers and tools.

  Posted by: greeneyed on July 28, 2005 at 11:52 PM

• The concept of what you are talking about, to me, boils down to decoupling of code. The interesting thing about XHTML and CSS is that the decoupling actually occurs using a technique very similar to aspect oriented programming.

  Posted by: coding on July 08, 2007 at 03:57 PM

This work is licensed under a Creative Commons License.