Rule #4: More than two. Modularize user-interface code.
Web user-interface code is made up of many small, special purpose languages mashed together into one web page. This can quickly become hard to read. Modularizing your code is the key to making the code easier to understand, but overdoing it can also make the code obscure. If you remember the mantra more than two and understand each language's facility for modularizing, your code will be as readable as it can be.
Dynamic Output
Dynamic Data
If you use the same programmatic pattern more than twice, encapsulate it even if the data source can differ.
Write a generic procedure that can take arguments for variable data sources or output. Whether this procedure is
server-side or client-side depends on the specific case.
Server-side conditionals (if/else, while, etc.)
It's unavoidable that you'll have server-side code inline with the body of the markup. For a highly functional web application,
this happens most often when you're writing code to loop through and format a collection pulled from the database. Never nest
inline conditions more than two levels deep. If you have deeply nested conditions, pull some of the logic out into a procedure.
Don't repeat static HTML (markup)
If you have a dynamically generated value but the HTML/CSS formatting is static, put the dynamic part into a function
but not the HTML. This will allow you to state the markup itself only once.
Don't Do
`if` <body onload="`myval1`">
`else` <body onload="`myval2`">
Do
<body onload="`BizHTMLfunction1()`">
Where [BizHTMLfunction()] handles the businessHTML conditional and returns the appropriate value.
Encapsulate flaky HTML (markup)
If you have an HTML/CSS combination that a) must nest in a particular order for all browsers to format correctly and b) is
used more than twice, encapsulate it in a procedure that write()s or print()s
the formatted output. Otherwise, the markup should be part of the main client-side HTML page.
Cascading Stylesheets
Stylesheets can be applied to an HTML element inline, via the style attribute, or through a CSS stylesheet. Some developers advocate using one way or the other, but this is false simplicity. Both techniques have their uses. Here are some guidelines for implementing CSS formatting. In many cases, more than one of these suggestions will apply. It would be impossible to come up with a difinitive set of rules.
- Use an inline style for formatting markup unique to a given web page and used only one or two times.
- Use a CSS #referent in an included, external stylesheet for formatting content that appears once on a given page, but must be reproduceable across multiple pages. For example, this suggestion would apply to a navigation widget with the same position on each web page.
- Instead of #2, you can use an inline style for formatting unique to a specific server-side procedure that outputs the same HTML on every web page. For instance, a dynamic, formatted page title across the application could include both the dynamically determined content and the styling.
- Use a CSS .class or <element> in an included, external stylesheet for formatting content of a consistent and repeated type that can occur more than once on a page, and across many pages. For instance, maybe your web application displays a list of "document numbers" or "subtotals" and you need to define a consistent visual appearance for that type of data across the web application.
