In a response to these comments made by Paul Jones concerning the Prado framework, Mike Naberezny shares his thoughts on the framework, the "PHP way", and how the majority of site functionality out there can really be divided up pretty simply.
RADO is getting some new attention because it was completely revamped earlier this month. It's certainly matured considerably since the contest and is the most well-known component framework for PHP. However, in all that time since PRADO was first introduced, the idea of a component framework hasn't been adopted by the majority of PHP developers. Why is that?
Although PRADO is a nice piece of software, Paul surmises that a component model as used by Microsoft .NET (Visual Web Developer now free!) and its close cousin PRADO is not the "PHP way" or "PHP spirit". For the most part, I agree with this. Although, I don't think it's necessarily a PHP-specific issue. I think it speaks to a larger architectural decision - how far to abstract out the HTTP request/response paradigm.
He summarizes the functionality in three different methods of handling: "page/file based", "action based", and "component based". He also notes that the interesting fact is that the "page/file based" method seems to be so dominant in the PHP world, only emphasizing the fact that PHP is more of a "get it done" language than anything.
I've been told that MIX has sold out and that there is a lot of interest in our slot, so I'm sure we'll have plenty to talk about, but I'm looking for questions to break the ice and get things rolling.
If you know a little bit about the topic and would like to help out with questions of your own, send them along to Wez via email - wez@php.net.
On Debianhelp.co.uk, there's this quick guide for those Debian users out there looking to quickly and easily install a full LAMP setup on their machine.
They start with the install of Apache 2 via the package manager/installer apt-get (different packages depending on which style you prefer - mpm-prefork or mpm-worker). With that installed, the web server should be up and working. Next up is MySQL, installed in a similar way and enabled in the php.ini file as a module.
Finally, PHP is installed and support for it is added into the http.conf file for Apache. There's also a brief mention of installing ASP via a mod_perl package as well.
In this article on WebProNews, Andreas Roell praises PHP, nothing several strengths and its flexibility while the fact that it's kept its reliability over time.
PHP has been able to stand its ground as a consistently implemented server-side scripting language. PHP is a general-purpose scripting language that is ideally suited for web developers, and can be easily embedded into HTML.
He mentions the advantage it has of being Open Source as well as flexible enough to run on just about anything out there. PHP can be more cost-efficient than other solutions and, since it is Open Source, you're not left waiting for a company to release their next patch when they feel like it (fix it yourself!). And, of course, what would an article singing the praises of PHP be without a brief mention of its competitor, ASP.
In a new post on his blog today, Paul Jones mentions a framework that might bridge the gap for ASP developers making the move over to PHP, Prado, and some of the issues that more traditional PHP developers might see around it.
An old buddy of mine wants to start using PHP, but the problem is that he's been working with Microsoft technologies for so long, he doesn't get "the PHP way". His background, for many years, has been with ASP.NET, COM, and those sorts of things.
As it turns out, there's a PHP framework out there that maps well to "the ASP.NET way": Prado.
He talks about how the framework is structured and what non-PHPers might find to like about it, but he also wonders if the phrase "the PHP way" might be better replaced by a more definitive term to describe the way most PHP develoers prefer their apps to work.
I'm pretty excited about this weeks webcast. I'll be speaking with Brian Goldfarb and Joe Stagner of Microsoft about how PHP can be used for enterprise development on the Windows platform.
I think that everyone should consider checking in and asking these guys some questions.
He also mentions that Microsoft, for a long time, only saw PHP in the context of the LAMP "package" and not as a stand-alone language. Seems their outlook has changed a bit - check out the webcast to see just how much...
Both ASP and PHP are languages used to build Dynamic Web sites that can interact with Databases and exchange information. ASP (Active Server Pages) is from Microsoft and is used with IIS (Internet Information Server) that runs on Microsoft Servers. PHP (Personal Home Pages) is from Rasmus Lerdorf, who originally designed this parsing language which was later modified by different people. It runs on Unix and Linux servers and it also has an NT server version.
There are a lot of differences between ASP and PHP.
They go through several topics comparing to two - things like cost, speed, and database connectivity. The information provided here isn't anything groundbreaking, and there's no real conclusive choice (despite their "choice" at the end) between the two. What it really boils down to is the old "right tool for the right job" kind of situation, really...
On the Sitepoint PHP Blog, there's this post from Harry Fuecks on converting those lingering ASP scripts over to PHP, and a tool that can help along the way.
If you've been around PHP a little, you've probably run into asp2php before, an app which attempts to convert ASP 3.0 code (VBScript mainly) to PHP automatically. I've mentioned and joked about this stuff before but recently been playing with something that looks serious.
A while back, while looking for tools able to parse PHP, run into ASPA, developed by Anakreon Mejdi: "ASPA attempts to automate the process of translating asp pages into php. The supported languages are JScript and VbScript".
He looks at what ASPA is, a few of his thoughts on the topic, and a summary that notes that while "it works", there are still some issues that need to be ironed out before it will be really useful...
