Re: [PHP] A Tool For Building PHP Web Apps
Maybe this can help: http://www.intorel.com/index.php?page=ActiveSiteCompiler-default_asp --- On Fri, 4/10/09, Paul M Foster wrote: > From: Paul M Foster > Subject: [PHP] A Tool For Building PHP Web Apps > To: php-general@lists.php.net > Date: Friday, April 10, 2009, 1:28 AM > 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? > > Paul > > -- > Paul M. Foster > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Tool For Building PHP Web Apps
2009/4/10 Marcus Gnaß : > Paul M Foster 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 >> >> > > You could try to substitute all your calls to include() or require() with > SSI-includes and let your webserver do the aggregation then. > > I read an article about retrieving the webservers result after performing > SSI actions but before handing this over to the application server, but I > can't remember where ... > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I guess using caching would be better. It would resolve the issues of loosing so much time including all the files you need and it doesn't waste more time than installing the opcode cache and setting it up. I'm quite happy with apc, it boosts up the speed a lot! It even has an option to optimize the require_once and include_once function calls. Though I don't really know what it does. -- Currently developing a browsergame... http://www.p-game.de Trade - Expand - Fight Follow me on twitter! http://twitter.com/moortier -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Tool For Building PHP Web Apps
Paul M Foster 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 You could try to substitute all your calls to include() or require() with SSI-includes and let your webserver do the aggregation then. I read an article about retrieving the webservers result after performing SSI actions but before handing this over to the application server, but I can't remember where ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Tool For Building PHP Web Apps
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 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 serv...@jiffyslides.com leonardbur...@gmail.com "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
Re: [PHP] A Tool For Building PHP Web Apps
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
RE: [PHP] A Tool For Building PHP Web Apps
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. 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? Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Tool For Building PHP Web Apps
Roadsend is very beta when I last checked and while promising seemed to be geared more towards taking php and moving it to the desktop without using gtk. I could see the uses but I think adobe air fits that model better with less to worry about. Personally, I am leaning more and more towards using php to build XSLTs and just passing the data via XML. It fits nicely with the mvc framework models and reduces the view code dramatically. Sorry for top posting Bastien Sent from my iPod On Apr 10, 2009, at 1:32, Asher Snyder wrote: This might be what you're looking for: http://www.roadsend.com/home/index.php -Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: Friday, April 10, 2009 1:28 AM To: php-general@lists.php.net Subject: [PHP] A Tool For Building PHP Web Apps 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? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] A Tool For Building PHP Web Apps
This might be what you're looking for: http://www.roadsend.com/home/index.php -Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: Friday, April 10, 2009 1:28 AM To: php-general@lists.php.net Subject: [PHP] A Tool For Building PHP Web Apps 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? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
