View previous topic :: View next topic |
Author |
Message |
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Sat Apr 26, 2003 3:59 pm Post subject: |
|
|
awesome... hang in there |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Sun Apr 27, 2003 4:34 am Post subject: |
|
|
Tom: If you are interested in testing it, let me know. It is usable as is, though I can still improve upon it. It still requires modifications to more than just the config_load plugin, so I'm hesitant to post it right now, but I'd be glad to hear how it works out.
I've been meaning to bench it, but I probably won't bother until it is somewhere near finalized. So far, it is certainly within my expectations as far as speed, though I can think of ways in which it can be terribly abused.
Sadly, I'm not familiar enough with the CVS / Diff tools to make sharing with others straightforward enough for me yet. I've been using Torotoise as a CVS client on my Win2K box, though I've also tepidly tinkered with the command line tools using my trusty Cygwin. It doesn't really seem to matter how much I try to learn, there is always something that I'm trying to do in which I'm simply a banal newbie. |
|
Back to top |
|
aloner Smarty Rookie
Joined: 24 Apr 2003 Posts: 24
|
Posted: Sun Apr 27, 2003 8:36 am Post subject: |
|
|
There is function 'make patch' in TortoiseCVS - it will produce patchfile against CVS repository - then just post the patch somewhere. _________________ Your ad here. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Sun Apr 27, 2003 2:55 pm Post subject: |
|
|
aloner: thanks. Looks nifty, but how does one apply the patch back?
UPDATE:
I'm at the stage where I'm happy with it for now. Only very modest changes were required. There are 3 files that make up the patch:
* Config_TemplateFile.class.php (extends Config_File)
* plugins/function.config_load.php (should be fully BC to config_load)
* plugins/resource.config_dir.php (loads templates from config file dir)
- plugins/function.config_load.php is the only file to get touched and again, there are few changes needed.
- The resource plugin is used internally by Config_TemplateFile -- not intended to be used from templates directly.
- Optional dynamic selection of config class via class parameter or defaults to $smarty->config_class.
- Optional cache_id and compile_id parameters support templated config files
A side-effect is that output of config files are cached per cache_id (which is neat, but perhaps someone may not want config info showing up in their cache dirs?)
Quote: | Templated config file example
Called template uses $nick as cache_id, while config file does not use a cache_id (like a 'global' config file).
config_TemplateFile_test.php
Code: | $smarty = new Smarty;
$smarty->caching = True;
$nick = 'ishmael';
$smarty->assign('nick', $nick);
$smarty->display('config_test.tpl', $nick); |
config_tpl.ini
Code: | callme = "Call me {$nick}, please!<br/>" |
config_test.tpl
Code: | {config_load file="config_tpl.ini" class=Config_TemplateFile}
{#callme#} |
OUTPUT
Quote: | Call me ishmael, please! |
|
Quote: | Templated config file with cache control example
Called template and config file use same cache_id (like private config files). Can be mixed and matched for various purposes.
config_TemplateFile_test.php
Code: | $smarty = new Smarty;
$smarty->config_class = 'Config_TemplateFile';
$smarty->caching = True;
$nick = 'boots';
$smarty->assign('nick', $nick);
$smarty->assign('cache_id', $nick);
$smarty->display('config_test.tpl', $nick); |
config_tpl.ini
Code: | callme = "Call me {$nick}, please!<br/>" |
config_test.tpl
Code: | {config_load file="config_tpl.ini" cache_id=$cache_id}
{#callme#} |
OUTPUT
Quote: | Call me boots, please! |
|
Quote: | Default config file example
Plain old config_file handling.
config_TemplateFile_test.php
Code: | $smarty = new Smarty;
$smarty->assign('nick', 'in the evening');
$smarty->display('config_test.tpl'); |
config_tpl.ini
Code: | callme = "Call me {$nick}, please!<br/>" |
config_test.tpl
Code: | {config_load file="config_tpl.ini"}
{#callme#} |
OUTPUT
Quote: | Call me {$nick}, please! |
|
|
|
Back to top |
|
aloner Smarty Rookie
Joined: 24 Apr 2003 Posts: 24
|
Posted: Sun Apr 27, 2003 3:38 pm Post subject: |
|
|
> how does one apply the patch back?
It can be done with GNU 'patch' utility from Cygwin or almost any Unix installation.
Also there are some Windows programs for this, however i don't know about them much. _________________ Your ad here. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Mon Apr 28, 2003 8:25 am Post subject: |
|
|
aloner wrote: | It can be done with GNU 'patch' utility |
Very cool! Thank you!
I will post something up at the dev list soon. I'm just dealing with some final issues and writing some simple docs, tests and examples.
There are some tricky issues with caches and compiling--it got my head swimming but I think I'm back on calmer waters now.
For the heck of it, I also added a hack to allow config files to optionally assign into _tpl_var space intead of _config_var space. Its not elegant nor is it 100% BC with the default handling, but I like it. It would be more meaningful if ## parsing could be turned off (or replaced with custom handlers) in the core.
At any-rate, I think the new architecture for config file handling is pretty cool and allows for some interesting customizations. After working with it, my feeling is that it is still not 100% there as I had to do a couple of hacky things that I am not happy about to get things working in a satisfactory way. That could be me and my lack of sleep, though
Last edited by boots on Sat May 24, 2003 7:28 am; edited 1 time in total |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri May 09, 2003 10:20 pm Post subject: |
|
|
@TOM:
I've now implemented this using at least three different techniques. I want to finalize one of them so that I can post it. What I want to know is how you think this should work. Do you want in use activation, multiple compiled entities or a one-time fits all?
ie.
in use: {#myvar#} -- myvar is expanded at runtime... (this would be the same as eval'ing, so I don't think you want this)
multiple compile: you have the opportunity of marking each config_load with a unique compile id giving you multiple "versions" of your config file. Only the last loaded config file is active at any given time.
one-time fits all: when the config file is compiled, it is compiled with the active _tpl_vars. Changing a var will not change the results of a config file once it is compiled.
Or if you have another scenario, let me know. I've been sitting on the code for a long time and I know you want something, so just speak up! |
|
Back to top |
|
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri May 09, 2003 10:30 pm Post subject: |
|
|
one-time fits all......
Would it not be possible just to check for "\$[a-z]" when a config var is _displayed_...
Sort of like a simple eval.
I sort of see this as simply treating config vars like any normal template var, but static in the sense that it's content cannot be reassigned but stil contain embedded variables. Constants with variable elements.. lol
another idea would be to perhaps do a <?php echo eval_config($this->_config_vars['foo']) ?>
I'm not sure... I'm really looking forward to seeing if this works seemlessly |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri May 09, 2003 10:45 pm Post subject: |
|
|
Quote: | another idea would be to perhaps do a <?php echo eval_config($this->_config_vars['foo']) ?> |
The problem is that it would greatly affect your performance in comparison to normal config vars. The other options would compile results directly into your compiled template but are a bit more confusing in use.
Perhaps I will post two versions |
|
Back to top |
|
|