Re: Var Templates

Tom: I'm not trying to give you a beating!! I AM arguing against the shoe-horning problem I mentioned in my first post. I think the fact that you have to work so hard for it means either it is such an excellent idea that you have to beat it into our heads before we "get it" or otherwise we do get it but disagree with you on its need. I think I fall into the latter category, but I am willing to be shown the light, so to speak. I checked your actual suggested problem and you have to admit that that is EXACTLY the type of thing that config files are NOT meant to handle but which templates ARE meant to handle. Indeed, you have a situation that begs for a smarty assigned variable from PHP. You certainly haven't said why you can't use straight PHP for your problem except that you have legacy code; however, since you are arguing for functionality that doesn't exist yet, your code can't possibly be affected! > Then why do we even need to have a config file class? Indeed. You may have noticed that I'm not really a big fan of config files. That is because they require a seperate class for access, are not compiled, and then require a very different syntax to access their variables from within templates. Furthermore, as you argument rallies against, they are completely static (which can also be argued as a virtue). That's why I've been leaning towards suggestions that attempt to unify config files with templates. You would get what you need and the core could concievably be made smaller and more consistent with the elimination of config files. I really worry that the opposite would happen if your suggestion is accepted: additional template features creeping into config files. After all, it is just as reasonable to want if/then logic in config files if you are expanding vars. So too for every other construct that templates offer. Yuch. Perhaps there are other ways this can be addressed, for example, with a new template block {config}{/config}. This block can be made to work just like config files except, as a template function, would also permit for standard template functionality. Or perhaps the existing inline {php} in templates is sufficient (yuch). Let me ask this: why do you think your suggestion is a good thing to have in the current config file versus using ANY of the styles I suggested? I mean, other than the fact that you already have a design choice in mind. This is not a great answer to you, but sometimes it is just as easy to change the design of your code as it is to say that your code won't work because Smarty doesn't do such and such. xo boots PS. By I disagree that using templates to assign vars (via eval) is any more expensive than config files; however, straight PHP is the least expensive thing you can do here and probably the most "correct", whatever that means. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com