#32436 [NEW]: 'phpx' making a first class scripting language (default way to drop <?php ?>)
| From: | sam_bravard at yahoo dot com | Date: | Wed, 23 Mar 2005 21:23:03 +0000 |
| Subject: | #32436 [NEW]: 'phpx' making a first class scripting language (default way to drop <?php ?>) | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-75770@lists.php.net to get a copy of this message | ||
From: sam_bravard at yahoo dot com
Operating system:
PHP version: 5.0.3
PHP Bug Type: Feature/Change Request
Bug description: 'phpx' making a first class scripting language (default way to drop
<?php ?>)
Description:
------------
I think it's time PHP had a default way to run PHP files without having to
wrap them in <?php ?> tags.
PHP5 is really a great general purpose scripting language. It would be
great that 'out of the box' it started acting like a real scripting
language and leave it's need of wrapper page tags and the output side
effects behind.
Thoughts:
*) Create a new 'phpx' (other name?) command line tool that will default
to not needing page tags.
- or change the default behavior of the 'php' command to accept files
without enclosed '<?php ?>' and make a command line option to allow it.
But this will break existing code, so 'phpx' seems like a better choice.
*) Add a new 'phpx' httpd mime-type handler that processes php files as
pure code without the wrapper tags.
Rationale:
phpx command line tool:
*) php should look just like any other scripting lang from the command
line. Make the barrier to entry low and make the model consistent with
what everyone expects. Things like trying to remember to close a '%>' tag
in a large file of php code just makes users frustrated.
.phpx web handler:
*) When designing ASP.NET like web frameworks like Prado (see
http://www.xisc.com/) the code gets split between a markup file
which
isn't PHP code at all (parsed custom tags in an YourPage.inc file), and a
backing class YourPage.php which is pure php classes and has no need for
generating non programmatic page output.
Example silly but serious failure #1:
God forbid the user adds any extra whitespace at the end of the file after
the closing php '%>' tag, and the entire HTTP response rendering chain
breaks because by default PHP copies everything to the output stream and
those 'spaces' before the HTTP header is sent causes the response to fail.
In a real 'language' file, extraneous whitespace shouldn't crash your web
application.
This class of potential errors just seems plain silly and would be great
if php could by default ignore.
Thoughts?
--
Edit bug report at http://bugs.php.net/?id=32436&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32436&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32436&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32436&r=trysnapshot51
Fixed in CVS: http://bugs.php.net/fix.php?id=32436&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=32436&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32436&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32436&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32436&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32436&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32436&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=32436&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=32436&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=32436&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32436&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=32436&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32436&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32436&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32436&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32436&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32436&r=mysqlcfg