[geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17

[Joe Mucchiello]

At 10:53 PM 1/20/2008, Blaine Lang wrote:
>Joe Mucchiello wrote:
> > So you could have a series of similar config settings with the 
> same options not clutter the system with a bunch of duplicate 
> functions. For example, if for some reason you needed to store 
> dates in the configuration, there's no reason to have more than one 
> function that displays dates.
>
>Create a function stub for those fields and call a common date 
>format function. I'd rather not have to create a new config option 
>type which appears to be more restrictive. I don't expect most 
>plugin config options will need these extra functions.

I don't know how to respond to this. How is what I wrote "more 
restrictive"? Heck, I suggested having configmanager_type_$type AND 
configmanager_field_$fieldname.

I write APIs for a living. I try to make them as flexible as 
possible. I'm trying to look ahead of the current issue to find a 
solution that not only solves the immediate need but will solve 
problems we don't know we have now. That means having extra stuff 
that you don't need now. We don't need a display option now. Maybe we 
will. Most web stuff has three states to_display, to_editor and 
to_database. Just because the config screen is locked in edit mode 
now doesn't mean it will always be that way. Using mode as a 
parameter if over time its meaning changes (will preprocess always be 
what we are doing?) we can change the mode to move with the new 
paradigm. If the function contains "preprocess" in it, we have less 
flexibility.

This is just like the templatesetvars issue. It works passably but it 
could be so much better.

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com