I want to replace the default Django Admin templates with a completely revamped bootstrap version. The data in the Dashboard should be populated from the DB. How do I work with templated files ? Which files should be overriden ? In which template tag does HTML code go ?
From django docs on admin:
The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around.
It's possible to change templates to do what you want, but that will be very complex - you have to basically rewrite most of the templates, get to know how it is working internally and probably change that too to your own design (after all, you are going to show specific details, like charts, data and so).
You will faster to achieve results if you going to build your own app, that will work exactly like you need without multiple fixes. Does it have to use js frameworks depends entirely on your requirements. Usually they are much more simple for admin backends, that are going to be used by owners, not clients. Anyway, if you don't have experience or knowledge in this, you will probably better off with just plain static django templates.
Django admin is just a same app as the ones you build, so limitations will be the same. Security wise, it doesn't offer much that you can't do yourself - make sure you have permissions set in models/views. Read more about security in django.
From functionality point of view, django admin just comes with CRUD access to your models, which can be done quite quickly. Once you past that, you will have much easier time adding functionality to your own app instead of overriding django admin.
Overall, I advise you to build your app for CMS-like admin panel. JS frameworks is neat, but that require burden of multiple additional tests (with api mocks), constant swapping between adding api / writing a component and much higher time consumption overall.
Related
This is not a HOWTO question, as it, as such, has been answered before here
I am trying to integrate Django with modern frontend framework, and I found that it is possible to store and render Django templates from models. Since it is not a standard, I am wondering what are the advantages (or disadvantages if that's the case) of file based templates.
Reading though the documentation, I have seen that it is recommended to actually cache templates and models as much as possible for best performance, so why would it not be recommended to store templates in the database? It seems very convenient to me that in doing so pages can be edited from the admin panel (where you can add a code editor), which, along with the rest framework and a front end framework synergize very well.
From my research, the template tags and template language seem to work and the context can be passed in a view as well. the only thing I cannot figure out is the {include .. } tag, as it does not seem to point to a view. (although a custom tag cam be made to have this function)
Can such a setup be used in production? or are there security/performance/other concerns?
It's not recommended because templates are the developer's responsibility, not the site admin's.
Otherwise, there's not much performance difference between reading files directly from filesystem and from database.
One drawback of this approach is you don't get revision history (using git, mercurial etc). Sure, you can implement something similar to save the revisions in the database, but then why not use the better tools which already exist?
There's a Django flatpages app which lets you save HTML content in database. But the purpose of the app is to allow site admins to edit HTML content, such as information for an "About Us" page, because writing this info is not a developer's responsibility.
I’m creating a big project with Django and wondering if it is sensible to use the HTML template structure for my front end or should I implement something like React? What are each of its benefits? Is it perfectly reasonable to use HTML templates for a big project? Any advice?
Django templates are quite fully featured, and performant, and I'd use them if I could meet the requirements in my project with them alone. Adding react will increase the tooling you'll need and have to maintain, so my team only introduced it after we started to need user interfaces that were react-like (it started when we implemented an in-app to do list). So your project requirements will really dictate if you want to invest additional development and devops energy into react in order to have a more instant-update/native-app-like feel, or not.
If you are unsure, I'd recommend starting with templates and introducing react later. It's entirely possible to run an app that uses templates for 90% of your app and react only where it's needed (we do this).
The thing with React is you need to have a good API in between your back-end and your front-end. I would recommend Django Rest Framework for that. Anyway, templates are nice to quickly get something up and running, something that is mostly display centered and you don't have to do too much scripting. React makes it easier to have a heavier front-end. However, templates can handle a lot of front end as well, just you won't get access to any of the nice benefits of React. I have used templates for a big project, and it worked nicely. I didn't have to build an API, and the templates easily interacted with my back-end. I am not sure exactly what kind of project you are doing, so these are just my recommendations.
I have been facing a big challenge with django since I was assigned the task to rebuild the admin page of our platform. I started unsure of what to do and now that I am half way on, I am even more unsure.
Here is my question:
If I want to build a highly customized admin, should I do a giant hack on the source code or create a new app?
1) Giant Hack
That is how I started and got stuck. A couple of problems appeared on the way, for instance:
I had to extend the AdminSite and override every view I wanted to change
Django's admin is very modular (I mean, very very modular) and a screen might be the sum of tons of other templates
Creating a simple navbar is a pain in the ass (at least it has been for a newbie like me). This is due to the fact that app_list (the variable that contains the mapped models to show in admin's first page) not being accessible when other templates rather than base.html are injected. Thus, I would have to create a context processor, replace every TemplateResponse() by render() (technically, since I tried to do it and it didn't work as well)
The problems go on and on. Given my lack of experience with django, I might be doing crap, but it does feel like I am on the wrong way.
this guy's answer motivated me to post this.
2) Building a brand new app
Of course it will take a little while to implement this, but it seems like a robust and maintainable way of getting it done. One of the points is that I will need to give the same flexibility as the default admin site gives when adding models and promptly having their cruds and tables (I am not really sure how to accomplish this behavior).
I am pretty new to django and any guidelines will be highly appreciated. Give me your thoughts on how to make it.
There is no need to overwrite admin views. The easiest way is to overwrite the templates and add your own css & javascripts.
I have added my own navbar, sidebars and bottom. It is really easy if you overwrite the admin base templates.
If needed you can provide custom data to the template by using own templatetags.
I am new to Flask and have noticed that there are two plugins that enable CRUD views and authorized login, Flask-Admin and Flask-AppBuilder.
These two features interest me along with nice Master-Detail views for my model, where I can see both the rows of the master table and the relevant details on the same screen.
Any idea which one to prefer? I see that Flask-AppBuilder has far more commits in Github, while Flask-Admin many more stars.
How to tell the difference, without spending too much time with the wrong choice?
I am the developer of Flask-AppBuilder, so maybe a strong bias here. I will try to give you my most honest view. I do not know Flask-Admin that much, so i will probably make some mistakes.
Flask-Admin and Flask-AppBuilder:
Will both give you an admin interface for Flask with bootstrap.
Will both make their best to get out of your way.
Will both help you develop Flask more Object Oriented style.
Will both let you override almost everything on the admin templates.
Will both support Babel.
Both inspired on Django-Admin.
Pros for Flask-AppBuilder:
Has a nicer look and feel (bias? maybe...).
Security has been taken care of for you, and supports out of the box, database, LDAP, OpenID, Web server integrated (REMOTE_USER), and in the near future OAuth too. Will let you extend the user model and security views.
Granular permissions, creates one permission for each web exposed method and action (you have to try it).
You can easily render Google graphs.
Smaller project, it's easier to request new features, and get your pull requests merged.
MasterDetail views and multiple views can be setup easily.
Backends: supports SQLAlchemy, MongoEngine, GenericInterface (you can integrate with your own builtin data still a bit beta).
Pros for Flask-Admin:
You have to assemble your own security (models, views, auth etc), it's ready though to integrate nicely with flask-security. This can be a pro or a con depending on what you want.
Builtin File Admin.
Bigger project with bigger community.
Backends: supports SQLAlchemy, GeoAlchemy, MongoEngine, Pewee and PyMongo.
Better support for MongoEngine (EmbeddedDocument, ListFields etc..).
On the overall i think Flask-Admin makes no assumptions at all like Flask, you have to code more, but this will let you be more free. Flask-AppBuilder makes some assumptions (on security), you will have to code much less, but some things can get on your way if your building very specific security models.
Hope this helps you and others, i tried my best to keep the bias out.
For me, master/detail is the major feature. That led me to use Flask AppBuilder to create ApiLogicServer:
With 1 command, create a database API, to unblock UI development. Also, a multi-page web app, to engage Business Users - early in the project. Declare logic with spreadsheet-like rules - 40X more concise than code, extensible with Python - for remarkable business agility.
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. ;)