As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Paypal payments advanced integration with Python-Django. I am creating the ecommerce site in django. I need to integrate the paypal payments advanced . But i can't see any tutorial for that integration.
You can use django-paypal app. It has pretty good docs. And here is a docs for django-paypal.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Hello this may be fresh and green.
I'm looking to build a responsive web, I am familiar with django however new to AngularJS
The backend I have in mind is Deployd.com which utilizes MongoDB
may I know the perks or downs of :
angularjs as a web framework as compared to django
from research it seems that angular has awesome data binding capabilities
if django, why? anything that django can do well as compared to angular
(other then angular being hard to master)
compatibility of angularjs + django
(no speculations, people with deployment experience only please)
Angular is a front-end javascript framework.
Django is a back-end server framework.
They aren't comparable.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am building my first web app with jQuery/CSS3/HTML in the front end that would GET/POST data from a backend implemented in DJANGO.
For this, I would like to build entities in DJANGO that are ReSTified. The DJANGO site https://www.djangoproject.com/ talks mostly about DJANGO MVC. I dont think I want MVC. Am I thinking right? If so how would I get DJango do ReST for me?
Moreover what style of architecture is better? MVC or ReST?
Can you please advise?
Regards,
Manav
These are completely orthogonal concepts.
Django is built on the MVC pattern (in fact a variant of that, better referred to as MTV). That simply refers to how the application is structured - in Django's case, with models, views and templates. If you're using Django, you can't get away from that.
REST is a pattern for how an application interacts with its caller - ie by using HTTP verbs and serving up (usually) JSON. You can't "build an application in REST", but you can write a REST application using any structure you like, including MVC.
Django itself is an MVC framework. However, there are apps available that will allow you to create an API for your models.
I believe that the most common ones are django-tastypie and django-piston
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Most web service tools support both SOAP 1.1 and 1.2 but what should be the version to choose when building a new WS?
I'm thinking WSDL 2 wasn't really all that adopted, but is that the case for SOAP also? Is SOAP 1.1 still considered the "de facto" standard when building SOAP web services or should SOAP 1.2 be used?
If the technology you're using permits it, then expose endpoints with both versions of SOAP.
SOAP 1.2 is a bit easier to handle. For example, you don't have to add the SOAPAction header to the request when using SOAP 1.2. The article below has a bit about it.
Request Differences SOAP 1.1, 1.2
The main thing you should check is to confirm that any prospective consumers you will have for your services will be able to consume 1.2. On a side note, if you want to ensure maximum interoperability, try and ensure that you can generate good concrete WSDLs for your services. Avoid included WSDLs, included XSDs as much as you can.
Tools like XMLSpy, SoapUI etc are going to have no issue with 1.1 or 1.2 and included XSDs, WSDLs.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am learning Django and has made a simple app. I was thinking of deploying that app to Google AppEngine.
What is the easiest way to do it (i.e. the one which involves changing as little code as possible)?
What is the best way to do it (i.e. the one which supports most of Django's features)?
I know similar questions have been asked here but none of the questions were asked after Nov 2010 (http://code.google.com/appengine/articles/django.html)?
If you want to learn full django with Google App Engine the project to recommend is www.allbuttonspressed.com
It implements full django with Google App Engine. If you want to learn the basics I suggest starting with SDK 1.6 and python 2.7 so that you realize that upgrading from python 2.6 to 2.7 without manually copying in the django you use will break django dependance.
I used much django with app engine but I'm getting out in favor of Jinja2 for template engine and WTForms for forms since with python 2.7 the google.db.djangoforms is not available so for more advanced stuff than basic forms you would want a form framework and WTForms seems OK though I didn't use all of it yet.
I hope some of these opinions from me be relevant.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've been using wordpress for a few years to run a couple of community based sites. one of them is a blog, while the other is more of an app, and I use wordpress for the admin feature only.
I'm thinking of moving to django as I'm familiar with python, I want to play with geodjango and I don't feel an urge or the need to do anything from scratch.
What are your thoughts on going from the wordpress blogging engine to the django framework in terms of programming, extensibility, scalability, speed, etc...
cheers
Django and wordpress cannot be compared, because, like it is said in django docs: "Django is a thing that you use to create things like wordpress".
If you would like to compare the speed:
Wordpress is really slow engine. One of the slowest. Sometime it needs to make 30 hits to database to show only one page.
In django it completely depends on how you white your app. You can make it slow, fast, or whatever, depending on your skills and functionality that you wish to receive.
So, your question can't be answered, because you must decide whether you are whilling to make your new blog from scratch or not. If you are, then Django would be a great choice. If not, stay on the wordpress, or try a different engine.
Wordpress is a CMS. Django is a web development framework. You cannot compare them in any reasonable way.
Everything that you get for free from Wordpress you will need to work for in Django, or at the very least install a pre-existing module for it.
The effects of scalability and performance will only depend on your implementation of the things you want to do in Django.