Javascript and Cookies for dynamic caching

The problem with whole page caching is that for a given URL, all the content must be the same. For dynamic websites, this is a poor solution. People are used to seeing Hello, Bob and extra menu items if the user has access to more features.

Instead of full page caching, you could do partial page caching but that means more server work and more disk reads. In the previous blog entry, Veneer has a nice full page caching feature so Veneer will work around the problem.

Using a nice javascript cookie library from Paul Stephens, Veneer can parse the fields the cookie fields and adjust the Dom accordingly.

There is another problem. The URLs change depending on which module is being used. Routing in Veneer is /module/action or /controller/module/action. How does the javascript parse the URL? A quick google search produces a url parsing library by Steven Levithan.

Now, if the user is logged in, the name is stored on the client for personalization. The member level is stored on the client so if the client is an admin, a context sensitive admin link is placed in the admin area.

Auto Caching

The great thing about about the Zend Framework is that the components are so well made. There is an automatic page caching algorithm in Zend_Cache. Of course, it is not perfect since I have my own use-case. Besides, I am not sure that it works with Zend_Layout.

The solution is Veneer_Cache. I simply wrap Zend_Cache. The was noplace in the controller that I could pick up all the HTML. There probably is in Layout but it is subject to change. I decided to try a plugin.

public function dispatchLoopShutdown()
{
$registry = Zend_Registry::getInstance();
$msite_config = $registry->get('msite_config');
if($msite_config->cacheOn==1) {
if($registry->get('cacheable')) {
$body = $this->getResponse()->getBody();
$cache = $registry->get('cache');
$cache->pgSave($body);
}
}
}

If the configuration says to have the cache on AND I decide in the action that I want to cache it, it will be done automatically. I hash the URL to see if there is a cached copy of the page. If there is, I display it. It makes the logic fairly simple.

View Helpers

Veneer will offer a number of view helpers. They will all reside in Veneer/View/Helper. THe default module controller will automatically add the helper path. That is the Zend default behavior.

I think Pádraic Brady actually has a better way of doing it. I will be using that for helpers that require state instead of using the Maurice Fonk's way. It seems unnecessarily complex.

Layout

Veneer needed a way of theming the pages. You can use includes but that is a pain. There is a layout component in the Zend incubator. It seems to be working fine. A few bugs. I can't seem to change the view script. I have to use the default one.

http://svn.ralphschindler.com/repo/ZendFramework/Zend_Layout/library

The key is deciding on a good set of placeholders for all modules to use. As I build a few, I will create a list in the wiki. These will definitely change

Module/Theme Installation

The modules and themes are all in their own subdirectory. That should make for an easy installation of new modules and themes. I should be able to write a good install script.

The data for each module will be placed in directories associated by each site. This is sort of like the Drupal way. Another way to do it is like Symfony where the code is referred and each site is in it's own directory. I think that would require more control of the machine.

Veneer Routing

The thing about Zend is there are tons of different options for routing. I have no idea how a generic module system would work with multiple methods of routing. It is simpler to use the Conventional Modular Directory Structure.


/module/action/parameter1/parameter2/etc.
- the controller index is implied
/controller/module/action/parameter1/parameter2/etc.
- there are a limited number of possible controllers.

Controller options
All the controllers are derived from veneer controllers since they have similar functions.
Admin - The admin functions
API - a rest based programmable interface
Auto - No UI - batch jobs
Block - blocks for the layout.
Module - index

maybe more

Why YUI?

I decided to use YUI because I have more faith in Yahoo's testing for class A browsers. Yahoo hosts the CSS and Javascript so that works too. Yahoo is less likely to give up on it's libraries.

The examples are good too.

A new CMS is started

There are millions of CMS's. Why does the world need another?

The answer is that the world does not need another CMS. I need a CMS that will do what I want it to do. There may be a CMS that does exactly what I want it to do but it would probably take longer to find it than to write my own using Zend Framework.

The CMS is called Veneer because I am going to try to create a CMS with the minimum amount of code. The system will use Zend Framework, Yahoo UI components, and maybe Pear.

The only problem with using Zend Framework to write a CMS is the choices. Zend will do whatever you want. What I have done is reduce the number of options to a manageable number.

Design Goals
1) Less Code
2) Less database access
3) Module system - easy to extend
4) Easy to install

This blog will not be well thought out.
Blog early - Blog often
Release Early - Release Often