Geriatric code. Can't stand it.

[strredwolf]

I can't stand geriatric code -- code so anchent it's a wonder it works.  KeenSpace's autoupdate engine is the main highlight here.

I'm rewriting it.  Parts are already working on the Wolf357 engine, and I'm testing it with my own comic on my laptop. 

The design is much better -- metainfo (from the DB) is stored in a hash (comming from an SQL DB), and comic dates are stored in a hash of arrays.  It's in Perl (like the old code), and uses Perl 5's reference (aka C-like pointers) features to keep the organization sane.  Plugins are designed to be "write, chmod +x, and forget" instead of having to edit a central configuration file.

***todays_comics*** is implimented and tested.
***advertisement*** is implimented, but not tested.
***first/next/previous/last_day*** is being implimented.

I need to go through and see which tags are being used.  Hei-ho shell scripting!!!

Comments

[kisai.livejournal.com]

Wolfie, plase make whatever you are doing modular. One of the things that PO'ed me with autokeen was the much assumtion that was done to the code that I had to layer on the dispatch enging with extra stages because I couldn't predict the outcome of autokeen.

Idealy I'd rather move to a more efficient templating system. Perl is fine what what we do with it, but once again there is too much assumption. For one, I'd like to be able to define a template timestart/end so that different templates can be used for certain dates (ie halloween/christmas/etc) .

The Rant/News system I have a better idea, The rig for the front page with an openended css that generates static pages. Though this is theory.

The thing that aggrivates me right now is that the hoverhead increases 25% whenever another stage has to be done. We need a second server just to break up the midnight EST/PST/GMT updates. Not all of them are completing in time.

I hope you aren't assuming that every comic has only one user, one comic and one author, as it's not the case.

[strredwolf.livejournal.com]

I am. There's no actual ".cf" that brings in all the code -- the plugins are probed.

I also think that the current AutoKeen engine isn't as efficent as it could be, and right now we're currently compiling comics one-by-one. The old setup assumed alot of things. Wolf357 is going to require some DB schema changes to fully exploit it's abilities (including subcomics), but is compatible with the current DB schema and will translate them.

Want to see my source code?

[kisai.livejournal.com]

email it to me.

Like this is what I'd like to do:

Probe for a template, compile this in memory, spit out the flatfiles, basically changing the variables for each comic.

The ***todays_comics*** is the source of much trouble since it assumes that all comics you want one-after-the-other, when it really should only put one comic in, but compile a one-time include file where if defined as css, table, or one-after-the-other it would pre-generate that the first time, and never have to regenerate it.

Oh
xHTML and CSS compliance please.

Two tags I'd like to add, if we can address the xhtml/css compliance is ***header_data*** where it would put in the link to a css file defined (remember, people know how to change colors, not code if they don't know html) or replace the entire header/footer with ***all_headers*** which would replace advertisement, and ***all_footers*** which would put all the footer data in. The all_headers would address the html declaration, all the HEAD data so all the features would be available (css, rss, loading hints, meta tags, etc) It would then go as far as the body tag, put the advertisement in the "above the fold". Expert users can then go back to just the advertisement code if they wish. Have autokeen make sure that the advertisement is placed only once.