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

[Jan Schneider]

Zitat von Chuck Hagenbuch <chuck at horde.org>:

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

Me too.

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

But shouldn't we make it easier rather than harder for designers to  
create a new theme? At the moment all they have to do is to copy the  
graphics directory and then start overwriting the icons one by one as  
they go ahead with their theme.

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

I agree that this a good argument, though I wonder why this would be  
necessary. Are the app views picking the icons by some automagical  
method? AFAIC the app views are using different view, even different  
controllers, and that's the place where the icons are included anyway.  
So they don't have to rely on some theme-loading magic to insert the  
right icon, they can simply point to the correct one.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/