I am reading Django documentation (https://docs.djangoproject.com/en/3.0/ref/contrib/contenttypes/#module-django.contrib.contenttypes).
I did not understand content type app, the Django docs describe it as below
Django includes a contenttypes application that can track all of the models installed in your Django-powered project, providing a high-level, generic interface for working with your models.
Can someone explain this from beginner perspective ?
I have experience in developing websites in Django but never touched in this app.
Example: you want to make user-related logging, something like an audit module in user profile. You have dozen of models that could be logged. User, Order, Task, Product, etc.
So your main model will be something like AuditEntity.
How to make it general for all possible current (and future models) that could be logged here? Which type of field do you need?
The answer is Django contenttypes.
If you want - try to implement such a model's structure to understand how it works.
I think that what is trying to tell you is that you can have different content (in blocks, as it is organized in "blocks" and it is very "module friendly", I hope to give the idea), this content is made up of different things, especially models, let's just say that they are like big classes of things needed in your application (don't judge this expression, I know it is not professional but is the more beginner friendly I can write now), hope this makes more clear!
Related
I have a site that - other than the signup process - will be only used by logged in users. It's my first Django site, and I'm wondering whether I can use the Django user model (slightly extended) to work with all my users, or should it only be used for administrative users such as myself?
Apologies if this is a stupid question. Additionally, and either way, what's the best way to manage user registrations? It'd be awesome if this were built into Django, but it's not, and I read django-registration is relatively abandoned. Any recommendations welcome.
You can use the Django User model for all your users (of course, it all depends on your actual scenario, but it sounds like it could work in your case). You can also extend it (e.g. add more fields): https://docs.djangoproject.com/en/dev/topics/auth/customizing/#extending-the-existing-user-model
Is it the best way to manage users? Again, it depends on the scenario, but it would still work for a significant portion of Django projects.
I read django-registration is relatively abandoned
I haven't used it in a while, but I'd guess it would work with the current Django version. In any case, it's a fairly simple and robust application, so you might be able to tweak it to make it work (you might even decide to commit the changes back to the repo, in the open source spirit).
I was just talking to an advanced developer friend of mine about this. He said using djangos users is frowned upon and to build it out separately. I don't know much more on this but it's something I will be doing in the future.
Is anyone aware of a Django app for designing and storing flowcharts in a database? After searching for variations of "Django flowcharts", I've only found flowcharts of Django's internal design, not anything about authoring or storing flowcharts in a Django webapp.
As asked in a similar question, I've found several impressive Javascript and JQuery based libraries for browser-based flowchart design, but nothing for persisting these server-side.
I wrote an app that stores and controls state machines in Django 1.2:
https://bitbucket.org/canassa/zinaflow
It uses a per-object permission model for controlling the transitions and GenericForeignKeys for attaching the state machine to any model in your application. With the per-object permissions you can assign a Django user for each transition.
Depending on what you need to do, this app might be a overkill for you. But reading the source code can give you some ideias on how to implement an app yourself.
Why couldn't you do it yourself? The behavior and presentation is already implemented in the several truly impressive JavaScript libraries you've referenced, now all that's left to be done is to store the models in the database for your favorite pick you'd like to persist through Django.
There is a library that implements Modified Preorder Tree Traversal on the model level that I'm sure would be of great use to you to store the logical relations between the flowchart elements and other presentation data, such as the coordinates, shape, it's transformations and other visual properties can be easily stored alongside.
I'm sure that if you'd give it some thought you could quickly execute it; hell it's even probable that there are many people who need the same thing, which would make it even more useful if you weren't developing it just for yourself. This seems like a good candidate for an OS Django app.
I am not aware of an existing app that does this, but if you want to start developing your own a good place to start would be exploring the code for GraphModels, a command from the excellent django-command-extensions project. It is a django manage.py extension that creates database diagrams from models using graphviz.
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 know python and have just read a basic intro of django. I have to built something like a travel website with real time updates. Will django be sufficent for this? Somebody advised me to look at django-CMS, I couldn't find a very beginner's tutorial there. Should I opt for django-CMS? Also how much of django should i know before i can try out django-cms?
Edit: Not too much real time stuff but just updates on the fly, like availibilty etc. Do i really need CMS?
Thanks
From your brief description it sounds like the main part of you project will be something that manages travel information and displays it to visitors to a website. This definitely sounds like something Django would be perfect for.
Django projects tend to be very modular, so the content management part of you code would likely be completely distinct from the travel parts of your project. Personally I'd start with the core travel functionality, rather than start out with worrying about content management. Then once you have that in place you'll be better positioned to decide whether django-cms fits your content needs, or whether something hand rolled will do.
Start by defining your models for the travel application. Then register those models with the admin. Get happy with how the data is modelled and then try and create one of the basic views. You should have something up and running pretty quickly.
You might also be interested in the GeoDjango project http://code.djangoproject.com/wiki/GeoDjango which provides lots of geographical and mapping tools - which sounds pretty relevant to your project.
I would say no. Django CMS is well designed, if you change content frequently. It has nice features to build up a page. But that means it only shows its benefits, when you create a lot pages/subpages and so on.
For a simple website that only presents data, without adding new pages/views, Django will suffice.
And from my experience, you should at lest be familiar with Views and URLs in order to use Django CMS well. But the same applies to Django itself. Everything else can be found on google.
Hope that helps.
I just wanted to try to build a project with django. Therefore I have a (basic) question on how to manage such a project. Since I cannot find any guidelines or so on how to split a project into applications.
Let's take a kind of SO as an example. Which applications would you use?
I'd say there should be the applications "users" and "questions". But what if there was a topic system with static articles, too. Maybe they also could receive votes.
How to build the apps structure then? One app for "questions", "votes" and "topics" or just one app "content"?
I have no idea what to do. Maybe it's because I know not very much about Django yet, but I'm interested either...
There aren't hard-and-fast rules, but I would say it's better to err on the side of more specialized applications. Ideally an application should handle just one functional concern: i.e. "tagging" or "commenting" or "auth/auth" or "posts." This type of design will also help you reuse available open source applications instead of reinventing the wheel (i.e. Django comes with auth and comments apps, django-tagging or django-taggable can almost certainly do what you need, etc).
Generic foreign keys can help you decouple applications such as tagging or commenting that might be applied to models from several other applications.
You should try and separate the project in as much applications as possible. For most projects an application will not contain more than 5 models. For example a project like SO would have separate applications for UsersProfiles, Questions, Tags (there's a ready one in django for this), etc. If there was a system with static pages that'd be a separate application too (there are ready ones for this purpose). You should also try and make your applications as generic as possible, so you may reuse them in other projects. There's a good presentation on reusable apps.
Just like any set of dependencies... try to find the most useful stand-alone aspects of the project and make those stand-alone apps. Other Django Apps will have higher level functionality, and reuse the parts of the lowest level apps that you have set up.
In my project, I have a calendar app with its own Event object in its models. I also have a carpool database set up, and for the departure time and the duration I use the calendar's Event object right in my RideShare tables. The carpooling database is calendar-aware, and gets all the nice .ics export and calendar views from the calendar app for 'free.'
There are some tricks to getting the Apps reusable, like naming the templates directory: project/app2/templates/app2/index.html. This lets you refer to app2/index.html from any other app, and get the right template. I picked that one up looking at the built-in reusable apps in Django itself. Pinax is a bit of a monster size-wise but it also demonstrates a nice reusable App structure.
If in doubt, forget about reusable apps for now. Put all your messages and polls in one app and get through one rev. You'll discover during the process what steps feel unnecessary, and could be broken out as something stand-alone in the future.
A good question to ask yourself when deciding whether or not to write an app is "could I use this in another project?". If you think you could, then consider what it would take to make the application as independent as possible; How can you reduce the dependancies so that the app doesn't rely on anything specific to a particular project.
Some of the ways you can do this are:
Giving each app its own urls.py
Allowing model types to be passed in as parameters rather than explicitly declaring what models are used in your views. Generic views use this principle.
Make your templates easily overridden by having some sort of template_name parameter passed in your urls.py
Make sure you can do reverse url lookups with your objects and views. This means naming your views in the urls.py and creating get_absolute_url methods on your models.
In some cases like Tagging, GenericForeignKeys can be used to associate a model in your app to any other model, regardless of whether it has ForeignKeys "looking back" at it.
I'll tell you how I am approaching such question: I usually sit with a sheet of paper and draw the boxes (functionalities) and arrows (interdependencies between functionalities). I am sure there are methodologies or other things that could help you, but my approach usually works for me (YMMV, of course).
Knowing what a site is supposed to be is basic, though. ;)