One struggle I did get stuck on is the “Access Denied” message when connecting. A lot of people are having issues with it. My issue was that I had used the same username for my API access as I use to login to the admin in my testing. As soon as I changed from that, I overcame that issue.

Anyway, I stumbled across this Python Magento library and saw it had a number of useful functions already in it. So I decided to hack away and add to it.

So far, I have added a function to retrieve the list of categories and write them to a file from the catelog_category.tree api call and finally, as per my original intention, write a function to bulk upload categories from a CSV file.

I’ve never contributed code to a project before so if I get these changes in, it’s my first public contribution.. until that happens, you can hit me up for the code and a sample CSV file.

I might add: Python xmlrpc is beautiful to work with and gives a great deal of flexibility for building a gui on top of this. Working with the Magento API was nice also.

So I decided to find out what it would be like to do some web programming in it. I learned a bit about asp.Net in the process and mono also.

So first thing I did was:

$ cd /usr/share/doc/boo/examples/asp.net
$ xsp2

and then from your browser you can run any of the “inline” samples

http://localhost:8080/InlineBooButtonClick.aspx
http://localhost:8080/InlineBooExpression.aspx
http://localhost:8080/InlineBooHelloAspNet.aspx

but if you try and run one of the code behind samples, you get something like this:

Description: Error parsing a resource required to service this request. Review your source file and modify it to fix this error.

Parser Error Message: Cannot find type Boo.Examples.Web.YourName

Source Error:

Line 1: <%@Page Inherits=”Boo.Examples.Web.YourName” %>
Line 2:
Line 3:

The problem is the the boo source code needs to be compiled and the dll’s must be placed in a bin directory in the folder you are running xsp2 from. There is a nant build script there but after trying to hack it to get it to build, we worked out it was easier to just compile manually.ie:

$ sudo mkdir bin
$ sudo booc -t:library -o:ScriptRunner.dll ScriptRunner.aspx.boo
$ sudo cp ScriptRunner.dll bin

from your browser:

http://localhost:8080/ScriptRunner.aspx

You can then use this to play around with some boo as if it were the booshell (booish)

Thanks to Cedric for helping me out in IRC on this.Technorati Tags: mono, python, boo, language, xsp, ubuntu, linux

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)