Re: Re: cvs: php4 / TODO

From: Date: Fri, 13 Oct 2000 08:26:27 +0000
Subject: Re: Re: cvs: php4 / TODO
References: 1 2 3 4 5  Groups: php.dev php.general 
Request: Send a blank email to php-dev+get-34870@lists.php.net to get a copy of this message
Jim Jagielski wrote: > There is that unfortunate mindset, that's repeated often: that > PHP is only good for small and medium sites. PHP, and Java and JSP > and just about anything you can think of, are tools, designed to > do something, and do it well. Are there shortcoming in PHP? Sure. > But I tend to believe that there are more in Java. The fact that > a saw can cut, but a hammer can't, doesn't make the hammer a > worthless tool ;) That perception of PHP is in part a marketing problem, but marketing needs buzzword compliance in order to become efficient in changing that perception. That is, because behind this perception of PHP are some very real limitations in the language and the platform, which an appserver, stronger typing and a made-over object model would cure. Java too has some design stupidities, for example the lack of native java compilers and the enormous memory requirements of JVMs. Java was a bytecode driven language in order to be portable between client machines and in order to implement Java security. With java on a server, there is no need to be portable, and the execution environment is controlled completely so there is little to no need for JVM based security. The JVM has become completely redundant. Instead, it would easily be possible to compile Java into native machine code of the target platform, and have it execute directly on the silicon. That would save the cost of the JVM, and all the complexity involved in JIT, bytecode caching and the like... Of course, PHP does not address this, either, as there is not (and won't be?) a native PHP compiler or gcc/PHP integration (and a stronger typed variant of PHP, so that this compiler can take advantage of the type information). > There are very few things intrinsic to Java/JSP that make it "better" > suited to large, complex sites. One here's that it's "impossible > to separate the business logic from the display logic" a lot. But > what is it specifically, for example, in JSP that _does_ allow it? As a side note regarding separation of content and layout, have a look at the roxen platform. Such a mechanism involving XML/XSLT with PHP callbacks, would be really useful and a very powerful marketing point for PHP. Basically, you would have a web server module which executes stylesheets, not unlike mod_xslt as found as referenced by http://www.gingerall.com/. PHP would be a really nice escape mechanism on top of such an engine, where one could overload/replace regular HTML/XML tags with calls to PHP functions, giving these PHP functions access to attributes and content of these tags. One could then for example write an overload for <h1>-tags, replacing them with TTF rendered fonts. Have a look at http://www.netuse.de, and right-click on any of the headines. These headlines are set as normal <h1>/<h2> containers in the source document, but the roxen engine has overloaded these tags with a definition of our own: <define container=h1> <p> <gtext split fg="#000033" bg="#ffffff" 2 bold nfont=offensive><contents></gtext> <br> </define> This defines a new tag <h1>, which is being implemented as a call to <gtext>, using the <contents> of the <h1> container. The <gtext> tag is implemented as a callback into a programming language, in the case of Roxen the pike language. It takes the contents of this tag, and renders them as a TTF GIF, using the fonts and attributes specified in the gtext. This definition of <h1> is being kept in a stylesheet external to the document, and is in fact configureable. Try http://www.netuse.de/index.html and http://www.netuse.de/index.html?tmpl=netuse1.tmpl to see the effect (will take a long time first time, as the result must be rendered and is then cached automatically). Merging XSLT and PHP, a similar thing could be possible with PHP, enabling you to truly separate content and layout. Have a look at the true source of that index.html: <h1>Willkommen bei NetUSE </h1> <news title="Microsoft senkt Preise für Windows 2000 Server" src="/news/microsoft/20000928.html"> <img src="/profil/partner/SPPLogo.gif" alt="" width=159 height=50 align=left> Microsoft senkt im Zuge einer Vereinfachung des deutschen Lizenzmodells im Zeitraum vom 01. September 2000 bis 31. Dezember 2000 den Preis für das Netzwerkbetriebssystem Microsoft Windows 2000 Server. </news> The <news> container is <define>ed as part of the template, and will generate the result shown on http://www.netuse.de. Changes to the index.html will be detected and re-rendered, then cached automatically by the roxen webserver. This separates content from layout just fine, and has an efficient and transparent caching concept behind it, making it very, very fast. Unfortunately (for roxen) there is little to no user base for roxen, despite it being the superior server and having a really nice concept. PHP has the user base, and could have the concept, if XML/XSLT and PHP are merged properly. Kristian -- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/

« previous php.dev (#34870) next »