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

[Joe Mucchiello]

At 05:05 PM 1/20/2008, Blaine Lang wrote:
>Dirk,
>
>I was wondering why we need a new config type and not just check for 
>the existance of a configmanager_fieldname function?

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.

Of course, one could say having both is most flexible. Have 
configmanager_type_$type for new classes of data and have 
configmanager_field_$fieldname for specific fields that need special 
processing. But my example below assumes there are just "types".

>I was thinking we need to check for a function to feed the values to 
>a config parm as well as validate upon save. The validate function 
>could do any post processing like convert days to seconds (if a 
>field wanted to present a update frequency in days and field needed 
>to be saved as seconds).
>
>configmanager_fieldname_preprocess() and configmanager_fieldname_postprocess()

Why spend time call function_exists more than once? What happens when 
preprocess and postprocess aren't enough? And they aren't, there 
should be three state: to_display, to_edit, and to_save. Arguably 
there could be a 4th state: to_validate called before save but they 
can be combined.

function configmanager_type_$type($config_object, $mode, $param, $extra = null)

$config_object is the config object instance.
$mode could be 'display', 'edit', 'save'.
$param is the database entry for the item.
$extra depends on the mode. At the moment only save would use it. 
Save uses it to hold the $_POST array of the field list received 
during "edit" mode.

That should be infinitely extensible.

Return is always an array. A return of false means the function does 
not process that mode. (Returning an array means the returns can also 
be extensible.)
Return for display mode is HTML text for displaying the current value.
Return for edit mode is a map: 'html' => $html_text, 'fields' => 
array of fields where html_text is <input name="$html_field".... Thus 
you could store a date in the config using one database field but on 
screen, there are 3 controls.
Return for save mode is the value to store in the database (before 
any serialize/addslashes).

function configmanager_type_date($config, $mode, $param, $extra = null)
{
     switch ($mode) {
     case 'display':
         list($date,$stamp) = COM_getUserDateTimeFormat($param['value']);
         return Array('value' => $date);
     case 'edit':
         return  Array(
            'fields' => Array($param['name'].'_month', 
$param['name'].'_day', $param['name'].'_year'),
            'html' => "<select name=\"{$param['name']}_month\">"
                     .COM_getMonthFormOptions(date('m',$param['value']))
                     ."</select> / <select name=\"{$param['name']}_day\">"
                     .COM_getDayFormOptions(date('d',$param['value']))
                     ."</select> / <select name=\"{$param['name']}_year\">"
                     .COM_getYearFormOptions(date('Y',$param['value']))
                     ."</select>"
            );
     case 'save':
         $month = COM_applyFilter($extra[$param['name'].'_month'], true);
         $day = COM_applyFilter($extra[$param['name'].'_day'], true);
         $year = COM_applyFilter($extra[$param['name'].'_year'], true);
         return Array('value' => mktime(0,0,0,$month, $day, $year));
     }
     return false;
}

Other potential modes could be stuff like "default_value". For a date 
field, default might always be "today".

>>Is the function name okay or should it start with "CONF_" instead? Any
>>room for improvements?

I prefer user callback functions to have the long names like plugin_ 
and phpblock_ whereas API functions should have short names like 
PLG_, COM_, SEC_

>>bye, Dirk
>>
>>
>>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://eight.pairlist.net/mailman/listinfo/geeklog-devel

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