[dev] [commits] Horde branch master updated. 89bca7f749db1780dca80363d6f3d8c89f899df4

[Michael M Slusarz]

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
>>>>> sound).
>>>>>
>>>>> 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  
framework/bin/install_dev).

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  
distribution files

* 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

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]