Re: [PHP-DEV] short_open_tag

[Terence Kearns]

Kristian Koehntopp wrote:

On Tuesday 22 October 2002 09:17, Terence Kearns wrote:

Ideally this is true, but as so many poeple have pointed out, not every
developer has access to the ini file on their ISPs server. Indeed,
maintaining a php.ini file is already a nightmare for ISP hosting to
unspecified groups PHP users.

I cannot speak for other ISPs, only for our setup.

In our environment we do have low traffic setups. These are run from Apache servers with a hacked up suexec that includes a chroot() call to the customers toplevel directory. This setup runs CGI-everything including
CGI-PHP. Due to chroot, each customer gets a copy of a minimal execution environment including a copy of the PHP interpreter and
a copy of php.ini. The customer can install additional software (sparc
binary) including a C-Compiler or Assembler, a different PHP if she
likes. Should the customer break something, we reinstall a copy
of the original setup on top of this.

This setup offers the advantage of highly customized configuration
for the customer, extremely low maintenance cost for us, and very
high grade security (no safe_mode required, security independent
of PHP, affects all CGI, even resistant to access rights goofs). The
price is the CGI performance penalty.

Because of this we also have some mod_php setups, but these are
usually dedicated (again no safe_mode) or very controlled. In these
environment the customer cannot control php.ini, but has no need to
as there is php_flag and php_value available from .htaccess. This
includes the dreaded short_open_tag flag.

OK this setup sounds cool :-)
unfortunatly, not every ISP is as cool as the one you run.
Neither should it have to be.

And frankly, if you need XML and short_open_tag disabled, and if
you need it on a hosting machine and not as a local CLI program (which
I think is far more likely) and if you need to intermix XML and PHP
instead of using a templating solution, and if you THEN insist on a
provider with a setup that is simply broken, then I feel you deserve
what you get. Really.

You're making some big assumptions about how people will want to produce XML. One of the ways people might want to work with XML is to obtain XML output by mixing PHP code in an XML document. This is no different to the way people most commonly use it with HTML. Anyway, how people should be allowed to generate XML is not the issue. I am aware that for large scale applications, it's better to generate it programatically using XML DOM. However, people should be able to generate XML whatever way they are comfortable with - especially if they are comfortable with the methods they used to use for HTML. My personal preference (DOM), but that doesn't come into it.

My main concern is that when XML
becomes very popular, trying to implement it will become a "NON-trivial"
exercise for the great unwashed.

If you need to deal with XML, and you need to do it with PHP instead
of XSLT,

I'm sorry?, I don't get this "instead of XSLT" business...

go PEAR and use the Transformer. You save yourself all the
engineering and you will be independent of all short_open_tag hassles.

The PEAR Transormer class is cool. But it in no way fixes the short_open_tag problem.



--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php