[dev] [commits] Horde branch master updated. 89bca7f749db1780dca80363d6f3d8c89f899df4
Michael M Slusarz
slusarz at horde.org
Fri Mar 12 21:46:47 UTC 2010
Quoting Chuck Hagenbuch <chuck at horde.org>:
> Quoting Jan Schneider <jan at horde.org>:
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>> Quoting Jan Schneider <jan at horde.org>:
>>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>>> commit 97fd203dcaaf5ddf7c9c2252eb44ac76e8d84846
>>>>> Author: Michael M Slusarz <slusarz at curecanti.org>
>>>>> Date: Sun Mar 7 20:15:31 2010 -0700
>>>>> Add Horde_Themes:: library.
>>>>> Move all themes related code to a single place (includes both image and
>>>>> Horde::img(), through Horde_Themes::img(), will now attempt to auto
>>>>> determine a graphic location. It looks in the following directories with
>>>>> this priority:
>>>>> 1. App theme
>>>>> 2. Horde theme
>>>>> 3. App default
>>>>> 4. Horde default
>>>>> This prevents us from having to copy all over all graphics for a theme -
>>>>> now, only need the graphics that differ from defaults (caveat: if
>>>>> loading graphics from CSS, copies of graphics need to continue to live
>>>>> in theme directory).
Processing the feedback, how about this solution:
1.) Require all applications to contain all graphics they need. Would
simplify a bunch of code and would allow all graphics to eventually be
able to be loaded via CSS.
2.) For themes that want to override the default graphics, require a
themed_graphics.php file. This file would contain a list of graphics
that override the default graphics, e.g.
$override = array(
'graphic1' => 1,
'graphic2' => 1
This file could easily be auto-generated via a script (most likely
using RecursiveIteratorIterator/RecursiveDirectoryIterator - see
This, to me, provides a cleaner solution than the 'themed_graphics'
empty file for a variety of reasons:
* To me, it *is* annoying to make sure that all default graphics are
copied over to a theme. This increases maintenance costs - to add a
graphic to an application, a developer must remember to copy this
graphic over to ALL themes or else each theme with graphics will be
broken. With the new technique, themes will continue to work if a new
graphic is added. (albeit with the default, non-themed graphics).
Thus, maintenance of a theme falls on the theme creator/maintainer
rather than a developer.
This is even a stronger argument when thinking about a
locally-maintained theme and updating an application. If updating
from Foo 1.0 to Foo 1.0.1, and Foo 1.0.1 adds several new graphics,
the locally-maintained theme will ALWAYS break and there's nothing we
(as Horde developers) can do about this. This isn't an issue with the
new theme - the local admin can determine at their leisure whether
they need to introduce a new graphic. This will often be the case
because 1) Horde app updates might be time-critical to fix security
issues and 2) it may take awhile to locate/design/tweak a graphic to
fit into a theme.
* As mentioned previously, this method makes it easier to determine
which graphics are being overridden.
* Granted it is a minor point, but it does reduce the size of
* PHP overhead is minimal - this method requires only that a simple
PHP array be parsed/read into memory.
* This is the only practical way of allowing view-specific portions of
a theme (i.e. dimp theme) to override the defaults. For example,
maybe we want a smaller/different graphic to be displayed when viewing
mimp. We also want this graphic to be used regardless of the theme.
This new method would allow the mimp view to override a default
graphic. This isn't possible with the old method.
Michael Slusarz [slusarz at horde.org]
More information about the dev