more eThreads

Monday, March 19, 2001, at 04:37PM

By Eric Richardson

I'm working on architecture stuff. Click if you care to read.

So right now I'm in one of those states where I think I know what I want the end result to be, but I keep going back and forth on how I plan on doing it.

The current manifestation of the dilemna is headers and footers. Right now #{node "7"}eThreads#{/node} differentiates glomule look themes by class, and when doing recursive loading of theme settings it loads themes associated with parents of the glomule which have the same class. The problem is that I want header and footer to be special, and to apply across all classes. At the same time, though, the other side of me thinks it would be better to allow different classes to set their own header and footer, in case the differences in how data should be displayed necessitate different page layouts. And then the crazy thought comes into my head that really I should be going for the best of all worlds, and make global header/footer settings that carry down, but still allow headers and footers to be changed on a per-class basis at any level.

I tell you, customizability is a slippery slope. The thing I'm most proud of in eThreads is the way that every little detail, down even to the most minute bit of HTML, is customizable. This way of thinking occasionally actually simplifies things, allowing me to see from the start the abstraction that should be in place to make each feature more flexible and powerful. More often than not, though, it leads to headaches as I try to figure out how to actually implement that abstraction. Yes, the end result is great, but the work it takes to get there isn't.

Right now the main thing I see in eThreads is size. There's a lot of code there. Granted, I think most of it's really well written code (even if I did write it myself), but project size does add extra complexity to any project.

And with that little outburst, I'm off to bed.