|
|
Index: Home | What Is Izumi | Misc Links | Random Thoughts | Too Much To Read | The Rant Vault | Quotes Dev: Projects | Ideas For Dev | Nerdkill | Rig | Hint
$Id: What Is Izumi.izu,v 1.15 2005/11/05 21:55:57 ralf Exp $
Title: Izumi (泉)
Goal: Simple web site content management using formated text files
Acronym: IZU
Language: PHP
Environment: Linux/Apache/PHP or Win2k/IIS/PHP
Type: Web script
Started: 2003/08/08
Izumi is a simple web site content management. Each page is rendered from a text file with a syntax similar to Wiki's text input or Textile. Rendered pages are rendered as HTML; this HTML is cached on disk when viewed the first time in order to make subsequent views fast & low on CPU.
It is possible to update the text files directly on the server, using any kind of text editor.
There are features not supported by this project:
Originally I was planning to submit the project to SourceForge using the RIG license (Perl's Artistic license). Then I decided I would merge it in RIG and that it had no future as a standalone project. Now I'm changing my mind again. It would be good to merge it in RIG, yet it is a useful project just by itself. The current architecture is pretty clean and most of the code specific to Izumi is splitted in a couple of classes or files, so it would be easy to share this part of the source between Izumi and RIG. More info later here.
Some of the descriptions here relates to my initial view of the project and have been more or less updated and thus may be inacurate now. I will keep it for history and later reference, but it needs to be cleaned.
This section describes the actual features of the project.
<tbd>
When looking for a name, I started with there initial ideas:
The first idea for a name was RTG (Ralf Text Generator). But then I decided to go for a Japanese-looking word (made up and sounding good) that conveys the meaning of bunch of pages with word content.
Tanigo was my first choice. It didn't sound that good. It was composed of tani (valley) and go (word),
the valley as the entrance to a mountain of words.
Izumi sounded nice, goizumi or izumigo's not so good.
Izumikoto and kotoizumi were interesting altneratives (I believe the sound "goto" is an alternative to "koto").
"Izumi" sounds right; 泉 is a nice kanji; "fountain" is a good meaning. More precisely, it means a natural spring of pure water. A good 3-letter acronym is "izu".
Why a new project? Why am I reinventing the wheel?
Like for most developments, it's easy to handcraft a fast prototype in "5 mn" (programmer's time), but it's more difficult to keep it alive and maintain it for real. The experience from RIG (and somehow from PowerPulsar too) shows that this actually happens if I actually use the project for myself and others. That and starting with a small goal to enhance it later rather than do the Right Thing first (a.k.a. Worse is Better).
Probably none of the following will be used:
I'm still trying to find an existing text parser to use (instead of hacking my own, which I started anyway). Here's a collection of related links (none providing the ultimate php script ready for me):
Having a look at the PhpWiki sources raises another issue: it is GPL, whereas I favor the Perl Artistic license. If my understanding of GPL is correct, reusing these sources imply I should make mine GPL too (and not just OSL compliant). That makes it a no-go.
Hmm I should add that my text parser currently is a big PHP/regexp kludge. I so don't like it as I can foresee it will be hard to evolve and maintain. Maybe there's a reason why PhpWiki's one is complicated.
20040423 Update: Actually my kludge is not so bad. It does a pretty good number of things. The only thing I currently lack is tables support, not because I couldn't code it but more because I fail to find a good wiki-like text syntax for tables.
These are old interesting ideas and extensions that I came up with when I started the project. They were useful in definition the direction of this project and highlight the kind of use I was envisionning. None of these have been implemented exactly as-is, if at all.
Syntax can be Wiki, simplified and/or enhanced.
Workflow:
Backups/alternates:
HTML caching:
Reuse pieces of RIG or apply to RIG later:
More ideas, en vrac:
Oh, I get it! Rather than have [topic:] I should use "number.number. + tab + title" for automatic heading generation.
There are two kind of templates:
Started: August 2003 Finished: November 2003 Status: Closed
Milestone 1 is a proof of concept, a pure hacked-to-the-core prototype. I basically took the PHP skeleton from RIG and made some classes to handle text files and display them.
The text rendering handles basic elements as links, hr bars, blockquotes, preformated text and first-level lists. That's really not much but it gives a good starting point.
The source reuses the common files from RIG, which provide a bunch of utility functions to manipulate preferences, cookies, generate HTML parts, etc.
The main difference with RIG source is that this one uses PHP classes, to be exact the following classes were introduced:
Izumi seems to be the right project. I currently edit this text file on the Linux server via Samba, using my favorite text editor on my Windows box. And I can see the result instantly by just refreshing Mozilla. That's the kind of workflow I had in mind and I like it a lot better than having to use a web interface to edit the page, as in PhpWiki, or use a form to enter a new blog entry as in Drupal -- less clicking, more typing. Just perfect, don't touch it!
Now, as far as the implementation goes, I'm not too sure what I want. The idea started with SyntheticPlan should be merged with Izumi. OK let's be frank: SyntheticPlan is not intended to do what Izumi does, but my idea was to have it "enhanced" (the real word is "hacked") to do something similar. Editing would probably have been done using a WinForm/C# desktop client that a simple text editor. Implementation wise, SyntheticPlan was also the first project that I wanted to plan and document thoroughly before writing code. So far that hasn't been too succesful either because I do have some valid doc but I have nothing to use -- thus no incentive to really think about it. So now I'm kind of considering going the other way around.
Milestone 1 was a quick-hack prototype. It worked. You're browsing the result of a successful prototype right now :-) This is an attempt to update what has been done and what's left to do.
Started: November 2003 Finished: November-December 2004 Status: Not-Quite-Closed (maintenance only)
Milestone 2 introduces "blog" support in Izumi -- a given izumi file is automatically split in blog entries, the more recents are served and the older ones are accessible as "archives".
RSS support as been added.
As the project seems near completion now, Izumi will be labelled as version 1 and packages will be made available.
Most notes have been moved out of the project page and into the Izumi page. Here you will find just a generic overview of the milestone 2.
(Notes are in chronological order.)
Implementation of the blog is pretty simple: a RBlog class is introduced, which is activated by a given Izumi tag in the Izumi master file. This class is responsible for splitting the master file into blog entries and blog archives, each one being a single Izumi file which are then rendered using the standard RPage class.
The original idea was to merge Izumi in RIG 2.0 as a module and then implement blog support as a new additional RIG module. Since I kind of gave up on implementing the modular RIG right away, I decided instead to implement the "simple" blog idea I had earlier -- simply parse Izumi files and generate blog entries depending on a tag.
Having implemented just this, it works very well, doesn't feel too much like an ugly hack so far and the final code is pretty clean.
I started implementing a Debian package. Some RPM packages will follow although I'm not quite sure which platforms to start with.
Originally I also wanted a mechanism to remotely update the content base. Well I found the easiest way to go is simply use CVS and on the server have a cron job that does a CVS update every few hours.
No milestone 3 is planned at this point. I'll leave this running on my server for a while and eventually will add some minor feature and when I'll be satisfied the whole thing will become a version 1.0. I expect this to happen by end of spring 2005.
Milestone 2 is very solid.
The blog implementation is clean and really adds a lot to the CMS part.
No milestone 3 is planned at this point. Milestone 2 should result in version 1.0.
|
|
This work is licensed by Raphaël Moll under a Creative Commons License.
|
|
| Color Theme: | Gray | Blue | Black | Sand | Khaki | Egg | None |
|
|
|
|