-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Owen Winkler wrote:
> 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
>
>
My concern is for themers like me who are most comfortable working
directly in PHP and CSS. Requiring themers to learn a new "language" to
take advantage of the configuration options seems a disservice and will
also, I think, discourage development of additional theme engines,
which, in turn, will discourage themers who use other engines from
sharing their skill with Habari.
I have no problem with making taking advantage of all of our options
require more effort, but at the same time, where we can make things
easier we should try to do so. By all means, making the HI Engine the
easiest to use is great, but at the same time we shouldn't make any
features exclusive to it.
Perhaps the answer is to use the cached file as described by Owen, and
take advantage of the Cascade to allow it to override the theme's CSS
with no actual changes to what needs to happen in the standard .css file.
- --
Sean T. Evans
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkn1vHoACgkQmQpMBUWJpdtOxQCgtqKDdYvWH9eNb3Wcwn4CKI3V
zrQAnAqtlaqKoQU+TJhj3mS2qhjJMBMX
=CqrY
-----END PGP SIGNATURE-----
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
