Local Development & Site Exporter
2005.12.05 14:31
Local development with 'static' deployment may be Templation's future, at least for me. In many ways this kills the dynamic server-based development paradigm that I enjoyed while working with a dedicated web server on a LAN -- it's hard to justify localhosting when you have a short fat pipe right to the server. But with the advent of now living in the real world of high-latency high-load shared hosting and unreliable net connections, localhosting is bringing back the thrill of the instant page refresh. Better yet is the ability to have all my work on my laptop at all times, with or without a network.
If everything is now local, why run Templation on the server at all?
With Templation on your server site-wide tweaks are easily accomplished through a quick SSH or FTP connection. If you use version control software to maintain your site you can even merge changes from both your localhost and the server. Very convenient. On the other hand, getting Templation off the server improves site performance, and avoids a slew of possible issues with PHP in an environment you may not have much control over. Obviously there are tradeoffs either way, but the current functionality of Templation is not enough to give you a real choice.
The Site Exporter
Essentially the site exporter is a way of publishing the Templation cache. For smaller sites this is not too difficult to do by hand. As long as you only have one template mode you can just copy the files directly out of the cache replacing the Templation-driven files in a copy of the entire site structure.
But to automate this process is trickier. Above all it needs to be reliable. A lot of things that are possible to do in Templation would not be compatible with site exportation. In the current state of affairs I've simply put a bunch of warnings in the documentation and left you to your own devices. But is this good enough? For site exportation to become a viable reality, many issues have to be solved more formally:
- All pages must be built up front with a single command. The most reliable way to make sure every page gets built is to traverse the file structure locally and build each Templation-driven page.
- Template modes must be supported. I had planned on the exporter doing only one mode at a time but that's a copout. The tricky part is reliably determining all the possible template modes programmatically. The arbitrary nature of template modes makes them susceptible to subtle breakage. So the question is should template modes be crippled for the sake of stability? Or is better documentation and trust in the developer the way to go?
- Templation and site logic shouldn't be intermingled. Directly referencing Templation variables in source pages is a blatant example of something that would break horribly in a naive site exporter, but there are many more subtle ways in which a site export could fail.
- More debugging tools are necessary. Templation already suffers from a certain opacity, but with the aforementioned issues and perhaps a lengthy export process, developers will need ways to peer into the guts of the export in a more fine-grained fashion.
- Deployment methods. What use is a site exporter with a simple way to deploy the site? Although a version control system may solve the problem for me, a simple rsync solution would be faster and more generally useful.
