Have you ever looked under the hood of Swing? Most Swing programmers understand MVC, but I haven't talked to many who really understand how little logic really goes in a Swing component.

If you look inside JButton or AbstractButton, you find that Swing components are essentially Value Objects. The complexity of drawing a button is handled by the UI. Any model information is handled by a model (yes even for a button), and all that's left is getMargin() and setMargin().

Why is it then, that whenever someone wants to add functionality to a component, they immediately subclass it? I know the simple solution is often the best, but even on medium sized projects, this lack of flexibility quickly becomes a problem.

The largest problem with sub classing components: extendibility. Imagine creating two subclasses of JButton. Button A has feature 1. Button B has feature 2 and 3. Now you want a third button with features 1 and 3, but not feature 2.

Extreme programming dictates that we not deal with code sharing issues until the problem actually arises. This (to me) is one of the weaknesses of XP. By ignoring the problem, we just make it more difficult to deal with later. The XP solution of "the simplest thing that works" is (imho) a crutch for those who get locked in analysis paralysis. It's just the other extreme. And as they say: "all extremists should be shot".

Another major problem I find when people sublcass components is their lack of understanding of UI Delegates. Most Swing programmers know that drawing tasks are the responsibility of the UI, but few understand that most internal listeners (including many of those which communicate with the model) are the responsibility of the UI Delegate.

Many of the features added to component subclasses should be controlled by the UI. Many times the programmer will break compatibility with other look and feels because of this short-sightedness.

I believe these mistakes are often made because people are afraid of UI Delegates because of their complexity. Many behavior changes can be implemented by using a visitor pattern, or a compound UI Delegate. By applying changes to components without subclassing them, the look and feel is not broken and the logic can be separated from the component and applied based on any arbitrary set of rules.

For those who want to better understand UI delegates and the inner workings of Swing components, try reading "Hardcore JFC" by Mitch Goldstein (an unfortunate title, but a very good book).

I�ve been working with HTML off and on since 1995. Most of my experience is weighted towards those early years of the web. Up until recently, I�ve believed that these experiences were holding me back from really appreciating the advancements that everyone else seems so impressed with. Specifically, I never really understood the community�s infatuation with CSS positioning, and after careful thought I�ve decided that the problem isn�t mine. I�m going to try to explain why I think CSS positioning is a tool that should be used sparingly and in very specific situations.

Note: I have no problem with using CSS to reuse style information. I also don�t mind using CSS positioning for very specific circumstances. I am only trying to argue that there is no need to blindly replace all table tags with CSS positioning.

First of all, I�d like to dispel the myth that CSS allows presentation information to be decoupled from the content. CSS doesn�t control a web site�s presentation logic. It simply augments the presentation information that already exists in the HTML. It was meant as a way to allow presentation logic to be easily replaceable. From a single place, you can change all your headings to 14pt red fonts. For this, CSS works great. It saves developer time and provides for some great demos for management.

Even if the CSS could contain all the presentation logic, and the HTML contained only content, the two would still not be cleanly decoupled. The HTML must know what styles are applied to it (so it can have the correct tags on the correct elements), and the CSS must have a pretty good idea of what the html looks like. It seems to me, that if HTML and CSS were truly decoupled, then the CSS would have absolute control over the presentation, and would regulate what content was displayed, and where. To remove the last pieces of presentation logic from the content, the presentation layer (CSS) would need to have complete control (and therefore be the starting point for the creation of the page). This would limit the content�s knowledge of the presentation layer, while the presentation layer would make assumptions about the content (omitting sections of the page when those assumptions proved incorrect). This is the same concept used in Word Templates, Page Layout software (Quark, PageMaker) and by Jakarta Tiles.

Some would say that CSS and HTML are decoupled, pointing out sites like the CSS Zen Garden. If you can replace the CSS to get a completely different layout, then CSS and HTML must be decoupled. To me, that�s like saying a human heart is a standard interchangeable part� after all, if I find one of the right size and blood type, a group of skilled surgeons can replace the human heart in only 12 hours.

CSS and HTML need to know immanent details about each other. This is fine, because CSS was only designed to extend HTML as a quick way to centralize presentation properties that may change often. CSS is simply used to create themes.

At some point, someone decided that all presentation logic should be expressed as CSS (rather than as a mix of CSS and HTML). Replacing HTML with CSS makes sense for presentation logic that may be replaced across a site at a later date, but what about presentation logic that won�t be repeated elsewhere in the web site? The consensus seems to dictate replacing all presentation based HTML tags with CSS alternatives (regardless of reuse) for the sake of consistency. This sounds like a great idea for presentation based tags such as the font tag. Both pieces of code are relatively simple, and provide the same benefits:

Error Message

and

Error Message

The CSS based code has the added benefit of being consistent with CSS syntax used in external style sheets (where the benefits of CSS really shine). The font tag just doesn�t have any advantages here.

The same logic should hold true for CSS positioning, right? That has been the rational so far. People have seen the trend: move all presentation logic from the HTML to the CSS. But at what benefit? What cost?

Moving simple visual properties to external style sheets has noticeable benefits. All pages can share the same properties. Changes made in a single spot can be reflected immediately through the entire site.

What about positioning data? The same rule still holds. Positioning information externalized and referenced throughout the site could be changed in a single place. But that doesn�t provide any amazing benefit to a dynamically generated site. Server generated pages can already be created from centralized templates. In most cases, that template is created visually and aren�t as tightly coupled as a CSS solution (tiles, for example is view driven � the solution I suggested above in the decoupling section).

What about features? While it�s true CSS positioning has a good deal of advanced features, most go unused. Most websites can still be created using simple nested tables. HTML Tables have an advantage over CSS in that they are much simpler to use.

This leads me to believe that CSS positioning is only advantageous in two situations:

• The site is static, and a consistent layout (which may change) is required throughout the site, or
• The layout is complicated enough that it can�t be done without CSS positioning.

Because traditional layout using HTML Tables is so much simpler than CSS positioning, the two cannot be considered equivalent. Each has their place. For that reason, I don�t think one can be safely eliminated for the sake of consistency (as can be done with the font tag).

The rush to replace table layout with CSS positioning is based on:

1. The incorrect assumption that CSS was designed to decouple presentation logic from content
2. The �dirty� feeling people seem to get when they create layout using html tags originally intended for tabular data presentation.

Had the �table� tag been called �layout�, there might not be an issue.

In the short term, I don�t see any reason to use CSS positioning unless the site is static and has a consistent layout or the layout is too complex for embedded tables. In the long term, I believe CSS positioning will only be a viable solution when it has been extended to be at least as simple as HTML Table (perhaps by adding layout managers to the existing CSS spec).

UPDATE: I found an interesting article supporting my opinion.