I am new in Django so I have a question for start working with it. Now I am writing my apps in PHP and Yii2. In Yii, I have to separate apps (frontend and backend) with two auth mechanism. But I want go to Python with Django I know that is admin site but I dont know how to clone functionality like Yii2. I need two different pages for login users (admin and normal users) and 2 panels for them.
Should I use two difference instances of admin site or write it manually?
You don't need to have two different instances. Since the admin pages (backend) are shipped with django out of the box, you can just start building the frontend. Be sure to register your sites to the admin pages for the models you are using.
I recommend going through the great django documentation:
Django Documentation
The django-admin is pretty straightforward and works great out of the box. You are somehow limited in terms of customization though. It depends on what your goals are an how much functionality your administration needs.
More infos here.
Related
I have been using django for a while, but there is something im not quite clear on.
How big should a django app be. If for example a django app should only be user authentication or if it should be an entire website in one app.
If I have a project with several apps and each app is a whole website with a lot of code, is that the way it suppose to be or should all apps related to a single site within a project ?
Im thinking of creating one django project for each site, but im now wondering if I should be creating one project where each app is one site. Can anyone please comment on this, what it the preferred way to do it ?
In the django documentation one app is only used for a poll, so it seems to be that, according to the documentation, that each app should be some part of functionality on the site.
An app is a submodule of a project which contains functionality (views, models, urls etc) for a specific part of the larger site and is as decoupled from the other apps as possible. The project as a whole is the website and your apps make up the separate parts of functionality for your site.
If your sites are going to basically contain the same functionality, it might be worth looking into the Sites framework which django provides.
So taking the polls example further.
Lets say the website is a survey site. There would be the polls app, which would contain the relevant models and views for creating and recording poll results. Then you might need to view the data, so you could create an analysis app, which would store the views for displaying dashboards and contain functions for data processing. Then we could take things a bit further, and have users be able to log in and see their own results (and give us the chance to link users to poll results), so you would make an accounts app, which would hold views for logging in/out, maybe a profile page etc.
So each of these different parts of functionality would be separated out into distinct apps, which would make up the project (site) as a whole.
If the apps have been decoupled properly, you could reuse the different apps in other projects (e.g. the accounts app could be dropped into a new project do provide logging in/out functionality)
In my experience so far, an app should be a reusable entity. There many guiding principles for choosing what to go and what not in an app. Separating authentication is one example. A projcet is one big collection of may apps and a reusable app can be in many projects.
Nowadays, there is a trend to move to micro service architecture, which is next level of separation of functionality with each service doing best one thing.
Each project is a unit in itself, not an individual app. So you host the project, not the app. I recommend using different project for each site and using micro-service architecture. A lot depends on your existing codebase too.
I wrote a django project that is some kind of a CMS.
Now, I want to be able to create several accounts that use that CMS, Each with a different database.
For example, user can create himself an account in my service - and he will get a site based of that CMS.
How can I get started doing this?
Look at the django docs https://docs.djangoproject.com/en/dev/topics/db/multi-db/ There are is useful example. Another good article https://thenewcircle.com/s/post/1242/django_multiple_database_support
Unfortunately Django is not suited to dynamically switch databases at runtime. You either have to implement really hackish solutions (like mentioned in this question Django multiple and dynamic databases ) or to go with several independent Django instances which you will have to start up on your server dynamically.
A much simpler solution would be to stick to one database and distinguish different users' content by some other means, like Django Sites framework. The only problem with this approach in my opinion is that you will have to carefully set up your admin site configuration, so that users don't see each other's objects (in case you planned to use built-in Django admin).
I want to switch from Rails to Django, to broaden my mind, and a question has bobbed up in my mind.
My Rails app is quite a mess, since my hobby-based development approach is a patch-and-glue one. I have seen very early that Django divied between a project and an app. According to their site, a project is made of many apps, and one app can be used for many projects.
This intrigued me, since that would made the lines between my site's areas clearer. I tried to find some more examples and information on that, but I couldn't answer my question, which is:
How big/small is such an app? Are they able/supposed to interact closely?
It is, for example smart to have one app to deal with user's profiles, and another app to deal with blog-posts and comments, from those users? (In my site, a user can have several blogs, with different profiles). Or are they meant to be used otherwise?
A django App is a fancy name for a python package. Really, that's it. The only thing that would distinguish a django app from other python packages is that it makes sense for it to appear in the INSTALLED_APPS list in settings.py, because it contains things like templates, models, or other features that can be auto-discovered by other django features.
A good django app will do just one thing, do it well, and not be tightly coupled to any other app that might use it. A wide variety of apps are provided with django in the contrib namespace that follow this convention.
In your example, a good way to devise apps is to have one for user profiles (or use one of the many existing profile apps), one app for blog posts (or one of the many that already do this), one app for comments, separate from blog posts (again, you can use an existing app for this), and finally, a very tiny app that ties the three together, since they don't and shouldn't depend on each other directly.
The purpose of using app's is to make them reusable. Django likes DRY principle DRY stands for DO NOT repeat yourself
An app should be as small as it can, and loosely coupled. So, for an app should not need another app to work properly.
Django recommends writing an app for each table (well, not always, but as soon as you want to grow your app, you will definitely need to divide tables to pair apps. Or else you will have hard time for maintaining your code.)
You can, for example, create an app for users, an app for sales, an app for comments, an app for articles. It will be easier to maintain your code and if you have done it right, you can use the app in other project with a little (if any) modification in the app.
Project's are, compilation of app's. Users app, articles app, comments app can come together an make a project, or in other words, a website.
If you want to learn django, I suggest you to check out:
http://www.djangobook.com/
http://docs.djangoproject.com/
One word of advice, do not, in any case, copy/paste. Not only your code has great chance to fail, but you will not know what the code is doing. If you are going to use someone elses code in your project, at least type them, this will make you understand what the code is doing, or at least, it will give an idea.
Writing your own code is always better for maintance, but this does not mean that you should reinvent the world, you can use libraries, look at their documentation to use it properly.
Documentations, tutorials are you best friend.
Good luck.
A project is basically a place where your project lives...in your project you setup your url's, project settings, etc.
An app defines its own data models and views to be used within a project. You can move these between projects if you like.
I highly recommend running through the tutorials from the Django site as they will show you what a project and app are, how to manage both, how to use the admin panel, how to make the app usable in multiple projects, etc.
A portal = A django project
A ads system, gallery photos, catalog of products = Apps
I want port some my Python scripts into web apps so that others can use it and I'll use some sort of web framework. I've been playing around with Django lately but it doesn't have the basic user registration, email verification stuff built in and one would probably end up using django-registration.
Almost all web applications require you to create an account, verify your account by clicking that verification link in your account and so on. One would save a lot of time if he could just skip past the part of setting up authentication, verification, the usual log-in and log-out pages and get to part of doing the "core" part.
Has anyone come across a pre-configured Python web-framework (Django would be nice) that does the all usual basic stuff? Django has that contrib.auth bit you can add django-registration
(I hope this question sounds reasonable.)
Thanks.
Take a look at Pinax ( http://pinaxproject.com/ ), which consists of a set of Django apps that take care of some of the most common tasks. Including the user registration one you outlined.
However, this is actually not very difficult to build. You are right, most sides need it, but implementing it even from scratch is pretty easy.
web2py take a look at Access Control Chapter in http://web2py.com/book
I'm supposed to build some Django apps, that allow you to administer multiple sites through one backend. The contrib.sites framework is quite perfect for my purposes. I can run multiple instances of manage.py with different settings for each site; but how should django's admin deal with different settings for different sites, eg. if they have different sets of languages, a different (default) language? So there are some problem s to face if you have to work on objects coming from different sites in one admin...
I think settings.ADMIN_FOR is supposed to be quite helpful for cases like this, but theres hardly any documentation about it and I think it's not really used in the actual Django version (?).
So any ideas/solutions are welcome and much appreciated!
Thanks a lot...
There is an old blog post by James Bennet which might be helpful:
Create a new Site object in your admin for each domain, and put the id of that Site into its settings file as SITE_ID so Django knows which site in the database corresponds to this settings file.
In the settings file for your original site (the one with id 1), add the other sites’ settings files to the ADMIN_FOR setting, to let Django know that this one instance of the admin application will handle all of the sites.
As documented ADMIN_FOR (for which i can not post link) should be a tuple of settings modules much like INSTALED_APPS is a tuple of django app modules.
Note that blog post is from 2006 so it uses a bit outdated API.