On Fri, Jul 18, 2008 at 2:38 PM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > On Fri, 2008-07-18 at 21:33 +0300, Sancar Saran wrote: >> And one thing. >> >> > (1). It is very convenient to pre-process static information at compile >> > time rather than on every request (specific properties, content chunks, >> > content relocation, etc). Additionally, it can compile to static HTML, >> >> One of my sites using 3rd party as data source (via xml). >> >> Their data may change any time, so we have to parse template files in each >> request. >> >> What is your suggestion ? > > I didn't say it had to be static. I said it can be either static or > dynamic. it can house modules, render module data, render arbitrary > data. Essentially you can make static what needs to be static and make > dynamic what needs to be dynamic. But the template engine isn't like how > smarty does things. My engine can produce a PHP file with appropriate > PHP code to load modules and render data at run-time. The difference is, > when this page is requested by the browser, the template engine is not > part of the run-time process. Only the modules are that produce the > dynamic data. Of course if you have no dynamic data, no modules need be > loaded (such as for CSS). In fact the PHP engine need not be loaded > either if it's a true static content file. > > Cheers, > Rob. I'd have to look into this to see if I really liked it or not. Is all of that part of your interjinn framework? It sounds like an interesting concept and is probably faster overall, but I'm always wary of generating executable php code. You just never know. Plus I am not a fan of any template syntax that isn't php. I like knowing any file I open will have straight php calls and not have to parse any meta languages I come up with. If there is a question about what is going on it is easy enough to look at any of my api calls or phpdoc to see what is going on. I've tried using stuff like that before and it just wasn't how I liked programming. More power to you though. The end goal is to push something out the door so everything else is just preference. :) In my code I always use MVC. People nitpick about how hard it is/overly complex but in the end all sites always have changing requirements. Past experience has shown me that it is easier in the long run. My controllers use table gateways & value objects to perform data access. Then the controller creates a view instance which pumps the data into it and calls render() on it. If I have something that I know is going to be intense I put the data caching directly into my gateway code. This way I always know where to look. (Of course there are always those nit-picky edge cases but let's ignore those! ;)) As for my js & css I have created a 2 step process. First I have a class called byte_Page. This page has 4 sub objects in it that allow me to build breadcrumbs, current page actions, inject css files, and inject js files. It does a bit more than that too, but you get the idea. I created it for having a consistent way of being able to have any piece of executing code be able to say I need X css or X javascript. This url then pipes to a file which basically stitches the files together. I needed that with the start of using the YUI files. On some of my more complex interfaces I was ending up shoving 10 different JS files down the wire which was just killing page performance. Those 10 rules for faster pages by the Yahoo performance group was really helpful. But like I said that is just how I like to do things. I just want to make the point that I'm not saying either is right or wrong. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
