Archive for May, 2009

Refactor BuildDrawable for extensions

May 19, 2009

Problem:
Every sender of ClassicBuildDrawable>>buildRightMarginFor: added an id attribute to the tag generated by the method. The new page-specific behavior needs to override this method to suppress the right margin.

Solution:
Move the id attribute up to buildRightMarginFor:, then override buildRightMarginFor: in the new (special) builder.

Advertisements

Extend PageContainerSpecification protocol

May 19, 2009

Problem:

A specific page in a Glooper site needs to be handled specially, with behavior provided by a new descendant.

Contemplated solution:

Add protocol that allows the new behavior to be supplied in a block, supplied by the descendant, that calls back to descendant code when the page is generated.

Approach:

1. Create spike solution to validate that the approach works and settle on the required new method(s).
2. Add tests to GenericGlooperStructureTest to document new behavior.
3. Adjust spike solution as needed.
4. When PageContainer is working with new behavior, add code to the new site that uses it.

Catching up — Glooper history

May 14, 2009

I’ve been heads-down with Glooper since February, and it’s way better now.

It has tests (hooray), I’ve refactored it so that it will fit into the Zeetix (Hex?) world, and I’m now using it every day to update the Zeetix sites. I’ve published the first site out of the new Glooper chute — check it out at http://www.zeetix.com.

As soon as I get a chance, I’ll add a post here describing the Glooper product/feature/assembly structure, including its test assemblies.

Glooper began as a website development tool I wrote in Smalltalk and called (for want of a better name) “SiteBuilder”. While SiteBuilder was cool and worked well enough for my needs a few years ago, it had several serious shortcomings that I needed to fix:

  1. One site at a time: SiteBuilder could only handle one site at a time. I maintain many, and many are related to each other. I needed to be able to make local changes locally (for leaves of the site hierarchy) and global changes globally (for shared nodes).
  2. Limited resource support: SiteBuilder did a poor job of handling resources like stylesheets, scripts, images, and so on that need to be present on the deployed sites. Many are shared, yet many are site-specific.
  3. Clumsy and error-prone configuration: SiteBuilder relied on reading and handling lots of outboard configuration files. Each ended up being copied to the leaves, and simple but global changes required error-prone hand-editing of each copy.

I’m sure there were more motivators, but those were the three big ones. I’ll post more entries here describing the changes I made.

More immediately, I’m now in the middle of Glooper’s next real test — an update to a site I built with its old version. I’ll be blogging my experiences here.

The site is for a real paying client (Ambiance Painting), an upscale painting company in Connecticut. The client wants to “spruce up” the site, add a blog, and include archived and current issues of a monthly newsletter distributed using ConstantContact.

Stay tuned!