- individual stylesheets are applied to a page
- Client-side script can be added
- Metadata such a description and keywords
Tuesday, 13 May 2008
Sunday, 4 May 2008
include. So why can't we make a master XSLT template file which doesn't transform any XML itself, but simply matches the document root to apply its template only once, but then crucially providing a placeholder for an imported stylesheet in the right place. This would allow me to use it as a 'master view' which is combined with the view my controller action renders.
There is however, a few problems. Whereas now my view renders whatever XML its passed using a single stylesheet, it now has to use the master stylesheet, but the master itself has to be aware of which view-specific stylesheet to include. This is getting a bit too much like a template language – replacing strings in the master template file with a path to the view specific stylesheet, and that's what I'm trying to avoid. The other problem is with CSS. Putting persistant navigation in the master stylesheet is fine, but what happens when you want to change the CSS class of one of the link elements? You have no hook to the master from the view specific stylesheet. I thought about having the navigation as its own XML file – easily editable and adaptable. Then view scripts can be used to change that nav XML, marking which link should have a CSS class of "current" and combining it with any data XML the view has received assuming there and some mechanisms are in place for the master stylesheet to find those flags, and produce the right XHTML output. Perhaps xml namespaces are the right way to go here, in order to differentiate between nav and content XML. Ideally, minimising the number of transforms is a good idea, so I don't want to have to transform the nav XML data, then use another template to transform that result to the final output including the actual content. The content XML and nav XML could be combined just before XSLT processing. It would be simple to wrap content XML from the model with persistent data. But the problem still remains to tell the master stylesheet which view specific stylesheet to include in order to render it correctly.
Saturday, 3 May 2008
If you have XML data that you need displayed, turn off automatic view rendering within you bootstrap file with
This gives you more control over how Zend renders views. Then, in your controller action , create a new view and assign some variable from you application logic. You need to tell the view where the script is to execute. You do this using
$view->setScriptPath('...');. Once this points to the right directory, you can add a script in there you want the view to run. You do this by calling the
render method of the view instance you create, passing it a single string parameter as the script you want it to run. As the contents of the script is returned, the whole thing needs to either be
Within the view script, print anything you want to be rendered on the page. So here you can pair up the xml data passed from the controller action using
$this and an XSLT stylesheets you want to transform.
Brilliant hey? I sort of get this stuff.
Friday, 2 May 2008
Zend currently uses the Pear library to do stuff with DBs. Whereas installing this library may be fine, you might not have access to the server to install more stuff. Instead, follow this article about Adding adapters to Zend which allow it to use PHP. Alternatively, get the latest source files here and put the
Php directory within
Zend/Db/Adapter/. It works a treat, just remember to set the connection type to
php_mysql as opposed to
None of this is my own work. It all belongs to David Coallier (email@example.com) and his blog http://blog.agoraproduction.com. Awesome job, thanks.
Apparently, some servers require
FollowSymLinks to be turned on. If mod_rewrite is refusing to work and just denying all access (particularly important when trying to implement MVC with a bootstrap file) try including this in the
Ok, I'm getting there. I know know a bit more about Apache's VirtualHost directive:
This gives an absolute path to the directory where your web files will be served from. It can be anything you want.
This says, for a given directory (and it says which in particular with the path)
AllowOverride which allows me to use
.htacess files in that folder. Not too sure what
Options does yet.
The other cool bit is this line:
php_value include_path .:/var/www/phpweb20/include:/usr/local/lib/pear
This tells the PHP module in Apache where to look for include files. Pretty handy.