I'm working with a Satchmo store installation that should reside within an existing django project. This django project has its own settings.py, local_settings.py, templates as well as templates for some of the various apps that have been installed.
Can you please suggest the steps to integrate satchmo store inside an existing django project with satchmo store using the django projects settings.py, local_settings.py, templates and database?
I recently had to do something similar. But it depends on what you want to actually do. I presume the most valuable part of Satchmo is the payment processing. It was for us. A cart with products and inventory is actually pretty simple to pull off with django. Satchmo was pulled apart into separate apps, and the payment processing was made into django-bursar (https://bitbucket.org/bkroeze/django-bursar) (I along with others have forked it to add some functionality).
Taking that app and connecting to gateways for payment processing is fairly straightforward.
Related
I want to build a django oscar ecommerce web app.
A Required fearure in this app is a content management system, therefore I want to integrate django-cms in my app. After some research I found apphooks but there is no guide on google for integration of django-oscar and django-cms.
Can anyone tell me the way to solve this issue?
Not sure if you still looking for this solution, but i created a content management system by combining Django-CMS and Oscar Commerce with tons of additional features including user messasaging, docker support, graphql, support for several payment providers and more.
https://github.com/bastianhilton/alternate-cms
Depending on what kind of integration you want to do, you should check Wagtail which is another Django CMS, well documented, the community seems to be growing up.
Adding Wagtail to an existing project is explained here and works well with a django-oscar project.
I'm new to django and plan on building a large django project.
I'm starting to implement cookicutter django after reading through "2 Scoops of Django" but still have some questions on structuring a project.
I've setup my project, we'll call it 'business_proj'. In business_proj I started an app called 'accounting' this might have an accounting dashboard for users in the accounting security group. Now, what if I want to have apps that belong to accounting, such as 'invoices' and 'purchase_orders'? Should I create those apps inside my accounting app? Or should I create all my apps in the main project root? The way I've started doing it is creating child apps inside of their parent apps but some parent apps are so big that even this gets messy. Is there a better way to do this? Thanks
If you have gone through Two Scoops of Django then you should probably check out Django Cookiecutter which has been created by the authors of this book.
Django Cookiecutter is an excellent boilerplate for starting a Django application both for personal use and for production.
They also have excellent documentation which will help you with the best practices for Python and Django coding.
Check out: Django Cookiecutter Git Link
I suppose it depends on the tastes of each developer. I split each funtionality in a separate app for example. I have never used child apps. Excepts when I work with Django Rest Framework. With Django Rest Framework I create a child app of each up for REST funtionality.
I'm about to develop a web site that works closely with database attributes.
It needs to fetch required data from the db based on search criteria and to display them as table.
I was studying django and feel that I'm ready to start the development process.
Now, I need to decide rather I choose to go with Pinax or just pure Django with apps that suit my needs.
i do want some social functionality like sending notifications to friends and maybe later a forum on site.
What do you think? should i go with pure Django or should i give Pinax a try?
Pinax wont run without django so you need to use django either way. If you want to create sitw with social networking feature pinax is a good option. If you just need user management, django has it built in.
I am looking for a guide to migrate Django project to Google App Engine and use Google's datastore. The most of the guides I found were linked to Django-Appengine using Django-nonrel (but I want to use GAE's native support).
Going through GAE getting started guide, it says:
Google App Engine supports any framework written in pure Python that speaks CGI (and any WSGI-compliant framework using a CGI adaptor), including Django, CherryPy, Pylons, web.py, and web2py. You can bundle a framework of your choosing with your application code by copying its code into your application directory.
I understand that I won't be able to use some features of Django in that case (majorly the admin feature) and would also need to restructure the models.
From other reading, I also found that latest SDK of GAE now includes Django 1.3 on Python 2.5.
I tried to put all files from my Django application to a GAE project, but couldn't get it all to work together.
Please provide some basic guide using which I may migrate my Django project to Google App Engine's code.
Thanks.
For an existing Django app, using django-nonrel is the simplest approach; it is very popular so you should be able to find help with specific errors you get quickly.
Another approach is written up in this article: http://code.google.com/appengine/articles/pure_django.html -- it goes the other way, taking an App Engine app that uses Django for dispatch, templates, and forms, but not for models, and describes how to make it run in a native Django environment. Maybe you can glean some useful hints for your situation from it.
I've used django-nonrel, which behaves pretty much like django, except that operations with JOINs will return errors. I've basically worked around this by avoiding ManyToMany fields, and essentially building that functionality manually with an intermediate table.
So far I've ran into two problems with Django-nonrel:
1. No access to ancestor queries, which can be run in a transaction. There's a pending pull request for this feature though.
2. You can't specify fields that are not indexed. This could significantly increase your write costs. I have an idea to fix this, but I haven't done so yet.
(Edit: You CAN specify fields that are not indexed, and I've verified this works well).
2 (new). Google is pushing a new database backend called ndb that does automatic caching and batching, which will not be available with django-nonrel.
If you decide not to use django-nonrel, the main differences are that Django models do not run under App Engine. You'll have to rewrite your models to inherit from App Engine's db.Model. Your forms that use Django's ModelForm will need to inherit from google.appengine.ext.db.djangoforms instead. Once you're on App Engine, you'd have to port back Django if you ever take your app somewher else.
If you already have a Django application you might want to check this out. You won't work with App Engine's datastore but Google Cloud SQL might fit your needs.
I have an application built with Django. Part of it relies on data that I aggregate from other websites. Wondering how I should approach building the scraper/aggregator.
The advantages I see of building it as a Django app is
the ability to use Django's models & database API
the ability to use Django's other methods
On the other hand I think the disadvantage would be scalability in the long run.
Should I build the scraper/aggregator as an app in my Django project or as a separate script that runs on its own?
Would love to hear your thoughts.
Neither of your points require it to run within Django. And since it will not be dependent on the web/HTTP interface, having it be a separate module is the only option that makes sense.
I just have published a Django app django-dynamic-scraper on GitHub, which is build on top of the scraping framework Scrapy and where you can build Scrapy scrapers in the Django admin and use Django model classes to store your scraped data, maybe this is of some use for people with similar problems.
If it's a django app, it will only run when someone loads the page. That could slow the loading.
Making another script could be a nicer idea but could produce inaccurate data.
I think it actually depends on the context.