Gary
Burd: I recommend extending Mombo's comment file format to
include more fields than title and body. The attribution
information should be moved to one of the new fields and be
formatted by the template.
I love it! Gary, how hard would it be for you to come up
with a weblogging package that has roughly the same functionallity
as mine that you could live with? I'd love to collaborate
with you. If you feel likewise, feel free to use as little or
as much of my implementation in this endeavor as you see fit.
Could you host a cvs repository on your site? Or would you
prefer it elsewhere?
Gary, how hard would it be for you to come up with a weblogging package that has roughly the same functionallity as mine that you could live with?
This is difficult for me to answer because I don't know where the line is between feature choices and implementation choices in Mombo. For example, is the Blosxom file format a feature that you want, or is it an implementation convenience?
Can you provide a list of the features that you want in a weblogging package? I will do the same.
Could you host a cvs repository on your site? Or would you prefer it elsewhere?
I prefer elsewhere. I don't want too many people depending on the 400MHz computer in my basement.
Do you have any experience with SourceForge? My friend Dave has been using SourceForge. I will ask him about his experience.
I realize that these are vague, but I am quite willing to provide a wide range of wiggle room. Example: I realize that we differ on the wiki syntax, but if you notice, there are no instructions on my page and yet most comments are formatted reasonably. But if pulling this back some makes for better cooperation, I'm all for it.
I have some experience in Open Source. ;-)
Note: no pressure to collaborate. If it turns out not to be the right thing to do, no problem.
I think I understand all the requirements except the full function template requirement. Do you want the ability to place all presentation in the template, or do you want access to a programming language as in Cheetah?
I'm enamored with Cheetah (did anyone get the significance of the name Mombo?) What would I lose by switching away?
This just might be a deal breaker... ;-)
Note: I invested a half hour here and a half hour there over the course of a week to produce what I currently have. I'm not particularly emotionally attached to it... in another few weeks I just might decide to pursue yet another technology and/or programming language.
[Yes, you caught me using italics. I used the html tags. I don't remember your wiki formatting rules for italics.]
With Cheetah templates, I see Python code that in my opinion does not belong in a template. I will send a few minutes today to see if this is due to a limitation in Cheetah or if it's just something that Cheetah enables.
Cheetah simply enables it. Feel free to enlighten me on how to do it better.
Almost all of my HTML formatting rules are based on what I have found people actually typing in. I've found that having a preview encourages experimentation.
- Site layout driven by configuration, not by code as in blosxom and mombo.
- Ability to support different types of entries. For example, the system should be able to handle the essay section on your site in addition to the blog entries.
- vi compatible file format (I do not consider XML to be vi compatible).
- Views: entry, month, list of months with entry count, N most recent.
- Dynamic caching.
- Platform: apache with .htaccess and mod_rewrite, vanilla python 2.2 (no expat or other extras).
- Do not use file mod time as metadata (I am growing to hate this).
- Extensible metadata. For example, allow the addition of author to entries.
- Comments, trackbacks, pingbacks.
Posted by anonymous at
Hi anonymous!
Why do you consider blosxom flavours "code" as opposed to "configuration"?
The Blosxom code picks apart the URL to find month, day, year and category. In doing so, the Blosxom code determines the layout of the site in the URL space.
The Blosxom code also determines gross page layout. Specifically, the Blosxom code says that a page has a single for loop.
I agree that the flavours are configuration.
The structure of my site is determined by the configuration which, for better or worse, is stored in the wrapper cgi script. I can add day archive pages to my site by adding a line to the structure configuration and adding a template. I don't need to touch a line of code.
The layout of my pages is completely determined by the templates. Instead of figuring out what's needed for a page and feeding it into the template, the template calls back to get what it needs. It enables pages like this where I loop over articles and news entry months.
Yeah, I know it's gross -- that's why I haven't depoyed it or checked it in. I was looking at trying to be compatible with blojsom and blosxom 2's plugins. But I'm starting to be unconcerned about full blosxom compatibility. Like maybe RSS 2.0 items for both articles and comments...
You have a sitemap, not unlike Cocoon or AxKit. Yours is in Python, theirs are in XML and .htaccess files respectively. Mine is spread between .htaccess files and post.py, and post.py mixes in other concerns. Bad, very bad.
What confused me was your comment about code vs configuration, because from my point of view, your templates have for loops in them which are code.
What you really seem to be getting at is (just repeating so that I'm sure I understand): a sitemap simply determines which template to run. That template then does all the real work, and does it based on exploiting some reusable componentry that does such things as parsing files, etc. Does this sound about right?
The framework for site rendering is a site map, template system and dynamic caching. The remainder of the site rendering is handled by extensible set of components. [ My current code is not extensible, but there's a comment indicating where the extensibility point is located. ]
I apologize for being sloppy with terminology regarding the word "code". What I meant by "code" is everything except the logic required to express the presentation.
I will add AxKit and Cocoon to my list of things to look at this afternoon. I will be looking at Cheetah in a few minutes.
Don Box: Tim Ewald, Joe Beda, ChrisAn and I are trying to get the new format for exchanging items working. Here's a preview of what it looks like now This format has a number of interesting twists. First, it is document literal XML ...