Andrew Rickmann wrote:
>
> I also think the idea of loading the CSS via a PHP file by default
> with any variables being replaced by their option values, or being
> removed, will add a great deal of flexibility without needing any PHP
> by the themer. For example: color: [[option1:#fff]]; would be replaced
> by whatever was in $theme->get_option('option1'), or by the default
> which is colon separated if there is nothing in the option.
I dislike the idea of pushing CSS through PHP every time, but it might
be useful to include some generic functionality in Habari that handles
"build caching". There is a module for Drupal called image_cache that
is quite clever in how it accomplishes this. I will attempt to explain
what it does in terms of providing dynamic CSS for Habari's themes.
Assume you have a cache directory at /user/build. The theme would
output the stylesheet URL as /user/build/style.css (for example). This
file does not yet exist in the directory.
Because the file does not exist, the request is routed through Habari.
Habari, using rewrite rules that catch requests to the build cache,
notes the request and builds the file. The file is served, but is also
saved into the correct location in the cache directory.
The result is that on the next request, the file exists. Apache sees
that the file exists and serves it directly instead of routing through
Habari. The file is served much faster because there is no PHP processing.
When a user updates options that affect the file, the file is
unlink()ed. The next request for the file rebuilds it.
There really isn't a need to use that one directory, but it would make
it easier to route requests. I imagine a rewrite rule that resolves to
a single hook, where the file that the request asks for is passed in.
Plugins/Themes that can resolve the file simply return it, and the
system takes care of putting the file where it belongs and managing
versioning. The plugin would call a specific function to clear a file
from the build cache. Also, some logic for versioning and appending a
querystring to the URL (like .../style.css?6) would be handled by the
system.
It sounds complicated, but it would make it all easier for the themer.
Also... Rather than developing a brand new syntax for the dynamic theme
bits, we could use HiEngine. HiEngine is already pretty close to the
syntax described, and wouldn't take much more effort to add a default
for a value that isn't set (something I was planning on doing anyway).
So the syntax would simply be this instead, if you were pulling it from
an option:
{hi:option:color1 default="#f00"}
Or if the theme settings were made available to this template via
standard variables:
{hi:color1 default="#f00"}
Either way, expanding the HiEngine seems much more productive than
writing another syntax just for this (which was also essentially my
comment on the wiki talk page for this Theme Configuration idea).
Owen
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
