Re: A Tool For Building PHP Web Apps
| From: | Leonard Burton | Date: | Fri, 10 Apr 2009 13:56:11 +0000 |
| Subject: | Re: A Tool For Building PHP Web Apps | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-291337@lists.php.net to get a copy of this message | ||
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@quillandmouse.com> 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@jiffyslides.com
leonardburton@gmail.com
"The prolonged evacuation would have dramatically affected the
survivability of the occupants."