Slashdot Mirror
PHP3/4 as Web Development Platform?
Erestar asks: "I work for a small network integration company that also handles a good bit of web application design and hosting. Right now we're running 2 clustered NT servers along with Cold Fusion. Since my introduction to PHP3 I have been strongly pushing to run it in conjunction with IIS while still keeping the Cold Fusion server active. What I need are any comments or suggestions as to the validity of my cause. Will PHP3, running as a module for IIS, seamlessly fail over? Has anyone encountered any problems when running PHP3 and Cold Fusion Server at the same time? How limited is PHP3 as far as script size is concerned? Another issue that has arisen is the practicality of doing this. Are there any benefits to running PHP3 that Cold Fusion cannot provide (aside from "its just so damn cool")? Would I be better off committing myself to writing custom CF tags and COM objects with VB or C++? Would I be better off waiting to for a new release of PHP4?" Erestar goes on to describe his applications. Click below for more.
"We work with practically anyone; our clients range from Used Car dealerships to billion dollar banking firms. Nearly all of the sites are database driven, most with ODBC to Access databases (we're planning on turning MS SQL Server on any day now, though). We're also developing a tracking application that will manage most of our business requests and anything else we can toss in. It is this application that I would like to code with PHP3. Any information that you could supply would be greatly appreciated. "
Well, you are wrong. Rasmus on Slashdot does actually == Rasmus from PHP devel.
The note you quoted from Bruce was written in July. He says right there that we agreed to fix those issues back in July. Being September now, that has obviously been done. And they were just slight wording changes.
As for your CGI thing. You are being silly. You quoted a CERT advisory from 1996. Being September 1999, that has obviously been addressed as well.
-Rasmus
You are misinformed here. PHP 4 is very much Open Source and it has been run by Bruce Perens. The Zend component is under the QPL which has been deemed to be Open Source compliant and the rest of PHP is under an Apache/BSD style license.
.htaccess files anyway.
And your cgi concerns aren't too well-founded. The thing you can do with the cgi version, at least under Unix, is to run it as your own user id through suExec which is quite safe. Under NT, who knows, but then I don't think IIS has
Also, ODBC support is not new to PHP 4. It was in PHP 3 as well and it hasn't changed much.
And finally, PHP 4 has an ISAPI version coming so from a performance perspective it should be quite competitive, and most likely quicker than CF on NT.
-Rasmus
We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.
You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.
On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.
PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.
One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.
My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.
Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.
If you'll be using the CGI version of PHP3, please be sure that you
If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.
Perl is a lot faster to develop in than Java. Really. I've done complicated stuff in both. When you really push the envelope, Java's standard API abstraction barriers don't go far enough.
JSPs are okay, but so is embedded Perl or VBasic.
Cocoon is very unwieldy right now, and probably not yet worth the effort unless you are a huge shop with lots of Java and XML devotees. The examples assume an Oracle backend. That should tell you something. (Yes, I've played with Cocoon as well. Cocoon 2 may inded be revolutionary...)
I have never heard of Midgard and I've been around for a while now. This indicates to me that it could be difficult to hire someone quickly and get them up to speed on it. OTOH, if it's just like PHP only better, I could be quite wrong.
Just my experiences and thoughts.
Personally, I don't mind servlets, mod_perl, OR mod_php. They're popular for different things, so for maximum code reuse (laziness) I choose whichever gets the job done fastest.
(Zope, incidentally, is quite cool and OO, and would be great for a new installation, but too much of a transition IMHO for a preexisting site)
Remember that what's inside of you doesn't matter because nobody can see it.
I have personally not used Cold Fusion or Zope. But, I require *nix based solutions doing basically the same stuff you have done.
I think PHP is great. Its fast, it works well and is very well featured. I think that it works best statically built into apache, and I have only used it with Linux and FreeBSD. I think you are best off to wait on PHP4. Just start with 3, and then migrate as needed. I don't forsee too much incompatibility between the two, and as someone who gets way to many "Its broke" phone calls, I can't imagine delivering a beta backend for an important app.
As for Zope, it looked to me to be a simpler language than PHP, although powerful. I think it is good for dynamic web pages, but big web apps (such as the sort I create) are out of its scope.
I think that sticking with NT and CF is a poor choice. My firm almost always either hosts the web app for the client (we have one client that is a conglomerate of 300 companies nationwide) or delivering an inexpensive unix (linux, freebsd) dedicated server. I think that web apps are so easy to decompile, or just yank the source, that clients think they can edit it, and you have to fix it. I prefer to lock them out unless I truly feel they know how to code at all. I think NT is a terrible OS and that you need to get away from that, fast.
But, I suppose I am a bit of a zealot. grin....
And I understand there is not an existing license problem with PHP's open-sourceness. If that's not the case please explain.
Thanks
Bruce
Bruce Perens.
You should, in fact, be able to write a remote filesystem client for the WebDAV protocol, and you could put it in the Linux kernel and make it work like the NFS or Samba client. That would WebDAV-enable a lot of Linux tools right away. Someone go do that and tell us when you're done :-) .
And the V in DAV is for versioning, but I don't have a clue about how the versioning works.
Thanks
Bruce
Bruce Perens.
- PHP-like language (called DTML), with new experimental XML-compliant form of DTML as well which can be handled by XML editors.
- Managed via your web browser, there is no need to have a shell account to maintain a web site, and no need to be in the
/etc/passwd file. - Access control including user-defined roles.
- User information, roles, and permissions can be local to a sub-tree of a larger site, and can override what is defined higher in the tree.
- Object persistence.
- Content management with session control. You can join a session to test new content without having that content appear to anyone who has not joined that session. Commit or discard the session when you are done.
- WebDAV (drag-and-drop management of web sites) works today. Too bad the only WebDAV client you can get is IE5, but that'll change - it's an open standard.
- FTP access to your web site and its dynamic methods.
- Database integration with built-in query system and sophisticated search interface.
- No need for CGI. Export methods of classes via the web. Persistent program rather than CGI which restarts an executable with every call.
- Transaction processing transparent to the programmer. If an uncaught error is posted during a transaction, the entire transaction is backed out of the database cleanly. Data is never left in an inconsistent state. There is also a programatic interface to transactions, but you don't generally have to use it.
- It's pretty fast and low-overhead, too. My Pentium III 450 running Linux and Zope has survived being slashdotted many times. Sure, my Pentium 120 does that using just Apache, for static files. My Zope site, on the other hand, is very dynamic.
- Web-based definition of classes, or you can use python.
- Call from Apache, or run it as its own web server. If your site is entirely Zope, you can turn off Apache and save the overhead.
- Multi-threaded.
- Written in Python, with a tiny bit of C.
It takes a few days to learn everything that's in there, there's so much. I suggest you go over to zope.org and get started.Thanks
Bruce
Bruce Perens.
I used php since version 2.0 and liked it very much. It's extremely simple to write in and for the most part gets the job done.
Session management wasn't really addressed with PHP3. There are some libraries/classes out there that do it and I've used phplib internally in our organization and it has worked quite well.
I've recently switched completely away from php3 in favor of mod_perl. I write most non-web based applications in perl and found myself banging my head on the regular expressions and lack of libraries with php3. Why reinvent the wheel?
mod_perl can seem overwhelming at first. I've written a web-based mail application using Mail::Cclient and a bunch of other modules in the course of about 2-3 days of off and on programming. mod_perl doesn't come with session management built in but Apache::Session takes care of it.
I've settled finally on HTML::Mason. This is a very powerful way to write web-based applications and I highly recommend you check it out. Their home page is at http://www.masonhq.com/. The way the code is embedded in HTML is very similar to the way PHP3 does it with some powerful other features (dhandlers, ahandlers, etc.).
My biggest gripe about PHP3 is the lack of classes. There are a dozen sendmail.php3 classes and some other good stuff on the PHP3 code archives but with mod_perl, you capitalize on the entire CPAN with literally thousands of well-written and well-tested modules.
Anyway, that's my two cents. My experience with these have been with Linux only so YMMV with a non-UNIX platform.
Synaptic
Personally, I've been developing Cold Fusion applications for about 2 1/2 years now, and I think Cold Fusion is one of the greatest products the Win32 server arena has ever seen. Crashes from IIS are not too uncommon, but I don't ever recall Cold Fusion crashing or even hiccupping in the least. If you are having problems with Cold Fusion stability on your server, you should probably take a closer look at the installation.
Also, if you are looking to implement some kind of fail-safe, I would highly recommend Zope over PHP3. I've used Zope as well, and I think it far outperforms PHP3 in just about every aspect I can imagine. You can check out Zope at its website.
Also, as someone else said, keep on Allaire's heels-- they are supposed to have Cold Fusion for Linux out by the end of the year.
Good Luck..
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
I think they are. Check out this CERT advisory, as well as this page from the php manual. It's certainly possible to set up a host like this guy is suggesting.. but some care needs to be taken. I'm not familiar with IIS, so I can't comment on the availability of a chroot()-style environment.
Also, ODBC support is not new to PHP 4. It was in PHP 3 as well and it hasn't changed much.
Okay, you caught me on this one - I went back and looked, and there is indeed support for an ODBC driver manager in php3. :}
About your comment that php4 is open source... I quote the php4 License FAQ Second, the license prevents commercial use of the Zend library to build commercial applications. Correct me if I'm wrong.. but that sounds an aweful lot like a violation of OSD rule #1. See this link for the full monty.
--
I would seriously recommend using the mod_php3 modules under Apache due to performance and security. If you run PHP as a CGI script, you can do nasty-evil things like read the .htaccess files under apache. There is also no "safe mode" for the CGI module (I haven't verified this, however).. which means one coding slip-up and you hand the remote user all the priveledges the webserver has on the system (which given that you'd be running NT, is probably full access). Even with safe mode, you will still have some additional security concerns that the apache module doesn't have. :(
The other problem with PHP4 is the licensing - it is not open source. Bruce Perens and the OSI have been working on it for awhile now (a long while ago *muttering*) but it isn't fixed yet. Go over the license and see if you can live with it.. otherwise stick with PHP3 (which meets the OSD).
The single compelling reason to use PHP over third-party or Microsoft offerings is the database support. You should know that PHP4 brings ODBC driver support (via iodbc under linux, YMMV under NT) so that you can access alot more RDBMS systems than before. This is a definate consideration when looking at the client's needs. I will again reiterate that NT isn't the best platform for serving dynamic content from.. and would urge you to consider using a unix-based solution.. it's more scaleable, easier to maintain, and more reliable than it's NT counter-parts.
--
PHP's nifty, but the trend is away from loading business logic and presentation logic onto the same layer, as PHP and Cold Fusion both generally do. Cold Fusion has been moving toward a 3-tier approach with the addition of a separate app server, but it's not really there yet in terms of being able to run on separate hardware and having intelligent failover at the middle tier.
This is where in the NT world the typical scenario of hosting COM objects on something like MTS comes in, and ASP or Cold Fusion in front of it.I've heard it doesn't work thrillingly well in some cases, especially when you're trying to host Java COM objects, but the approach is right and there are ways to make this work well.
The usual platform-independent approach is to use a CORBA (for C++ or Java) or EJB (Java) app server, or at least plain old Java Servlets, which does essentially the same thing, typically with JSP for the presentation scripting layer. One nice thing about JSP is that they compile to Java bytecode and run very fast indeed.
Yes, you can run ASPs on a number of Unixes, Cold Fusion on Solaris (and gosh, don't they have a Java implementation of their server piece now?). And a number of Unix-family OSes can also host and/or access COM objects, though they won't magically have access to Win32 APIs.
And yes, the JSP/Servlet/EJB/CORBA approaches work very well indeed on NT as well as Unixes, with most of the higher-end app server vendors all abandoning their proprietary technologies and standardizing on this set of technologies these days.. See Broadvision, BEA Weblogic, ATG, Sun NetDynamics, Netscape Appserver, and IBM WebSphere for just some examples of the vendors doing this. It's mighty compelling.
On the low-end, getting started with the JSP/servlet combo can be very inexpensive and very stable indeed on any OS. There are free servlet engines (which you can use to connect to CORBA and COM objects without much fuss) for all the popular webservers, free JSP environments that can sit on the servlet engines, and many choices for getting into EJB and CORBA, from free (albeit sometimes not ready for wide use) to commercial (industrial strength). The great part about this is that you end up with code at each layer that runs fast and is extremely portable to and between the most scalable and bulletproof app servers around.
As for commercial RAD tools, you may want to look into a new version of Drumbeat that generates JSP instead of ASP. And most modern Java IDEs make for great EJB and servlet development environments.
Can't speak for the forthcoming PHP4. It may come closer to this sort of thing.
One thing to say in PHP3's favor is that some pretty large and high-volume sites do use it, though the heavy-traffic ones probably have the nastier logic on a middl tier or as stored procedures in the database.
Perl is also good for the same things, but there's a bit more overhead, and that needs to be balanced against what you need to do. For larger applications, I would definitely choose perl, since there's just a lot more you can do with perl.
I've also used php3 for building template based web sites which have active and static parts. It's also really nice for this. Want your pages to all look roughly the same? Code a header and a footer up in php3, and just include them in a template. Makes site management really easy, and the syntax is fast to develop in, if you have any perl or c experience (or ASP or probably cold fusion, for that matter).
I know people have built very complex applications in php3, and it seems to work for them. I've never done that though. As always, whatever makes you happy, go with it. :-)
----
We all take pink lemonade for granted.
There is no K5 cabal.
I am not the real rusty.
Point made. My post above relates specifically to Linux installs (Apache/mod_php). Use NT at your own risk (hey! that's what the EULA tells you anyway, right?) :-)
----
We all take pink lemonade for granted.
There is no K5 cabal.
I am not the real rusty.
PHP is a terriffic system, but with the release of version 4 so close, I can't see putting tons of effort into getting stuff running in PHP3. This isn't really because of compatibility issues - PHP3 code should work near seamlessly with PHP4 - but the newest version will introduce state/session management directly into the language. Right now, you have to rely on other people's session managment classes to do that - there are some great ones out there, but it isn't really worth figuring them out now if they're going to be supported in the language soon anyway.
That said, I use PHP almost exclusively for web scripting these days. It has a steeper learning curve than CF, but it's also infinitely more flexable.
Hmmm.. If you look further below on here I'm going to be freeing up the code soon :)
:) well I can add those in too.
That is very cool. I did notice your post yesterday but didn't have a chance to respond.
I'm also breaking up the source code so it's easier to read..
As far as comments go.. who needs comments?
I will try to grab a copy of your source when it is released and see if I can make any contributions as far as comments go. I've found that it is sometimes most useful for someone who isn't familiar with the code to figure out what sections need comments based on what isn't apparently obvious. Getting the benefit of not being too close to the code I guess you could say.
I also have some interest in adding support for more of the databases that are supported by PHP.
Since no one is paying for it I'd rather see it has a problem for Microsoft than just a program no one uses so I am making the next release free...
I think that being able to free people of the shackles of ASP proprietariness is an important enough thing that I'd be willing to help out even with something that I don't have a personal need for. I also think that PHP is cool enough that anything that helps it become more popular is a good thing.
I think that there are still some opportunities to make money with this thing if it becomes popular. Perhaps writing a book or charging for support. You might even just be able to personally write your own ticket into a really cool job somewhere if that is what you want.
We also applied CF to a legacy client server system running 300,000 lines of custom C code under SunOS and Sybase 4. The system had not been maintained and was due for a $1.4m upgrade for Y2K. This money was to port the code to Solaris 2.7 and Sybase 11.4 with no new functions or upgrades for the users. Yet another example of Y2K money squandered foolishly.
No kidding. I wish I could find a few contracts like that. $1.4M for such an easy porting job (I do stuff like that all the time) is basically highway robbery.
Porting 300,000 lines of C code to such similar platforms is at most a nice mid sized project that should take 1-3 decent developers 3 to 6 months including debugging and testing, assuming your contention of no new functionality. That comes out to something like $333 per man hour figuring conservatively.
Frankly, I think one well experienced developer could do all of the porting work in a few weeks, and get a couple of people to help with testing. I've done jobs like that in that kind of time on code I didn't even write to begin with, so this vendor with presumably familiarity with their own code should have a leg up on it.
We quickly prototyped a CF solution and determined that the entire baseline could be completed, with major enhancements, with 30,000 lines of HTML and CF "code" in approximately 6 months. The original vendor concurred, but still wanted the $1.4m, and another $1m and a year to upgrade.
$1M for only 28,000 lines of CF code should yield a pretty damned good profit too, for that matter.
I have corresponded with the author of ASP2PHP (which did seem to do a good job of converting some ASP code a friend of mine had -- I don't use ASP, so I can't give that much of a testimonial there).
Although some people will probably not like his (definitely not open source) licensing for ASP2PHP, he did release the source a while back, so it may be possible for you to fix the problems you encountered. Getting him to accept the changes back may be somewhat more problematic, as he is a bit picky about how he will take things (he doesn't like diffs). Also the code isn't commented as well as I'd like to see for other people to work with it (something the author did not dispute, as he hadn't intended originally to release the source).
He also offered to look at ASP code that wasn't converting properly, so if you are willing to send him examples, he may be able to enhance the product so it would work better for you.
Compared to Zope, PHP is merely a very nice scripting language you can embed in your pages, so to speak. I really dig PHP for it's own uses, though.
Zope, on the other hand, is very impressive!
Object Oriented, tight, finegrained security model, very dynamic, runs on several platforms, Python, connects nicely to databases.... OpenSource!!!
Zope has an extremely high Feel Good Factor(tm) (a Jamiroquai term); in fact, it's very addictive!
Once in a while you come by a ware and this strange, warm feeling fills you up... these people have created a product with a lot of brains in it and behind it... everything is good!
Zope is of this kind.
Btw. you can get nice commercial support from the creators at http://www.digicool.com/
Best regards,
Steen Suder
Best regards,
Steen Suder
-- for email: send to
If you're a big PHP fan, you should check out Midgard (at www.midgard-project.org). It provides some sweet content management and administration features (very similar to some of Zope's capabilities), but is based on a slightly-modified version of PHP. They have experimental ODBC support, and that should be solidified very soon.
--JRZ
I have been developing in cf for quite some time, And my Biggest site is TOTALLY dynamic, everything except the images are in the db. We do on average 70k sessions a day. All of cf/iis/nt. So i doubt that cf cant handle load cause it is. Now running cf on a unix box was a whole different story, they use to use an emulation library to get it to run on unix which was just butt-ugly. btw the throughput over the nic card for the site is averaging 220 kb/s. constant. Again I love linux/unix/bsd etc etc etc. But dont bash something beacause you havent done it.
As you see, it's so easy even a script kiddie could use it. And they do.
On the other hand, many of the mod_perl applications I've looked at have been sophisticated and clean. They've actually been designed and structured. They're a pleasure to read and to maintain. And they're written in the same language as those CGI scripts from hell that the script kiddies mutilate. Yet it seems like it's galaxies far removed.
Interesting, eh?
I believe this is saying more about the average CGI script kiddie versus Apache mod_perl hacker than it is saying about Perl. But yes, it's easy to write bad perl code. I guess it's easy to write bad C++ code too, but the barrier to entry is higher.
I don't know that there's ever been a language written in which it's been the least bit hard to write bad code. If you outlaw bad code, only outlaws will code badly. :-)
I have written applications using ColdFusion, PHP3, ASP and now Java servlets. Once you fully appreciate the power of servlets; I've never looked back.
PHP3 suffers from the lack of session management-I know there is an add-on to handle that; and I have not checked out Zend (PHP4) in detail, so that might have changed. PHP4 supposedly comes with built-in database connection pooling, it sounds great.
My work with ColdFusion got me a new car, but I've never liked ColdFusion. Yes, CF is probably the easiest server-side scripting solution. But I have never been satisfied with its performance; which may have more to do with NT than CF. CF database connectivity functions are rather simplistic and do not give you much flexibility, IMHO. You can only do so much with s.It might be good enough for use with an ultra-simple database like Access; but once you start using a more complicated database like Oracle or MS SQL Server, you will need more complicated database access interfaces like MS ADO or excellent JDBC. But then, you can of course use ADO with CF, too.
By the way, you really don't want to get caught running Access as a database if your site gets
In my opinion, servlets are the way to go. Download Jserv and Apache, or one of a number of servlet engines for IIS, if you have to run on IIS & Windows NT. Get the O'Reilly servlet book, and start experimenting. You get built-in session management, excellent database connectivity with JDBC, access to all those free Java code around, and a lot of other goodies too numerous to count. When Enterprise JavaBeans become more popular, you will have a very good distributed object technology in hand, too.
I kind of like ASP, but I think Slashdot is not the right place to confess this, so I will stop. It's a pity it runs on NT only-there are a bunch of ASP solutions for other platforms as well (Chili ASP comes to mind), but frankly I'm not sure if you still have access to COM on those platforms. Almost everything that's useful with ASP are COM objects.
In a nutshell:
-If most of your work involves simple database query pages and simple dynamic pages that have to be done quickly, I don't think any of the server side scripting languages will make any differences. ASP, PHP and CF should be equally fine. You probably will not be dealing with fancy features like session management or database connection pooling with these anyway.
-If you need to do more serious applications which will experience high traffic, and complicated database operations, consider servlets, or COM objects with ASP, if you definitely have to use NT. If you use COM and ASP, consider writing the objects using ATL for the highest performance-in terms of performance, it is only second to ISAPI DLLs with IIS. However you will find it very easy to write COM objects in VB as well.
Moving to a real application server like open source Enhydra,Locomotive or IBM WebSphere will be even better in the longer term. They have some pretty impressive infrastructure for use with servlets, and they are very robust, too.
Zigbee Central: A Zigbee weblog
Everybody seems to be focusing just on Zope, PHP, Perl, and ColdFusion. What about:
(1) Midgard (www.midgard-project.org). It layers on top of PHP, adding functionality, remote administration, more code generation, etc. They plan to do an NT version soon (might be more a matter of just compiling it than doing any coding).
(2) Java Server Pages. They let you embed code into pages the way you do with PHP, ASP, and the rest. But since they're Java, you don't need to learn a new syntax, and you're guaranteed to be able to do anything (remember: Java can also use Perl and C/C++ modules, so anything is fair game). And apache.org supplies a free engine for it. I use JSP's regularly, and they're great.
(3) Servlets. Yes, they're useful and powerful, and standard syntax.
(4) Cocoon (ava.apache.org/cocoon/). It's a project using COM, XML, and XSL, and will probably be the most powerful framework around (but I want to wait to see anybody use it before I try; it's difficult to be first, since there's nobody to ask how to do it!).
PHP is a great concept for a language - being entirely internet oriented it makes code more compact than, say perl CGI.
I use PHP very seriously. I also use a Linux platform, and would strongly recommend that.
PHP3 has some big problems. 1) effeciency is not very good, especially noticeable on a large website. As I understand it, PHP3 has no capacity to cache the result of parsing code. Thus everytime a function is called or a file included, the parser must re-check the code. 2) OOP sucks! Reference support is extremely bad. Be prepared to undergo major hacks to get OOP working with PHP3.
I have used PHP4 beta 2 for over a month now with no glitches. It is a wonderful thing. OOP actually works great! And the parsing engine caches results (similar to Perl). Also lots of other handy stuff has been added... including output buffering (enables you to send HTTP headers even after HTML output) and a bunch of other functions that you will see in the PHP3 manual that look great and have a footnote saying "added to PHP version 4".
As I understand the licencing for PHP4, PHP4 itself is open source and free. Something called "Zend" is the parsing engine for PHP4, which you must pay for if you intend to take the Zend code and use it within a commercial application.
There is something called PHPLIB available for PHP3 which takes care of a lot of web authentication, page rendering, etc with some high-level object code. I looked at PHPLIB and decided not to use it because use PHP4, and I prefer to know every little detail of how my code behaves. However, PHPLIB gives a good structure for how a complex PHP-driven website can be built, so it is a good starting point for anyone.
A W S ----------- QABO : BALA
We developed our sites in PHP3 with MySQL on FreeBSD, and we're very happy with them. However, we've recently been playing with a couple other tools that have really piqued our interest.
ZOPE: Very nice development interface, easy to add functionality using python, XML support, good cross-platform ability. The object-based development platform takes a little getting used to, but is extremely powerful and convenient.
See An Introduction to Zope for a very good overview.
PHP: Can do just about anything. Great database support. We've had no performance problems due to php at all. Run it as an apache module, of course. I have not used it much on Windows, but PHP4 promises to have excellent Windows support.
We have a number of articles, tutorials and docs about PHP at DevShed.
APACHE JSERV: Efficient, powerful, mature. Apache talks to "Servlets" that do most of the work. The servlets stay in memory, no new processes are forked. Multiple servlets may be used, I believe across multiple servers if necessary. Session management is included. It's all Java. Apache Jakarta will also include Java Server Pages (JSP), a strong competitor to PHP and ASP.
ROXEN: Similar to PHP, written in Pike, a C-like object oriented language. Easy separation of layout and content, easy database integration, very efficient. This one includes its own multipurpose server (web/proxy/ssl/ftp).
See Introduction to Roxen by Kai Voigt for more information.
We're still sticking with PHP for now, but looking most seriously at Jserv for the future.
Our #1 qualifier:
OPEN SOURCE - all of the above solutions are!
--- Web Developer Shed - http://www.devshed.com
Something you may wish to consider is Allaire's announcement that they will be releasing ColdFusion for Linux in November.
-Vercingetorix
"Necessitas non habet legem." -St. Augustine
If you wanted to switch, I would highly recommend switching over full-scale and rebuild those NT boxes as Linux boxes, use Apache and PHP or mod_perl or what have you.
You might also look into doing servlet programming with Java. JDBC offers an excellent interface to databases and the advantage of going Java is that, at least with JDK 1.1, you really can move your code from the NT box to a Linux box when NT buckles under the load, and from there to a huge 64-processor Solaris box when the Linux box can't take it any more and it will all work essentially unchanged. (Write-once-run-anywhere works for the most part as long as you stick with straight JDK1.1 stuff and don't use too many third-party add-ins, or at least stick to add-on libraries that are 100% java.) IBM's JDK for Linux is quite high-performance and remarkably stable for what they call an "Alpha" version. (You can find it at www.alphaworks.ibm.com)
A warning about Java servlet programming -- Java is a highly structured language and if you're into the kind of "quick kluge" that languages like Perl seem to be designed to handle, or the "quick one-off" that PHP excels at, you're going to have some problems moving to Java servlets which requires a lot more thought and "engineering" to get a good design. The advantage is, at least in my experience, going the Java route winds up with much more maintainable and extensible codebase.
This is not intended as a poke at PHP or Perl, just that those two languages are really designed to do stuff "quick-and-dirty" and therefore are very easy to write nasty code -- lots easier than it is with Java. (although you can still write nasty code in Java.) I'm speaking from experience as I've written nasty code in PHP and had to try to clean it up into some sort of maintainable form without a lot of luck once the codebase gets to a certain size, and I've had to deal with nasty CGI Perl code written by other people that I was barely able to read, much less figure out how to change without breaking the whole thing.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
CF doesn't do everything I need and it's damned ugly.
Linux: PHP 4 and Apache.
ASP:
Pros: ASP makes better use of record sets through the recordset (surprise!) component and the use of sessions variables is much more intuitive.
Cons: NT
PHP:
Pros: Linux/Apache and a much wider range of support for inexpensive (and expensive, if you like) databases.
Cons: None