- How do I integrate gzip encoding? In other words, who "controls" it? Is it the responsibility of the template to say "I want gzip encoding", a custom controller, the global dispatcher... based on the page level, the site level? I'll probably have similar issues with caching when I tackle that.
- How do I set up "canonical" URLs? So when I say "print weblog search box", how do I configure the target of the search box? Remember, you might have your weblog at /blog/, someone else might have /weblog/, /notes/, /users/john/pages/weblog/, etc. Maybe there should be a global search facility... one target for the whole CMS?
- How do I have pages which can "morph" and serve different purposes? If I want my root to serve both as a weblog, and as a wiki-like thing, (and also be able to go to a 404 page if no wiki page is found), how do I set that up? I've considered conditional mappings (specific terminology to my CMS), and that may work, but I'm not sure yet.
- When you inherit mappings, I'm wondering whether to always replace, or whether you can prepend, append, or insert into the list of mappings already defined for a given section...
That's all I can think of for now. Hmm...
BTW, as I've been (slowly) designing my CMS, I've realized that it seems like my main design goal is to make it as "modular"... maybe "granular" would be a better word... as possible. In other words, I'm trying to separate each logically distinct part from every other part. So I've been able to separate the template (the main display) from the content of each section. So I can say, in a different file from the template, "make the left side of the page be the navigation", "make the body print my weblog", and it'll do it. I can't really describe it better than that right now, so that'll have to do.
Wednesday, December 4, 2002
Permalink
1) GZip Encoding should be handled by the Global Dispatcher. Every time it speaks to a browser, it should determine whether that browser can recieve GZip encoded material, and if so, set a flag that says that it should be compressed. If your Global Dispatcher is also responsible for final page output, the rest is easy. However, if each individual page is responsible for its own output, you have a few extra steps of work to do.
2) I don't think you should ever say "print web search box". Instead, you have configuration files, and HTML templates (like in MovableType). The configuration file would say the the URL is "/blog/" and make it available to the template as a variable. So... in the HTML template, if a user wanted a search box they might type something like this: [form action ="%$BlogURL%%$SearchHandler%" method="get"]. Then, if you wanted to make like a little easier, you could make a pre-defined searchbox that called the variables in that exact same way. However, in this case, in the HTML template, the user could include a search box simply typing: [##SearchBox##]. Obviously the syntax is at your discretion. But you get the basic idea.
3) I'm not 100% certian what you are talking about here. However, with HTML templates being used properly, the designer of each blog will be capable of putting whatever they'd like on the front page.
4) I'm really not certain enough what you are talking about here to even attempt to answer. Maybe you can clarify?
One thing that can help ensure modularity and granularity is this:
a) there should be some portion of your code that could be EASILY stripped out (i.e. it is in a class, or it is in files of it's own) that will act completely independent of a web browser. This chunk of code should perform the core functionality. In other words, with the chunk of code, I could fairly easily make a command-line based blog only readable to users telnetting into my system, or a GTK based blog with GTK based clients to read it.
b) There should be another chunk of code responsible for deciding exactly what needs to be done and what it needs to be done to. This means that it decides what page the user wants, what items should appear on that page, and where the data for that page lives. This chunk of code is completely tied to the web environment and would be useless without it. In the perfect situation, this chunk of code would actually call the chunk of code described in part "a" to get the data, and then call the chunk of code described in part "c" to display it.
c) This is either your custom templating code, or code that will bind your system to a third party template engine. It's nice to write this piece very plainly and simply so that users can easily override it if they have another templating engine that they prefer over yours. In the perfect world, this code would be modular enough to use for formats other than HTML/XML, and would be capable of being tied to chunks of code like that described in "b", but for other applications.
Wow. That ended up longer than I thought.