RE: [SMARTY-DEV] Re: Compiling config files & alternative config files format

I'd love to do it if I had the time, but I won't have the time until the end of this month. I already have some changes that I have made to the resource plugins (outlined in previous mails and postings). But they are not directly related to the config file loading. The thing is, they do make various things involving the compile id easier to deal with. I'll forward my modified smarty.class.php to Monte, along with an example of a "new-style" resource plugin that demonstrates the features of my changes. Maybe they'll be useful to whoever ends up implementing the config loading changes. I'd make a diff and send that, but I'm working from an older version of smarty, so a diff would be confusing, and only marginally useful, and I don't have time to re-make my changes in the CVS tree right now. ...sorry about that. If no one else wants to make the config-loading changes, I'll be glad to take it on beginning in January, along with some other changes that I've been wanting to make to smarty. :-) -lee > -----Original Message----- > From: Monte Ohrt [mailto:monte@ispi.net] > Sent: Tuesday, December 03, 2002 4:36 PM > To: Lee Coltrane > Cc: bdunogier@wanadoo.fr; André Rabold; smarty-dev@lists.php.net > Subject: RE: [SMARTY-DEV] Re: Compiling config files & alternative > config files format > > > Sounds like a good idea to me. The resource plugins have been > mentioned > before I think, but nothing acted upon. > > So the compiled config file would hold the array that currently gets > assembled on the initial config_load call for each config file. I > suppose you'll want compile ids for these config files too, > so separate > compiled files per language, etc. Secondary features would be resource > plugins and different file formats. > > So anyone up for the challenge? :-) > > On Tue, 2002-12-03 at 15:16, Lee Coltrane wrote: > > Rather than compiling the config files directly into the > compiled smarty > > template file, why not compile each config file to its own > php file (say... > > "filename.scfg.php", in the compile_dir), and just include > them from the > > compiled template file, recompiling them first if necessary? > > > > To do this, you would just provide a function on the smarty object, > > $smarty->loadConfig( $filename ). This function would be > called from the > > compiled template when it is time to load a config file (call it as > > $this->loadConfig( '<filename>' )). The loadConfig > function, then would > > check the timestamp of the config source against the > timestamp of the > > compiled config file (if any), do the recompile if > necessary, then include > > the config file using ( > require_once('<compiled-config-filename>') ). > > > > I think this would solve the re-compile issue that you've > been discussing. > > You'd still incur the overhead of including a php file, and > executing the > > php source, but you'd bypass the overhead of parsing a text > file - which is > > probably the most time-consuming task. I don't know, but I > bet this could > > be done without breaking the existing interface as well. > > > > In addition, the loadConfig function could use a file > extension to determine > > the expected type of the source file, and thus which ConfigCompiler > > implementation should be used. This decision would only > have to be made > > when a config file required recompile - all compiled > configs would look the > > same to smarty. > > > > While you're at it...what do you think about upfitting the > config loading > > process to be capable of using resource plugins? It would > be very useful (I > > think). > > > > good luck, > > -Lee > > > > > -----Original Message----- > > > From: Monte Ohrt [mailto:monte@ispi.net] > > > Sent: Tuesday, December 03, 2002 9:19 AM > > > To: bdunogier@wanadoo.fr > > > Cc: André Rabold; smarty-dev@lists.php.net > > > Subject: Re: [SMARTY-DEV] Re: Compiling config files & alternative > > > config files format > > > > > > > > > Compiling the config vars statically could be done, there > is just a > > > level of complexity with recompiling. Currently, only the > > > timestamp from > > > the original template is tested. Since config vars can be > > > used from any > > > parent or child template, you'd have to track the whole > heirarchy of > > > config files to test if something changed. Smarty's caching > > > already does > > > this btw, so use caching when possible. > > > > > > Monte > > > > > > On Tue, 2002-12-03 at 02:51, Bertrand DUNOGIER wrote: > > > > AR> not all people do install PHP with expat XML parser and > > > there are some > > > > AR> web space providers which don't use it too. So you > > > would need to implement > > > > AR> your own XML parser which is definitly too slow > > > > AR> (http://sourceforge.net/projects/phpxd > > > > AR> for example is really great). > > > > AR> I don't think it's a good idea to use XML exclusively > > > but perhaps as an > > > > AR> alternative format. > > > > AR> So the developer could choose if he want's XML or Plaintext. > > > > Yes, it's what i think too. > > > > > > > > Many hosts run expat, and when you run a professionnal > > > projet, you can choose > > > > the modules you're using. > > > > > > > > Since Config_File.class.php does not look complex, it > > > might be easy to write an > > > > alternative config file parser that could load the config > > > vars from an XML file. > > > > A SQL datasource could be handy too :) > > > > > > > > I'm waiting for a comment from Andrei or Monte regarding > > > the caching. > > > > > > > > Bertrand > > > -- > > > Monte Ohrt <monte@ispi.net> > > > > > > > > > -- > > > Smarty Development Mailing List (http://smarty.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > Monte Ohrt <monte@ispi.net> > > > -- > Smarty Development Mailing List (http://smarty.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >