Django: Moving from XAMPP to Django questions - django

I've worked with XAMPP, WAMPP, MAMPP, etc and am starting to look at Django.
A majority of the work we do is very CMS orientated; although we've been told not to use third-party CMS' (mainly because of user's find them hard to use, and other issues), I've found that I can code a very simple CMS using Cake, CodeIgniter or one of the other PHP frameworks.
And yet, I'm getting increasingly frustrated with the amount of coding I need to do just to get something up and running, and I've been told that Django is a good Python framework to use. It also seems to get a lot of buzz from reddit.
I have some concerns and queries about moving from XAMPP to Django.
1) Security
Any web app should be coded defensively. Over the past few years we've seen a movement towards protecting against XSS, SQL injections, Cross site forgeries, session fixation, session hi-jacking, cookie hi-jacking; the amount of security one needs can be overwhelming.
What things does Django do to prevent/limit XSS, SQL injections, Javascript injections, and santizing input; one normally associates with securing PHP web apps? Is it something I need to worry about, or does Django do all this stuff out of the box.
2) What goes in the /www/ public folder?
In a manual I read it said not to put manage.py or the other .py stuff in the main webroot, so this means I put everything outside of the webroot; so what goes in there?
Do I put the /templates/ directory inside the webroot? How does the server know what to run?
3) Can I still use .htaccess on Django projects? I am familiar with Apache and often use it to do routing, or blocking off bad bots, but will using .htaccess still work?
4) Cronjobs
Do cronjobs still work with Python/Django projects?
5) Running Third party perl/other scripts
In PHP you can use other libraries such as the curl library, ffmpeg, ImageMagik as well as many others; can I still use these libraries with Python/Django?
6) Admin screen
Django gives you an out-of-the-box admin screen; is this only for development purposes or can it put live? I am concerned about any the security of the admin screen.
7) Integration with Discuss, Facebook, Twitter, OpenID, captcha, etc.
There are libraries in PHP that help integrate DisQuss, Facebook, Twitter; but is it relatively easy to do an integration with these and other third party apps?
8) E-commerce, SSL
Are there many e-commerce sites that use Django? I've seen a lot of CMS/Blog type software but not many e-commerce sites. By which I mean, shopping card, Protx/Paypal or Worldpay integration.
That's another thing; there are sandboxes for Protx, Paypal, Worldpay etc for PHP -- but are there any for Django?
9) Is it worth it?
Is it worth moving to Django from an XAMPP background? Will it really make things faster, or is that just marketing hype?
Thanks.

Security. The Django core team are very security-conscious, and have taken great care to make things like SQL injection impossible. The next version, 1.2, includes a whole new cross-site request forgery protection library. Obviously, you still need to be aware of these when developing your application, but Django does a lot to help you.
What goes under /www/public: Nothing. Django doesn't work via the normal Apache serving mechanism: it hooks into (preferably) mod_wsgi, which needs a single file which then tells it to run the rest of the code. The templates can go anywhere, and are pointed to by your Django settings file, but again aren't served directly by Apache.
.htaccess: You don't really need it, because of point 2: you're not serving things in a filesystem hierarchy. The best way to do it is to set up vhosts and manage things that way.
Cron jobs: Absolutely. Django is just Python, and you can easily run Python scripts via cron. Django allows you to set up custom command scripts which initialise the ORM and give you access to anything you would need.
Libraries: Again, because Django is Python, you get access to the huge amount of Python libraries that are out there. For curl, Python has urllib; for ImageMagick, it has PIL; and no doubt there are equivalents of ffmpeg too.
Admin: Again, security has been thought of from the beginning. Opinions differ as to whether you should use the admin only for your expert users, or customise it and allow access for all users; I've had a lot of success using it as the basis for my custom CMS interfaces.
Facebook, etc: Yes, there are libraries for all of these.
E-commerce: There is a whole e-commerce project, Satchmo, written in Django. Libraries exist to interface with all the payment providers.
Is it worth it? Only you can tell. My experience working alongside a range of developers who have moved from PHP is that they've enjoyed the experience and became much more productive.

On SQL Injections: Django uses an ORM, which takes care of SQL injection protection, and you will rarely write you own SQL. If you do, just follow the instructions on how to pass parameters to raw queries and prevent SQL Injections.
There is an entire chapter on the django book about security that should answer all your questions.
On what goes into /www/: anything that is not code? The concern is to not put the python code there.
On .htaccess: Yes, it should still work (for any non Django resources as Daniel points out).
On cronjobs: what do you mean?
On Libraries: Python - the language you will use with Django - is rich in libraries that probably provide the same functionality you are used to. This is a key point: you will need to learn Python well to benefit the most from Django.
On the admin interface: This is actually the thing that will probably help you the most, judging from your question. They are customizable (within some limits) and they really give the staff (it is not intended for public users, but for staff users) the basics of CRUD for your database models. It is a time saver. You might need to write your own templates for advanced functionality, but for most simple CRUD aimed at staff (which is usually the point of a CMS) it is very useful and easy to set up.
On integration: Check Pinax for a group of applications that provide extra functionality. There is a rich and diverse universe of integration solutions out there. It is not unusual to find questions here in SO about django + facebook and others.
On E-commerce: Check Satchmo out.
Is it worth it: Now, I have no experience with XAMPP. I know that I like Python better than both Perl and PHP (and Java, for that matter). I know that as a framework Django is simpler to use, faster to deploy than anything I used before.
My suggestion is the age old: go build a simple project and make up your own mind. You are the only one in position to decide if Django is the framework for you.
An older question on SO discusses some Django limitations. My answer to that might be helpful to you too.

I recently moved to developing any new projects in Django, coming from a PHP background. Here are my thoughts on your questions.
1) Security
Strings sent to templates is escaped by default, which takes care of most of that. Since you're using an ORM, SQL injection shouldn't be an issue unless you build raw queries for some reason.
2) What goes in the /www/ public folder?
Django doesn't use a file hierarchy for URLs like a typical PHP setup. The server knows what to run from your urls.py and settings.py pointer to the template folder.
3) Can I still use .htaccess on Django projects? I am familiar with Apache and often use it to do routing, or blocking off bad bots, but will using .htaccess still work?
As noted above, it works for static content just the same. For dynamic pages, you'd want to implement some other form of authentication or redirection for clients you want to block, as far as I know.
4) Cronjobs
There's no reason why you can't use cron for whatever, as you still have a normal Linux system.
5) Running Third party perl/other scripts
You'll want to use the Python versions of those libraries, of course. For instance
FFMpeg
PythonMagick
I replaced most of my need for Curl with the built-in urllib and urrlib2 libraries, but there is also PyCurl if you need it.
6) Admin screen
The Admin screen is intended to be used by your own admins, i.e. site staff. It may be possible to do so, but it's not supposed to be the scaffolding on which you build your public facing project.
7) Integration with Discuss, Facebook, Twitter, OpenID, captcha, etc.
There are a lot of people out there using Python and Django, and I haven't had any problem finding libraries. In my experience there is a bit less support for something than PHP, but what is there is often higher quality.
8) E-commerce, SSL
I haven't tried payment integration, so I can't say. Not sure about the other sites, but the Paypal Sandbox is run by Paypal, isn't it? I don't think it's related to what you're using on the server, so sure, you can access it like normal.
9) Is it worth it? Is it worth moving to Django from an XAMPP background? Will it really make things faster, or is that just marketing hype?
I moved to Django because Python is truly a more compelling language than PHP. Will it make things faster? I'm not sure what the advantages in that respect would be for Django vs.the PHP MVC frameworks. There are no magic bullets.
You do have to keep in mind that you're not just learning a new framework, but also a new language. There will be a bit of a learning curve if you've never used Python before. but I've found both Python and Django to be fairly easy to learn. The clean design of the language is fantastic and Django is veryt well designed, too. I do feel that it's boosting my productivity. I've found snippets for or articles about most everything I need to do in Django as I've been learning, so adapting has been pretty simple.

Related

Looking for the right Tools for developing a website with SPA components in Django

i am a new Webdeveloper and im struggeling to find the right tools and frameworks to use for the specific site i am building.
Its a site for managing all kind of information and documents about clients my firm cares for.
It consists of general information (like statistics etc.) that should be served synchronously and a client specific part that should be a SPA (mainly because i want to have a list of all clients on the side, so that the main part of the page updates when you click one).
My problem is , that there is so much information about that kind of stuff (but not specificly a project comparable to mine), so that i can't decide what the best approach would be.
I found those options so far:
Just serve everything with django and update reactive parts of the page with Ajax
building a dedicated Frontend and with Frameworks like Svelte or React and using Django as API.
Using these Frameworks just for the critical components that have to be reactive and serving everything with django
If i understand correctly, the cleanest way would be Nr. 2, but i would lose access to djangos form rendering with crispy_forms (which, for a website consisting mainly of forms, would kinda suck).
The same is kinda true for Option 3 i think, since the critical Elements are mostly forms. And as far is i know you cant render django forms as react components.
I was discouraged from using Option 1, cause it seems to very error-prone to build a SPA without a framework.
I would really appreciate some input from more experienced People like me to help me with the decicion which path to go down.
Greetings!
There are many options, but it all depends on your knowledge and deadline.
Don't try to make everything perfect at once. Make an MVP using the technologies that you are familiar with and show the working version to the management. I'm sure there will be many edits and improvements that they will want to implement.
If you need an advise about stack, then you can look at Django + DRF + Vue.js

Why are people using Django templates with webpack to connect DRF with ReactJS?

Am I missing something?
But I am really not getting the rationale behind most online blogs and tutorials suggesting to use a base Django template to render a ReactJS bundle (bundled from webpack).
In my mind, the point of using Django Rest Framework in the first place is to completely isolate the frontend from the backend and have something like Nginx serving an html file that would import the ReactJS library (like any other stndard html/js project). The ReactJS layer would then get or manipulate data solely through the DRF REST API.
It is like most developers treat ReactJS as a completely novel beast, when it can be simply treated as standard JS (with added steroids) that runs on the browser.
Can someone therefore explain to me what are the advantages of using the methods depicted by blogs such as Jonathan Cox and Owaislone ?
On one part, you're right. One of React's principles is to make it function like a Mobile app(that consumes REST API) which also compliments React-Native, so there's not much for the programmer to learn and pick up and can quickly develop an app if they are familiar with React. This way, you'd build the back-end to serve both the web app and the native mobile app without much rewriting or customizing.
Usually, people like keeping their code together, front-end and the back-end if they're just developing for the web. It's a common practice. Since Django is widely used and is also an open source framework amongst a lot of web-developers, there's a big community to develop tools or plugins for it. This way, they'd just have one server instance running and configure the backend to serve just the index.html page, and the routing is handled by the browser.
I, on the other hand, prefer the latter part, work on a team with backend engineers and mobile developers. We heavily rely on RESTful calls for our apps. So we keep our code base neat and isolate our backend from our front-end so each of us can work independently.
It's just a matter of preference really, Jonathan Cox and Owaislone both don't preach about the right way to develop React apps, they just demonstrated one of the ways React can be used.
Also, some backends have a lot of security and need to be configured to allow certain headers for making requests. It could make you look at your computer screen for days while you sit there wondering how to work around the problem and you're diving deep into the documentation for web requests. CORS is one of the problems when you isolate your front end and back end code. It's something that can totally be avoided if Django is serving the files.
I'd say you can go ahead and pick one that suits your need, isolate your React code from the backend if you'd want the back end to work on mobile apps too, saves a lot of time.

Best practices for layout out Angular/Django apps

I'm fairly new to both Django and Angular. I recognize this is subjective and there are likely many ways to do it, but I'm wondering what best practices people can recommend for laying out such an application. I'm specifically thinking of the case of rich, SPA with the backend being mostly or entirely a RESTful API server, but then I'd like to have a common approach for any apps that serve significant views from Django. (I haven't done enough to decide if the latter warrants using Angular or may be more trouble than its worth).
Specifically:
What are pros/cons of maintaining the front-end code in a separate directory/repository from the backend versus, say, inside a "static" subdirectory of the Django app? In my case I'm the sole developer for now, which has some impact on this decision, but I can still consider myself separate "teams" of back-end, front-end, designer, etc. in the sense that my workflow will put me in one of these roles at a time.
My setup is basically a development machine, SCM in GitHub, and hosted publicly on WebFaction (shared web hosting). I will down the line want to easily grab projects on different development machines, but the primary workflow is just one dev, one prod installation. That said, I'm interested in best practices in real-world projects as I hope a future job may be working with Django.
ADDED: Another point I'm very unsure about is whether the Angular app should/must be bootstrapped by Django. That is, should the front page be served by Django and injected with any data?
PROS:
Can configure URL paths and even API endpoints that change from dev to production, without any alternate config and without these being hard-coded in front-end.
This is maybe necessary for authentication? Unclear to me having not done this yet...
Allows use of tools like the Django debug toolbar app.
CONS:
Couples the front-end to the back-end. What If I want to swap out the latter? What if I want the front-end to work in a sandbox with mock data?
Seems to strongly favor moving all Angular stuff into the Django app layout. At the same time, I don't like having a mix of Angular partials in one place and Django template(s) in another. I am already resolved not to mix NG and DJ templates, as I don't believe much good will come of this.
I also started as solo developer on Django as BE with AngularJS FE. I've put AngularJS files in static folder and everything is fine.
Cons are definitely that you have FE and BE mixed up in one project, but I think that shouldn't matter since you are solo developer. Even if you decide once to hire additional developer (to split FE and BE work) your work wouldn't have any conflicts since one of you would work totally independent.
One of the pros for me is definitely I did entire login process via Django (templating as well) and once login went fine I served rest of the FE (entire AngularJS part).
For Django REST I've used TastyPie. It's great REST enhancement for Django and easy to set up.

Running Mezzanine on App Engine

I am looking for a blog solution to run inside a Django project deployed on the Google App Engine. After a bit of review I decided to try out Mezzanine v0.11.3. I've overcome the hurdle of getting it in project using the advice of others deploying on App Engine at this link: http://groups.google.com/group/mezzanine-users/browse_thread/thread/c8b13c41a3168c94.
Mezzanine is now showing up in the Admin, but clicking on Blog posts leads to a multi-table inheritance failure. I believe that this is due to multi-site support functionality in Mezzanine via use of the Django sites framework.
Has anyone overcome this issue? I'm going to try to use django-dbindexer but I'm not confident it will work.
*Update: as far as I can tell, the folks at AllButtonsPressed don't have any magic solutions to work around ManyToManyField issues yet, so I think that option is dead.
If no one knows a work around, do any of you know of a good blog solution I can run inside a Django project on the App Engine?
*Update: found this post Integrating Blogger into a Google App Engine App. Will investigate if this solves the problem.
*Current Status:
I have not been able to solve this problem and I don't think it is currently solvable. Thought I would share what I found through my investigations though; maybe someone out there can carry on and come up with a solution.
Options tried:
Bloog
I looked this over but it is a Python
solution, not a Django solution and I
didn't want to do the work to turn it
into one
Byteflow ( https://bitbucket.org/piranha/byteflow/wiki/Home ) notes:
designed to be standalone, will need a
lot of edits to settings.py,
inclusion of 12 additional apps and
overrides on account settings plus
hand tuning at every upgrade.
AppEngineBlog ( http://code.google.com/p/appengineblogsoftware/ ) notes:
written in appengine specific code,
not maintained, no example sites
available to see how it looks
Coltrane ( http://code.google.com/p/coltrane-blog/source/browse/ ):
simple blog constructed from standard
Django functionality no development
or support, basically need to use
this code as a way to develop your
own blog and go from there
Flother ( https://github.com/flother/flother ):
found via Coltrane comments, probably
embeddable without too much trouble,
requires 8 additional apps,the photos
and places components have
ManyToManyFields that would have to
be re-written or these components
disabled
Blogger API ( http://code.google.com/apis/blogger/ ):
use Blogger at whatever location you
wish to gain fully functional
blogging capabilities, then use
Blogger API to deliver content to any
other site you wish to display it
Flother came close to what I need but there is still a fair bit of uncertainty and effort there. I'm proceeding with the Blogger option as the only viable choice for me at this time.
Well, as far as I can see, there is no way to get Mezzanine running on GAE other than wading into the code and ripping out anything relating to a ManyToManyField (Sites support, Photos and ... something else. Can't remember what).
The only thing I could find out there that has the potential to be added to an existing project, uses only portable Django code (app engine specific) and runs on App Engine is http://www.allbuttonspressed.com/projects/allbuttonspressed . I haven't actually tried to integrate it yet because I'm going to see if the Blogger solution works.
I've been using bloog for two of my blogs without any serious troubles so far - there are few little quirks that make it mildly unpleasant sometimes but nothing that's been a deal breaker.
I use the Blogger solution and it works fine, especially if you're only one person and you run the whole site.
The problem comes when you want to others to help you out. Now every css and design decision needs to be sent to a programmer who hacks away at django templates. A CMS with a real WYSIWYG editor would allow you to ship off that work to marketing/design people and let you focus on the fun stuff.
I came across a decent review of the various blogging engines for Django, however, it's unclear how well they each integrate with GAE.
I have deployed Mezzanine/Cartridge in GAE succesfully but I have not documented it yet in github or something like that. It works using python 2.7 of course and django 1.5. Additionally it works with Google Cloud SQL, and the local file system GAE provides. It additionally works with google gmail facilities. For thumbnailing I am using local GAE functionality.
It requires several additional libraries like boto, but it works well.
See a short demo in midevocional365.appspot.com/

Web technology for a first small web project

I'm a C++ developer with basic Python skills. Here's the task, a friend of mine is running a small company and he asked me if I can make a website for him. I have no real deadline so I think it's a perfect opportunity to try sth new and do some web development.
User has to be able to add photos, change texts ect.
Do you think that Django would be an overkill for this kind of project? I have no experience with it. Perhaps I should try to customize some blog engine or Google Sites?
You may be interested in Google App Engine (http://code.google.com/appengine) which recently exhibited a rise in popularity. The application runs on Google's servers, eliminating the need to maintain Apache and worry about up-time. You basically get a Django-based solution with a data store, with an SDK which allows you to conveniently develop an application on your desktop and then upload it to appspot.com for everyone to use.
The documentation is great, and even if you eventually decide not to use it, the tutorial is excellent for getting you up to speed on Python and webapp design. There is also a codelab which contains a simple Wiki example.
If you need to set up quickly a very simple website, Wordpress can be the perfect choice.
Wordpress is born as a blogging platform, but in the newer version you can manage pages, contact form and so on. And you can find good plugins to expand its capabilities.
The administration interface of wordpress is clean and easy to use, the page or article editor is simple and powerful. Add an image in a post or in a page is easy and intuitive as in no other opensource CMS I've seen.
Django is a pretty flexible framework, it tends to scale well both up and down. It may be overkill to have to learn the whole API for just a simple site, but if you're looking to learn something new, and have some time to spare, then it's a fun platform to learn and work from. My suggestion would be to install the API and have a play around with it, read the Django book and see how you get on.
Maybe before diving into Joomla or Django a first step should be working with the technologies in a raw, pure way. Create a simple web page that excutes some server side script (python? php?) that retrieves data from a mySQL database and displays it. Throw in a little javascript too. Just so that you feel comfortable with the bare-bones fundamentals.
Then when you dive into the big frameworks and libraries, they won't seem so magical.
If you're really asking what the best tool for the job is, then you are going to have to give a little more detail than "first small web project." If what you are asking is more along the lines of you want to learn web application development and what you already know is C++ and python so what would be a good web application stack where you can leverage your current skillset, then here are some more suggestions.
Django is pretty cool. Every one has already talked about it here. As mentioned earlier, the google app engine is sort of based on Django.
Also, consider zope which is another python based web application container.
If you wanted to leverage your C++ knowledge instead, then consider Wt.
Why don't you take a look at the hello world examples for all three and decide which one looks the most interesting to you?
There are a multitude of website frameworks and kits that you could go with as opposed to starting development work from the ground up. It really depends on what kind of technology you want to go with, and how comfortable you feel with the language's potential. As mentioned above, there are things like Joomla, and If you want to stick to PhP frameworks, you could also use Drupal, which has a ton of documentation and support, and is relatively easy to understand.
If you want to venture into the Microsoft realm, you could look into DotNetNuke. It too is much like Drupal and Joomla, so it's a nice CMS framework, which you might feel more comfortable with since ASP.Net is based off of a programming language as opposed to a a scripting language, unlike Classic ASP or PhP. If you're going to go the Microsoft route, I also recommend taking a look at their BizSpark developer program - but that's more dependent on how serious your friend is on running his site as a business.
Then you also have a lot of things offered up by Google, such as their charts and visualizations -- which doesn't seems like something you're looking for, but for future reference, or cool little things like a map mashup.
It really depends on how much you're willing to learn and how much time you have and sometimes not having a rough deadline is the worst possible thing that could happen. Naturally everything starts to take longer. By the time you're done, the tech is either out of date, or you've taken so long that the business plan has changed.
using django it is easy, there is already an application for photo albums available at http://code.google.com/p/django-photologue/ it becomes with tagging too and maybe you just need to add some jquery effects to get done your site.
To get this done you just create a django project, add the applications to your settings, configure your urls and templates, and thats it.
Also i f you need a small version you can just use this code as a base of your new app.
have fun with django!!
sergio
Pylons is an excellent Python web framework based on WSGI standard. It has ported many of the features of Ruby on Rails so is great for rapid development.
I've been using it for a few years now combined with SQLAlchemy for my database layer and I've found it perfect for development of all my web sites.
It is easily good enough for production sites too.
The one downside I've found is slight complications getting it deployed on shared hosting but as long as you have shell access to your host, you should be fine.
You may try to install and customize Joomla (http://www.joomla.org/) It's full of stuff, easy to use and easy to customize also.
Everybody reaches for a framework, but, assuming this is running on Apache, why not just server side includes, and, since you have Python experience, Python CGI scripts that emit JSON for use in the UI by Javascript. By going with CGI/SSI you defer your decisions about framework and/or templating system until later, when you have more experience under your belt, but you should be able to get a reasonable amount of re-use of whatever Python code you write.
I'll cast my vote for Drupal (http://www.drupal.org)
I think LOVDbyLess might do exactly what you want. If all you need is basic blog and photo upload and a simple SNS, then check out this Ruby-on-Rails open-source thing. It's been evolving with new features and is pretty easy to set up.