After reading the documentation, the file layout and concepts are all quite similar to django, though a downside is that we lose much of the beauty of the Python language and it doesn’t seem to have the Admin interface that makes django so delightful to work with.

Here is a sample of a helloworld, which would exist in a file called “Hello/Views.php”

< ?php
class Hello_Views
{
    public function hello($request, $match)
    {
        return new Pluf_HTTP_Response('Hello World!');
    }
}

as you can see, it is reasonably similar to (though more verbose than) Django’s equivalent “/hello/views.py” which would look like this:

from django.http import HttpResponse
def index(request):
    return HttpResponse("Hello world")

Check out the full helloworld tutorial of Pluf

ORM

Pluf has an ORM that applies similar concepts and ideas as Django’s ORM, though as with the helloworld, it is slightly more verbose. The rest of the framework follows the same patterns, urls.php has a more verbose PHP regex patterns than django’s urls.py

Caching

Pluf runs it’s own caching system as well as being able to utilise APC and Memcached

Django vs Pluf

So what exactly does Pluf offer in ways of advantages over Django and why would you choose to use it instead? The obvious reasons are if you are well setup as a PHP developer. You work with tools and ide’s setup specifically for PHP, you have hosting infrastructure setup for PHP and you work with developers who are well versed in PHP. The other advantage of Pluf is that it comes with a migration framework out of the box, whereas django doesn’t and you need to use one of the available database schema migration, the most promising currently looks like South

Of course, Django deployment is becoming much simpler recently by leveraging the tutorials and tools like virtualenv, pip and most recently modrails has begun supporting python wsgi services. I recently performed some benchmarks with modrails vs fastcgi against a django blogging application called byteflow and modrails provided approx 1.8x speedup. More to come on that later.

Technorati Tags: PHP, Pluf, Django, Web Development, Framework, MVC

Whilst they have served me well in the past and I may feel tempted to use Virtuemart for a customer who:

a) Will never ever need any customisations done to it
b) Already has a Joomla installation and is very comfortable using Joomla

What’s the issue with Zencart, OSC or Virtuemart you may ask?

The issue is this. First OSCommerce is a mess. Every single module you ever add to it is a hack, making upgrades a pain in the ass. Zencart, being closely related to OSC is not much better. It’s modularity is a bit better laid out and so you can actually create / install modules with very little hacking, if any BUT it’s template system still suffers from it’s OSC origins. It’s an effort to try and template for them..yes, it’s possible but does it really have to be that hard? Joomla’s concept is 1000 times better in regards to templating and Virtuemart excels in this area due to it’s Joomla foundations.

The big problem with them is when you need to make modifications to the core cart to implement a particular feature a customer wants. We have had situations where a small feature for the client required 144 changes in the files of Virtuemart. As soon as a XSS or other security issue comes to light, we have two options

1. Let it be, cross fingers and hope nothing happens (this really is not an option)
2. Inform customer, explain risks and give them compelling reasons to update (at their cost)
3. Our current solution is when we sign contracts with customers, we include a compulsory security updates fee, which means we update their site when new security releases come out. This has worked out best so far but still requires us to explain why we are giving a solution that isn’t inherently secure to begin with. Microsoft has made this easier to explain (daily updates anyone?) and for the most part, we can kill most XSS / SQL Injection attacks using Apache modsec rules but we really want to get beyond NEEDING to upgrade and therefore NEEDING to patch our mods into new releases of Virtuemart etc.

So, without further ado, there looks to be two better alternatives that have come to the rescue recently that look very, very promising though we haven’t done any work with them yet, so I will report on that later.

In PHP land, we have Magento. A very sexy, professional looking Open Source Ecommerce application that’s built upon the Zend MVC framework and claims to be able to develop extensions without touching core code. This, hopefully will fix our templating, modification and upgrade woes in a PHP solution. It has SEF URL’s built-in, google analytics built-in and a mini-CMS of sorts.

In Python land, we have Satchmo an open source ecommerce application built on top of the Django framework, with a reasonable feature set.

As part of my toolbox, my thinking at this point is if we have a customer that needs a standard shop with little to no development work, Magento will be our tool. If the customer has very unique needs, integration with other systems and customisations, we will work with Django.

This is because PHP deployment is so easy, that our only need should be to produce templates in Magento. If development work is needed, deployment and templating become a trivial matter in Satchmo in comparison to the ability to develop in Django & Python.

Would love to hear other’s experiences with any of the above… and of course any horror stories (or otherwise with OSC based development)