From the "Braindump" section over on DevShed today there's a new article sharing some helpful hints on picking out that right Open Source content management system that you need for the job.
A Content Management System (CMS) provides a straightforward way to maintain a web site, allowing site owners to include interactive features such as article publishing, file uploads and sharing, forums and blogs with a minimum of coding. And a good CMS will also allow extensive customization to the site's layout and appearance, so it doesn't end up looking like thousands of other sites built on top of the same code base.
The look at a few of the priorities to consider - multi-author support, metadata management, ease of use - as well as technology and business considerations. Systems they look at in their overview include Joomla, Drupal, Mabo and Plone.
This post on the JankoAtWarpSpeed blog started off a discussion between PHP and ASP.NET developers as to why one would go for the first over the second.
The first thing that came up to my mind was that PHP is quite simple language comparing to ASP.NET (.NET actually) which is a complete framework that offers a wide range of possibilities (yeah I made a comparison). Maybe PHP has a simple learning curve comparing to ASP.NET, but why would web designers care for data access layer or OOP anyway? But on the other hand, it doesn't mean that web designers should limit their selves just to PHP. Why not be familiar with other technologies as well?
The post has lots of comments from both sides of the fence, each espousing their language of choice. Reasoning ranges from "because ASP.NET is a Microsoft product" to the price of ASP.NET hosters to PHP's open source-ness and the much different learning curves.
With the final decision on the namespace operator announced, several of the PHP community have voiced opinions, comments and concerns about the selection including:
Fabien Potencier has posted to the symfony blog today about a form handling enhancement they've introduced in the latest release of the framework (v1.2) - sfWidgetFormChoice.
When displaying a form, you often want the user to make a choice amongst a list of possibilities. In HTML, a choice is represented by a select tag. You can add a multiple attribute to make it accept several choices. [...] To unify all these possibilities, symfony 1.2 comes with a new widget called sfWidgetFormChoice. sfWidgetFormChoice is an abstract widget in the sense that it delegates the rendering to another widget (the renderer widget).
He includes examples of how to use the widget to make dropdowns, radio buttons, check boxes and even integrate some Javascript for handling multiple lists and autocompletes.
With a follow up to a previous post of his about Delphi's choice of VCL over Prado for the behind the scenes framework for their software, Eirik Hoem has posted this based on feedback from the original post.
What I miss in the feedback I got from my previous post was people acually using VCL/PHP for enterprise applications and how that is working. From what I can tell the usage of Exceptions is still limited to the 3rd party libs such as Zend Framework which are included with VCL/PHP. That's a bit interesting.
He mentions one big issue that several people pointed out with the VLC implementation - the class name prefixing (or lack there of) and the problems it could cause in the future. Prado uses naming conventions that keep its classes out of the move generally named realm. He also touches on the quality of the code behind the VLC implementation, noting that while it might work well for smaller projects, there's more of a potential for failure on enterprise-level usage.
On her blog, Objectively Oriented, Maggie Nelson looks at a topic she was debating for a new application - whether or not to use persistent connections to her database.
There's a connection already waiting for you. Yay, right? Well, with MySQL, connecting is actually really really cheap, and frankly, if you are using persistent connections, you might encounter some issues with Apache going zombie on processes that use a connection, effectively taking that connection out of use. Grrr.
She did some research on the topic but found contradicting evidence for both sides. Eventually, what her choice boiled down to was this possible issue mentioned by Jay Pipes (of MySQL):
If you use Apache, Apache can zombie a PHP process and cause the mysql connection to be held until the mysql server restarts...
In a recent post to his blog, Michael Kimsalasks a question that I'm sure PHP developers everywhere are wondering - why did Google choose to go with Python as the programming language of choice for their new App Engine service.
TechCrunch is announcing Google's new "App Engine" service being launched this evening. The basic service is a full app stack hosted and managed by Google, providing a web framework (maybe I'm misreading this?) and the Google 'big table' database service. [...] My question is "why was Python was chosen instead of PHP?"
There's been some great responses since it was originally posted including everything from agreement to rationalizations for the move (though there is a fair amount of PHP and Python bashing going on - an obvious occurance).
From the Ask Apache blog, there's a quick tip that makes it simple to give your site's visitors the option to either download or view a PDF file no matter what their browser default is.
One of the most annoying things on the Internet for me is when I click on a link to an Adobe PDF file. For me this is annoying to the extreme because the PDF file is openened directly in your browser because of the Adobe PDF Plugin that almost all browsers have installed. [...] For me an ideal solution would be to offer me choices.
His solution uses mod_rewrite in an .htaccess file to push the visitor to a PHP file. This file grabs the filename they want and pulls in the content, pushing it back out the other side with the "attachment" header that forces a request box on the browser.
Brian Moon has posted today about his editor fo choice for PHP work - jEdit and some of the benefits he thinks it has for other developers.
I keep trying all the latest and greatest editors out there. I fought with Eclipse and have tried the newer more PHP centric offerings built on Eclipse. I recently tried out Komodo Edit for a week. I had tried the Komodo IDE when it came out for Mac a while back. But, I just keep coming back to jEdit.
He's broken it down into two (well, really three) different sections - the likes and dislikes followed by things that he "doesn't care about but you might" (including Subversion and CVS support).
A new article over on Stefan Mischook's blog today talks about why PHP should be the language of choice as told from a business mindset.
I have written this article to speak to business owners and other non-nerd types. [...] I concentrate on the business arguments and only touch on the technological issues underlying them … when it makes sense to mention the nerd stuff.
He talks about answers to the "business questions" (like "Is the language reliable?"), about how PHP was made for the web not adapted to it and a quick story of his own to back up his points (started a project with Java and moved to PHP for thousands of dollars in savings).
