config_load / Config_File and other small details

Hi all. -------- On a nit-picking note, the Config_File class has not been updated to reflect the new global use of DIRECTORY_SEPARATOR and instead still uses an internal representation. Worse, the constructor assumes either the literal "\\" or "/" depending on a version & file system check. -------- On a its-just-me note, in the Smarty class, the comment that was added prior to the line: var $php_handling = SMARTY_PHP_PASSTHRU; includes this line: * This determines how Smarty handles "<?php ... ?>" tags in templates. I know its correct, but the ?> breaks the syntax highlighter in my IDE. Can it please be changed to ? > or &gt; ? (for html mail readers: thats & gt ; with no spaces) -------- I've been working with messju's changes to the config_load plugin (in CVS) and I have some issues with the interaction it has with the Config_File class (or any class that it ends up calling). Basically, the problem is that while the config_load is passed a $smarty reference, the reference is not handed off to the Config_Load class. Another point is that config_load assumes a single type of configuration file class--so once a class is initialized, it will not try to initialize an object for a differing class. To get around these limitations, I added the following: $_class = isset($params['class']) ? $params['class'] : $smarty->config_class; This adds support for an optional class parameter. I know, I know, but it is a temporary solution! Object creation becomes: if($_compile_config) { if(!is_object($smarty->_conf_obj) || get_class($smarty->_conf_obj) != strtolower(_$class)) { require_once SMARTY_DIR . $_class . '.class.php'; $smarty->_conf_obj = new $_class($_config_dir); [... snip unchanged code ...] } if(method_exists($smarty->_conf_obj, 'set_interface')) { $iface = array('smarty'=>&$smarty, 'assign'=>$_assign, 'cache_id'=>$_cache_id, 'compiler_id'=>$_compiler_id); $smarty->_conf_obj->set_interface($iface); } Those additional items--assign, cache_id, etc.--are for my private class, so I won't describe them here. My custom config classes (descended from Config_File) implement a set_interface($iface=array()) function. I pass the interface as an array for the same reasons that custom functions are passed a params array--not every config class will require the same interface. I don't really like this :). Are there objections to passing an interface array to the constructor? ie. $smarty->_conf_obj = new $_class($iface); $_config_dir would be packed into the $iface array by default. a reference to $smarty can be included, if required, or for consistency: $smarty->_conf_obj = new $_class($smarty, $iface); Or can someone suggest a different technique? I think the problem is that Config_File should actually be a static interface (yes, Monte, that was me :) -- I'll take the heat) with all the data structures it requires being handed to it. In particular, the fact that it mixes file handling, parsing and internal data storage and access seems wrong. Especially since the Smarty and Compiler classes still have embedded config var code (ie. there is not full separation). Some of this would go away if resources were used everywhere and not just for templates. (I really mean EVERYWHERE, including the cache/compiler units) xo boots @Monte: I just downloaded the new CVS changes you made. If I have some time I will benchmark the new core handling (I like "core", I would have chosen that too) against the current handling and also against a class of static methods. I'm glad you extracted the assign_smarty_interface because I have it in my mind that it does too much by simply aggregating the PHP vars into the _smarty_vars. I think that it should delegate reads to the PHP structures or even better, lazy load them as required. As it is, I think that too much is being passed (and made available) to the templates. (Alternatively, template calls to Smarty vars (at least the GPCSE's) can compile directly to PHP calls instead of lookups in _smarty_vars.) __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com