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

[Chuck Hagenbuch]

Quoting Michael M Slusarz <slusarz at horde.org>:

> 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.

Definitely agree here.

> 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.

I'm still not entirely convinced on not copying graphics into themes,  
but I'm okay with this method overall and your last argument is  
particularly convincing.

-chuck