Some news on django SHOP
Today Christian Bertschy, the CEO and founder of Divio, added me to the list of core developers for django SHOP. Thanks to him, Chris Glass and all the other contributors of django SHOP!
Since currently I’m working on my third e-commerce site based on django SHOP, it is a good moment for this decision. In my opinion, having a paid project, is a good motivation for developing the basic framework as Open Source.
Unfortunately, django SHOP in the past year did not gain much attention from the core developers and some of them might probably have shifted to another e-commerce framework. Myself, I was quite sad that open issues and pull requests were not even answered. This certainly is not a good prerequisite to start a new project with a seemingly abandoned framework. However, for me there have been a few reasons I have chosen django SHOP again:
The framework is very well written and flexible, but it is still compact and uncomplicated. So I still feel comfortable to dig in that code-base.
django SHOP integrates very well with django CMS. In the future I would like to point this out even more, since this in my opinion is its biggest selling proposition.
django SHOP uses the built-in Django admin interface. While this interface is not perfect, it is the one every Django developers knows. Having a separate admin interface, as some competitors do, will most likely result in two different backends, as other third party modules certainly will continue to use the default Django admin interface.
Here some developers might argue, that the default admin interface is not intended for the common merchant. They only see programmers and database administrators as the audience for that interface. I don’t share this opinion. Even django CMS makes use of the default admin backend, so why shouldn’t a shop solution use it too? And with djangocms-admin-style it even looks quite pretty.
In the future development of django SHOP I would like to change the path of development into a new direction:
django SHOP should be less puristic and embrace a few other well accepted Django-Apps. One of the reasons I like Django over other Python frameworks, such as Flask or CherryPy is its “batteries included” approach. In my opinion a shop framework should behave akin to this Django philosophy. Having a recommended set of third party apps, does not mean that one has to use them under all circumstances. But if the django SHOP wants to gain a bigger audience, there shall be at least one solution containing the minimum features, which then work out of the box.
In Django, one can for instance replace the template engine against Jinja2, but the default installation just works out of the box.
As some might already have seen, I proposed an alternative method for overriding and instantiating the abstract models. My latest shop site already uses this pattern without problems. This for existing installations however means backward incompatibility, and one might have to write a schemamigration by hand.
django SHOP should abandon its unique connector for Payment Service Providers and try a more generic solution such as Django-Merchant.
The upcoming django SHOP example installation shall use modern main-stream frameworks/apps such as django CMS, Bootstrap, SASS,Django-Parler, Django-Registration, Django-Filer, easy-thumbnailsand AngularJS (sorry for being biased on the last one).
The example shop shall be integrated using App-hooks, the CMS-menu system, placeholders and product detail views editable in the frontend. Don’t get me wrong on this, I don’t want to prescribe what a programmer shall use, but having a meaningful list of third-party modules using working sample code, just drops the programmers cost to make decisions. This is not only a Django specific issue and this article points out very well why each time you need to make a decision, it costs.
Currently, django SHOP makes no assumptions on how to notify a customer via emails. Django itself has some built-in email sending functions, but these scale very poorly and must be handled synchronously while performing a HTTP-request. Moreover, nowadays customers expect order confirmations in HTML, possibly with embedded pictures. It thus should be possible to let the merchant edit such emails using CKEditor in combination with the Django template language. These emails shall be managed by the database and sent using an asynchronous function, possibly triggered by Django-Celery.
And if all these features are implemented, then one day, I would love to see this new django SHOP on Aldryn.