Correct me if I am wrong, but wasn't there a few PHP code generators that did what the OP is asking? I remember hearing about Code Generation a few years ago, but that has been about it. On Fri, Apr 10, 2009 at 9:48 AM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > On Fri, Apr 10, 2009 at 09:01:14AM -0400, Bob McConnell wrote: > >> From: Paul M Foster >> > >> > Here's a hairbrained idea I was kicking around. I object to the idea >> of >> > including 15 or 30 files in a PHP application just to display one page >> > on the internet. It makes the coding faster, but it makes the display >> > slower and seems silly to me. >> > >> > So what if you had a tool or a set of tools where you could write code >> > snippets and such, and then hit a button or issue a command, and >> > everything you specified got written into a single file? You'd specify >> > that this page needs to read the config, set up a database connection, >> > validate these fields, etc. When you were done, it would write all >> this >> > code to a *single* file, which the user would invoke by surfing to >> that >> > page. The resulting code would be *static*, not like what results from >> > most templating systems. So rather than specify a specific variable >> > value in the resulting file, it would embed the PHP code to display >> the >> > variable, etc. >> > >> > What might be the liabilities of something like that? Would there be >> > security issues? Would there be increased difficulty in debugging? >> What >> > can you think of? >> >> Programs to do that used to be called compilers. There is an entire >> branch of computer science and a lot of tools (lex, yacc, etc.) >> dedicated to that topic. > > I know compilers. I've coded in C for years. I'm not talking about a > compiler here. It's more an "aggregator". The resulting page would still > be php/html, but everything needed in it would be self-contained (except > the web server and PHP interpreter). Kind of like what "make" does, > except that make typically invokes the compiler to mash it all into one > executable at the end. > >> >> It's not a bad idea, but there is one precarious assumption that >> underlies it. Can you absolutely guarantee there will never be a second, >> or third, or more pages on that server that will need some of those >> functions or classes? As soon as the site begins to evolve and grow, you >> will have multiple copies of many of those snippets, and when (not if) >> you need to modify them, you will have to find and change every single >> copy. >> >> So you need to ask yourself if this strategy is maintainable in your >> case. And will it make any real difference in the end? >> > > Good point. That's why I asked the question in the first place. Every > time you revised a supporting file, you'd have to regenerate all the > files that depended on it. Might be okay for a small site, but could be > a nightmare for a large site. > > Paul > > -- > Paul M. Foster > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Leonard Burton, N9URK http://www.jiffyslides.com service@xxxxxxxxxxxxxxx leonardburton@xxxxxxxxx "The prolonged evacuation would have dramatically affected the survivability of the occupants." -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
