Skip to main content

Programmer Friendly Pages

Posted by jhook on July 27, 2005 at 12:40 AM PDT

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:

Related Topics >>