Ecommerce & Django
Chris Moffitt
I've been lurking around here for a little bit, trying to get a feel for
Django. I recently had the need to set up an eCommerce site for my wife.
After looking at all the alternatives, I chose OsCommerce which seems to
be the dominate Open Source ecommerce application. It is pretty mature &
has thousands of users. For the most part, it does what it says it does.
However, after I've spent the last couple of months trying to get it
working the way I like, the PHP warts & overall design are getting to me.
My site is now functional but I'm really scared to make any changes for
fear of the whole house of cards coming down on me.
I'm no PHP expert and won't go through the cons of the language but let's
just say that the more I worked with PHP, the more I wished I were working
with Python! So, I started looking at frameworks to setup my site using a
python based solution. After looking around, Django looks like a good
bet.
There are certain problems with OsCommerce which are going to be
non-issues with a Django site:
- Templating: In OsCommerce there are some options but they're kludgy and
can interfere with other pieces of code or add-on modules. Obviously
templating is a core part of Django.
- Search Engine Optimize URLs: Before diving into this project, I didn't
realize how many people worked so hard to get URLs looking nice so that
they show up higher in search engine results. As you can imagine, trying
to modify these through PHP can be painful. Django's URL capabilities
should make this another non-issue.
- Performance and Caching: Scalability and general performance are huge
issues. In stock OsCommerce, you can have nearly 100 db queries for 1
simple page. Without caching, you have some real performance headaches.
The caching capability & proven scalability lead me to believe that Django
will make these issues less of a concern going forward.
There are some concerns I have around Django for this application:
- Lack of ecommerce modules: There are lots of things like FedEx, USPS or
UPS shipping interfaces that are available that would have to be re-coded.
Also, payment processing modules would have to be created from scratch.
I don't think these are show stoppers but it is a challenge.
- Admin interface: I'm a little concerned about whether or not the
default admin capabilities within Django will be usable for store
management. I might have to come up with some other alternatives & it
feels like that's uncharted territory in some aspects.
- Deployment on shared hosts: This probably isn't too big a deal but it's
certainly not as straightforward or ubiquitous as PHP app deployment.
So, what is the point of my lengthy post? I know some people have started
(or have completed) work on their own stores. Is there any framework out
there that I can leverage or do I have to "roll my own?" I think it would
be a great thing for this community to create a store framework. The
Django plusses I mentioned would be awesome in a complete solution. I
think it would also attract a lot of users to the project.
Is there interest or any activity in this area? I'm willing to hack
through by myself but I think if there's anyone that is an expert, we
could move through this a lot more quickly.
Thanks,
Chris
olive
originaly wrote in OmniMark language (isn't it exotic ?).
It is pretty straightforward with Django, I have already achieve the
shopping cart management, user registration, shipping (Chronopost,
France), discounts.
But the model is far from generic unless you want to sell CDs, DVDs,
books, music and dance events and accessories.
It is not yet plugable, has not been port to Magic Removal branch (this
is the next step before going on dev).
I am wiilling to share my experience and participate to such a project.
Olivier.
olive
Michael
Michael
ZebZiggle
application, I'm not doing a shopping cart, just a lump sum
non-recurring payment. I was going to do all the HTTPS stuff myself to
the transaction handler for approval and I'll accept the "means of
payment" screens myself in Django.
It would be great to have all this stuff already done, but the
processing company only has examples in PHP (and java / asp/ cgi/ etc).
-Zeb
Kenneth Gonsalves
> It would be great to have all this stuff already done, but the
> processing company only has examples in PHP
fairly trivial to translate the php example to python - i have done
it in one case, although the processing company said it wouldnt
work, it worked
--
regards
kg
http://www.livejournal.com/users/lawgon
tally ho! http://avsap.org.in
ಇಂಡ್ಲಿನಕ್ಸ வாழ்க!
Chris Moffitt
> fairly trivial to translate the php example to python - i have done
> it in one case, although the processing company said it wouldnt
> work, it worked
I agree. I've looked at the PHP code for Authorize.NET and it definitely
looks pretty straightforward. I can't imagine it would take long at all
to get that coded into Python.
The main issue is that it would be nice to start getting some "synergy"
with all these apps in this space. I don't think I have the talent to
build a grand solution but I can do some of the pieces to help out along
the way. Maybe we can just start entering some of the code snippets and
modules into the wiki. If it grows into something more then we can try to
make it a project.
Just my 2 cents.
-Chris
arthur debert
am I all for it.
I've got no experience on e-commerce but there's a few things (I guess)
I may help with... I guess this would be agreat project...
I just suppose some "liberal licensing" would be nice (such as BSD or
the like)...
cheers
arthur
Jeremy Jones
What is it with wives and websites? Anybody out there (who's a male
married to a female) not building a website for his wife? I smell a
support group forming - Husbands of Work at Home Moms: the
Django Chapter. :-)
I originally intended the store I've built for my wife to be released
as open source, so I really tried to keep it generic in its innards.
However, after a slew of feature requests (from her as well as me),
I've broken the genericity of it and pretty much killed its open
source suitability. That being said, I'm planning on creating an
ecommerce framework that would be generic that could have components
plug into it (such as shipping cost calculation, integration with a
payment system, package tracking, etc). I'm more than willing to throw
my ideas and requirements on a wiki and post code there as we go along
and see how it evolves. This could be a killer app for Django.
- jmj
bruno desthuilliers
> On Thu, 13 Apr 2006 14:21:54 -0000
> "arthur debert" <deb...@gmail.com> wrote:
>
>
>>
>
> What is it with wives and websites? Anybody out there (who's a male
> married to a female) not building a website for his wife? I smell a
> support group forming - Husbands of Work at Home Moms: the
> Django Chapter. :-)
Too bad :(
I was about to express some interest for this would-be project, but I
have *not* built an e-commerce site for my wife, so I'm afraid I won't
qualify ? Err, wait, I've actually done an online gallery for her, does
that count ?-)
--
bruno desthuilliers
développeur
br...@modulix.org
http://www.modulix.com
Clint Ecker
Mine is on m-r, btw.
---
Clint Ecker
clint...@gmail.com
http://phaedo.cx
Chris Moffitt
> it
> would be easily expandable to just about anything. It will interact with
> Paypal's shopping cart system and USPS for shipping. It's a pretty
> straight
> forward port from my old PHP system, but a lot more fun and easy.
>
> Mine is on m-r, btw.
My site was actually going to have a similar functionality but I was
planning to use Authorize.net for payment processing. I also wanted to
extend some of the inventory mgmt functionality.. That's probably a
separate discussion.
It does seem like there's some interest in trying to get some sort of
community around this application for Django. If that's the case, how do
we want to get it set up? I think there are 3 options:
- Someone host on an existing site
- Setup a sourceforge project
- Setup a free python project on python-hosting.com
I'm sure there are a couple of other options too. Which brings us to
deciding how best to proceed. I don't really care but it would be nice to
start getting something setup. Anyone want to do it? If there's not a
better idea (or more willing volunteer ;) I can setup something at
python-hosting.com. The only outstanding question is the name of the
project. Any brilliant ideas? DjangoCart, DjangoCommerce, DjangoSell,
PyCommerce, PyCart, HusbandsSupportingWivesShops?
-Chris
arthur debert
+1 on this one. when getting started we better focus on the coding
right away, and python hosting's capabilities (svn + trac ) setup with
no fuss will be very helpfull (it seems).
" Any brilliant ideas?" not really...
djell, djuy , djart
Dave St.Germain
Jeremy Jones
"Chris Moffitt" <ch...@moffitts.net> wrote:
<snip>
> Any brilliant ideas? DjangoCart,
> DjangoCommerce, DjangoSell, PyCommerce, PyCart,
> HusbandsSupportingWivesShops?
>
DesperateCodeHusbands? No, wait...that just sounds bad....
- jmj
Chris Moffitt
> DesperateCodeHusbands? No, wait...that just sounds bad....
I like it. However, it's probably a little limiting for future use. One
question I have around the name Django. I noticed on the website that
it's copyrighted so we probably couldn't use it in the name. Is that true?
Also, I like using dj in it. It kind of goes with the music theme.
DJ Cart, PyDJ, Disco Cart, DJ Jazzy Commerce. I'm reaching here..
Once we get a reasonable idea for a name, I will volunteer to setup a free
python-hosting.com account to start collating code, documents & ideas. We
can always change the name later but you never know how these things can
stick.
-Chris
ZebZiggle
to define some common interfaces here. I just looked at the PHP code
and you're correct, it will be pretty easy to convert.
-Z
ZebZiggle
Django's last name.
-Z
Max Battcher
> I like it. However, it's probably a little limiting for future use. One
> question I have around the name Django. I noticed on the website that
> it's copyrighted so we probably couldn't use it in the name. Is that true?
IANAL and I am not connected with Django (other than usage), but
typically for open source projects the strict holding of a trademark on
the name is to dis-influence stupid companies (SCO, for one example)
from pretending to be the creators. I would be if you come up with some
nice open source project that use Django in the name you could probably
get it approved.
With that said, I have a stupid, but simple suggestion:
djecommerce, which is obviously superior to normal ecommerce in that g
(dje) is e + 2!
--
--Max Battcher--
http://www.worldmaker.net/
"I'm gonna win, trust in me / I have come to save this world / and in
the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track)
James Bennett
> I like it. However, it's probably a little limiting for future use. One
> question I have around the name Django. I noticed on the website that
> it's copyrighted so we probably couldn't use it in the name. Is that true?
Minor nitpick: it's a trademark, not a copyright. In the United
States, at least, names can't be copyrighted.
Also, in personal projects I tend to pick names of other jazz artists,
following the trend of "Django" and "Ellington"... for example, I've
got a project right now called "Coltrane".
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
bruno desthuilliers
> On 4/13/06, Chris Moffitt <ch...@moffitts.net> wrote:
>
>>I like it. However, it's probably a little limiting for future use. One
>>question I have around the name Django. I noticed on the website that
>>it's copyrighted so we probably couldn't use it in the name. Is that true?
>
>
> Minor nitpick: it's a trademark, not a copyright. In the United
> States, at least, names can't be copyrighted.
>
> Also, in personal projects I tend to pick names of other jazz artists,
> following the trend of "Django" and "Ellington"... for example, I've
> got a project right now called "Coltrane".
>
May I suggest 'Emmet' ? (Emmet Ray was a great guitarist and a huge fan
of Django)
My 2 cents...
olive
My possible contributions:
- on-the-fly PDF invoice creation using ReportLab (or another PDF lib
?)
- Advertising management
- links with others Web Services (Amazon ...)
- The Shop as Web Service ...
...
Nebojsa Djordjevic
> There are certain problems with OsCommerce which are going to be
> non-issues with a Django site:
PHP-style of i18n handling, really a show stopper for me.
Django i18n rocks, but we must add l10n stuff also (money/number formatting, currency support, etc).
> Is there interest or any activity in this area? I'm willing to hack
> through by myself but I think if there's anyone that is an expert, we
> could move through this a lot more quickly.
I'm willing to help, although I don't have lot's of experience in the e-commerce applications.
I have (a typical) on-line shop project in the near future so count me in.
Maybe we can create django-ecommerce mailing list for this?
--
Nebojša Đorđević - nesh
Studio Quattro - Niš - SCG
http://studioquattro.biz/
http://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/ | http://djangoutils.python-hosting.com/
Registered Linux User 282159 [http://counter.li.org]
Kenneth Gonsalves
> What is it with wives and websites? Anybody out there (who's a
> male married to a female) not building a website for his wife?
i build websites for me in my wife's name ;-)
Kenneth Gonsalves
> Also, in personal projects I tend to pick names of other jazz
> artists, following the trend of "Django" and "Ellington"... for
> example, I've got a project right now called "Coltrane".
jazz - django is a female western gunslinger - wonder if angelina
jolie's image is copyrighted? (lara croft)
Michael
Jeremy Jones
Kenneth Gonsalves <law...@thenilgiris.com> wrote:
>
> On Thursday 13 Apr 2006 11:12 pm, Jeremy Jones wrote:
> > What is it with wives and websites? Anybody out there (who's a
> > male married to a female) not building a website for his wife?
>
> i build websites for me in my wife's name ;-)
>
Dude. That was just wrong. You're giving away geek trade secrets. As
long as they don't know that we're building the sites for ourselves, we
score brownie points for the effort. You'd better hope none of our
wives are reading, or we're done for.
- jmj
Jeremy Jones
+1 on reinhardt
- jmj
Jeremy Jones
Looking forward to working on this. Here's a rough sketch of what I
was planning on building (and have actually begun work on). I don't
know if this will be palatable to any of the rest of you, or not. My
main purpose for building this app was (and is) to provide cheap hosting
for an easy-to-use ecommerce site. If what I'm working on can be of
use to the project we're talking about, I'm happy to contribute.
- User: I've started using Django's builtin User stuff to manage
users. A user is a someone who manages one or more stores.
- Multi-store. This is pretty self-evident. Stores can have products,
product have a names, price, images, descriptions. Probably ought to
have product categories in here on a per-store basis.
- Flexible product attribute management. The base attributes that a
product should have are name and price. But it would be nice to allow
store managers to create products with varying attributes. For
example, a shirt could use a "size" attribute with a drop-down list of
"small", "medium", "large" whereas a coffee cup doesn't need that.
- per-store store management interface. (Yes, I intended to put two
"stores" adjacent to one another.) Right now, the Django admin
interface is not suitable for allowing multiple users to manage only
the stuff that belongs to them. This multi-user, multi-store site needs
an admin interface that will keep users from mucking with other users'
stores.
- Integration with a payment system. I already have my wife's site
working with PayPal. That was a snap. I think it'd be great to come
up with a plugin system to allow integration with any payment system.
- Integration with shipping providers.
- Catalog upload. It'd be cool to allow someone to upload a csv of
their products. However, with "flexible product attribute management",
this may not really be that feasible.
- Tax calculation module. Users should be able to create certain rules
for what rate to tax which items. In the States, the rule would be
mostly determined by which state the order is coming from.
- Coupon system. Users should be able to create coupon codes with an
expiration date, percent or absolute price discount, expire after N
number of uses.
I don't really need this, but it may be kind of cool:
- Inventory management. Either totally manage inventory online, or
provide some mechanism for integrating with some inventory systems.
That's all I can think of for now.
- jmj
Chris Moffitt
Michael -
Looks like a great start. Do you want me to setup a mailing list? We're
getting enough interest that I think it would make sense. Give me the ok
& I can do it & send out an announcement to this list.
-Chris
Chris Moffitt
> I don't really need this, but it may be kind of cool:
>
> - Inventory management. Either totally manage inventory online, or
> provide some mechanism for integrating with some inventory systems.
>
>
Authorize.net so I can work to get a module setup there. I also like your
idea of an inventory mgmt system. If we can extend the inventory
capabilities to a little more than just tracking what was sold, I think
that could be a really nice advantage. Obviously we need to make sure
this doesn't turn into a full-blown ERP system.
Hopefully we can get something setup here pretty soon & start channeling
this energy towards structuring the project.
-Chris
Brice Carpentier
I think that would suit the project just fine, wouldn't it ?
--
Brice Carpentier aka Br|ce
Jeremy Jones
Googling for '"too commercial" jazz' turns this up:
http://www.redhotjazz.com/louie.html
It's Louie "Satchmo" Armstrong. I could go for Armstrong, but I think
"Satchmo" is cooler.
- jmj
Wilson
Jeremy Jones
Michael <michael....@gmail.com> wrote:
I just put up what I've coded so far on
http://jeremy.pitterpatprints.com/
I just created that subdomain, so it's not in the DNS for work yet, but
it is from home. I don't have a shopping cart built in there yet.
Another question is whether to allow products from multiple stores to
populate the same shopping cart instance. I'd think not.
Anyway, this site is butt-ugly. Nothing like the one Michael has put
up, but I hope it gets across some of my intentions.
- jmj
arthur debert
where the order relates to a download. of course, this could get pretty
complex if you add in things like serial numbers, versions, etc...but
we can start simple.I (personally) would like this, and I guess quite a
few of the early adopetrs migh want to sell software / digital goods (I
don't know, maybe their wife are selling e-books or something)
Jeremy Jones
{% block run_for_your_life %}
So which DRM mechanism should we use?
{% endblock %}
Just kidding. I think this is a great idea. This could be handled
a couple of ways. If you want immediate download upon completion of
payment, it'd have to be a there'd have to be a product type column so
and we'd need a way to distinguish what needs to happen with different
product types. Something I had thought about but failed to mention in
my ideas is a checkout sequence. I think it'd be nice to be able to
specify on a per-product basis what order of pages the buyer should
traverse when they checkout. This could just tie directly into that.
Maybe have some canned product types and have them associated with a
their own checkout sequences.
Another way this could be handled is through a shipping/order
fulfillment plugin. When all the payment stuff has been gotten out of
the way, a "ship event" could be triggered. The triggered event
could do something useful like pushing data to your shipping
provider (I really don't know how this part works at all), or
preparing print labels. In this case, it could email the customer
with a URL of the download.
Then there's the issue of how many times to allow someone to download
the same file? Or whether to require that the downloader's cookie
match the buyer's cookie?
Regardless, great idea.
- jmj
arthur debert
"monk"!
Clint Ecker
Item
-- short_name(slug)
-- long_name(char)
-- active(bool)
Sub_Item
-- Item(foriegn)
-- Color(foriegn)
-- Size (foriegn)
-- Type (foriegn) # what kind of shirt is it?
-- unit_price (float)
-- num_in_stock (int)
Color
-- name (char) # something like "Black"
-- html_equivilant (char) # something like #000000
Size
-- short_name # like "S"
-- long_name # like "Small"
Type
-- name # like "Jerseys 100% Cotton Large"
-- weight (float) # I use it in pounds. so it's usually something like 0.23
I also have Image and Coupon models along with some helpful methods in the Image models for doing thumbnails and stuff that I needed to develope when doing my templates. Anyway, I've got a basic shopping cart about 60% of the way done and my shirt_detail views and stuff, showing stock matrices and stuff.
I'd be happy to share anything I've come up with to help this project out!
---
Clint Ecker
clint...@gmail.com
http://phaedo.cx
Glenn Tenney
other volunteers used EZ-Cart for a few ecommerce sites and loved it.
You might want to see the features it has... See
http://www.cf-ezcart.com/
--
Glenn
bruno desthuilliers
>
> Looking forward to working on this. Here's a rough sketch of what I
> was planning on building (and have actually begun work on). I don't
> know if this will be palatable to any of the rest of you, or not. My
> main purpose for building this app was (and is) to provide cheap hosting
> for an easy-to-use ecommerce site. If what I'm working on can be of
> use to the project we're talking about, I'm happy to contribute.
>
> - User: I've started using Django's builtin User stuff to manage
> users. A user is a someone who manages one or more stores.
We also need to manage customers, and there must be some login and
permission stuff about them...
> - Multi-store. This is pretty self-evident.
Can be nice, but not a necessity for me. -0 on this.
> Stores can have products,
> product have a names, price, images, descriptions. Probably ought to
> have product categories in here
Anything about manufacturer ?
> on a per-store basis.
>
> - Flexible product attribute management. The base attributes that a
> product should have are name and price. But it would be nice to allow
> store managers to create products with varying attributes. For
> example, a shirt could use a "size" attribute with a drop-down list of
> "small", "medium", "large" whereas a coffee cup doesn't need that.
Must also have pricing according to attributes (or attributes
combination), and shipping costs etc,...
> - per-store store management interface. (Yes, I intended to put two
> "stores" adjacent to one another.) Right now, the Django admin
> interface is not suitable for allowing multiple users to manage only
> the stuff that belongs to them. This multi-user, multi-store site needs
> an admin interface that will keep users from mucking with other users'
> stores.
Django-admin would not be enough to have a usable system anyway (I mean:
usable by a normal human being !-).
> - Integration with a payment system. I already have my wife's site
> working with PayPal. That was a snap. I think it'd be great to come
> up with a plugin system to allow integration with any payment system.
s/great/mandatory/
Michael
Jeremy Jones
Michael <michael....@gmail.com> wrote:
> OK, OK, OK
>
> finally got working trac
> http://dshop.mine.nu/trac <http://dshop.mine.nu/shop>
>
> soon will put sources in svn
>
I setup a table of the requirements I batted around earlier. I put in
a "manditoriness" column". If you think a feature is just not
important, please note it. If we want to drill down deeper, we can
change the feature column to a WikiCamelCase and let it create a page
for each feature.
http://dshop.mine.nu/trac/wiki/RequirementsDoc
- jmj
Michael
get the sources:
svn co http://dshop.mine.nu/svn/dshop/trunk
I've put there the whole project -just change your db entries and
MEDIA_ROOT
ZebZiggle
checkout and credit card processing. I'll happily do the SkipJack
driver.
-Z
Viktor
Why not integrate this ecommerce system with TinyErp
http://tinyerp.org/. i.e. use django as a web interface for TinyErp.
TinyErp is written in python, well tested and for a long time used in
production.
It has his own ORM, not as sophisticated as Django's, but has very
similar table naming convention (so it won't be very hard to integrate
these two applications).
Ian Maurer
I would like to see payment processing become a general purpose
library that has no Django dependencies.
Maybe we can model (or at least learn from) the Perl OnlinePayment
library that is here:
http://420.am/business-onlinepayment/
I have also collected a few other links here:
http://del.icio.us/imaurer/creditcards
-ian
Chris Moffitt
> I would like to see payment processing become a general purpose
> library that has no Django dependencies.
>
> Maybe we can model (or at least learn from) the Perl OnlinePayment
> library that is here:
>
> http://420.am/business-onlinepayment/
>
> I have also collected a few other links here:
>
> http://del.icio.us/imaurer/creditcards
>
> -ian
>
>
Thanks for passing these links on. I think it makes sense to abstract
out some of the payment processing so it would be python generic. I've
taken the liberty of posting these links on our wiki.
http://dshop.mine.nu/trac/wiki
If you're interested, check out our separate google group for this project:
http://groups.google.com/group/django-ecommerce/
Thanks.
Wilson Miner
> Here's basically what I have... the thing with t-shirts is that you can have
> a base product, the design... and it's got several subproducts Medium Black
> shirts, Large black shirts, Meidum blue. And they've all got different
> prices attributed to them, like an XXL shirt would be a little more
> expensive than a XL shirt. For shipping and such, each shirt (or item)
> needs a weight associated with it.
For what it's worth, this is very similar to what I came up with for
handling a jewelry catalog. Each product had a base "design" model
with all the basic information (name, description, etc.) and some base
values (base price, base shipping weight, etc.). Then each design
could have multiple styles, each of which had their own (optional)
price and weight, which would override the base values if you ordered
that style. This allows you to set up really simple products with one
price, while still having the flexibility of multiple configurations
and price levels as an option.
ZebZiggle
ZebZiggle
I agree to keeping the payment processing as a non-django component.
I'll look at the links referred. Thx for that!
-Z