I have been playing for a couple of days with Django Admin to explore it, but I am still clueless of how it can be customized in the way we need.
Every time I look for any help for the customization in the admin panel, what I find is, a bunch of articles on various communities and forums, explaining how to customize the template, the lists items, the the column views etc. But that should not be called Django Customization.
If I need to make even a small change in the User functionality or any modification to the auth module. It takes a lots of efforts even in figuring out how that can be done.
Is Django that difficult to customize or its just lack of the help available over internet for this or its me who is moving in the wrong direction ?
You are not providing enough details on what you want to achieve, so it's difficult to say how complex the task is. You might also want to consider not modifying the admin site at all and building your own views where appropriate.
However, here are some good links to get you started:
Customizing the Django Admin
Doing more with the Django admin
Extending Django's User Admin
Personally, if you want a site to look like the admin, why not pull the templates and styles and use them, build your own views for what you need. Gobs of documentation and forum help is there for that. I like the idea of customizing the admin, but honestly, I have been doing it for awhile on a project and time and time again I think to myself, if this was built in the standard MVC (or MTV) manner with free templates online, copied admin ones, or some professionally made ones, and built with the plethora of addons and my code, it would be much easier!!! And, when you decide that request/response isn't cutting it, and you want to add lots of JavaScript, you'll be glad. I know. I have had to put all sorts of JavaScript on our Admin project. Mostly because it's impossible to make the admin do what we want, so we fix it with JavaScript once it is on screen. When you find yourself writing an Ajax based system, you'll wonder why you have the admin at all.
If I could start this project over, I might not even use Django, but I probably would. I most certainly won't used the Admin.
Now, if you are building an basic CRUD type site that doesn't have style-eyed users, then Django with grappelli, and some elbow grease will get the job done. Remember, Django is a collection of Python scripts. Just override everything you can, and you'll get there, if you aren't too ambitious.
Django Admin is easy to customize if your requirements match what is customizable in Django. If you need fancy features that are not out-of-the-box functionality you either need to find a plugin that does it, or implement it yourself by subclassing the appropriate classes. Which can be difficult, and requires good understanding of the internals of Django.
So in summary: it makes it easier to setup an admin, but if you need anything special that's not out of the box: you got a steep learning curve.
Depending on your requirements you can choose to use django or not. Anything that requires a lot of functional speccing is better of implemented manually.
It's very easy . Just copy default template to project and change HTML and some variable location
Just see in this vedio
https://youtu.be/NTZfjwf4F8A
Related
first of all i'd like to apologize if my problem seems to broad to answer but i'm really getting frustrated over this. so i'm a wordpress developer mainly (used to be a front end developer) and i'm getting into python django. but after taking many courses i can't seem to understand how to do the content management aspect of my project. so here is a rundown of my problem
in wordpress there is this concept of custom post meta where you can put fields that can change the heading of pages and fully customize the website so that the client won't need me every time he needs to change anything (CMS basically)
now i can't even begin to imagine how to go about doing something like that for django
i've tried putting a custom form on top of my list view in the admin page but that doesn't look so good and what if i need to customize a page that doesn't belong to a module with a list view
i've tried to make an app and call it page but then what about the stuff that is directly related to a module.
so my question is: how should i think about this since i don't want to go a long way in one direction just to discover that that is a poor way of doing things
also as a side note the site i'm creating is not that much bigger than a blog which i know i'd be better off doing in wordpress anyway but i thought it would be a good starting point to familiarize my self with django.
finally if you'd recommend any courses or maybe a tutorial i'd be more than grateful.
You're right, that is a very broad question. Here is a broad answer that I hope will help.
Django is a programming "framework" that can be used to develop new web-apps, including new CMS's. In my experience, the customizability of web-page titles in a new Django-app would involve using Django's html template language with template-tags and context-variables etc, as well as Python programming within the Django framework. For doing content management, you would basically have to program your own models & functions for that, along with whatever default or other database system (MySQL, PostgreSQL) you choose to install... There is a learning curve, but Python and Django are considered by some to be among the easiest language+frameworks to learn.
This tutorial playlist may help you. It helped me muddle thru Django in the beginning, and he has Python tutorials also.
I'm a beginner to Python and Django.
When starting a new project what do you do first before diving into the code?
For example, one could take the following steps:
Configure the settings.py file first
Configure models.py to lay out data structure
Create template files
Define the views/pages
Syncdb
etc
So my question is, what is a good workflow to get through the required steps for a Django application? This also serves as a checklist of things to do. In the definitive guide to Django, the author talks about approaching top down or bottom up. Can anyone expand further on this and perhaps share their process?
Thanks.
Follow the Agile approach. Finish one small case, from the start to the end. From the models to the tests to user experience. Then build on it. Iterate.
Thats the right way to software development.
To do it efficiently, you need: (don't bother right away, you will need it.)
Automated schema migration, automated build system, auto updating and deployment. - None of these, django has got anything to do with. Use pip, fabric, hudson, twill and south appropriately.
Take care not to over burden yourself with all these right away, particularly since you say, you are beginning.
the required steps for a Django application?
There are two required steps.
Write the settings. Write the urls.py
The rest of the steps are optional.
This also serves as a checklist of things to do.
Bad policy. You don't need a checklist of Django features. You need a collection of use cases or user stories which you must implement.
For some reason, you've omitted the two most important and valuable features of Django. Configure the default admin interface and write unit tests. The default admin interface is very high value. Unit testing is absolutely central.
You do it like this.
Gather use cases.
Prioritize the use cases.
Define the actors. The classes of actors becomes groups in the security model.
Define enough "applications" to satisfy the first release of use cases. Define the url structure. Cool URL's don't change.
Build the first use case: models (including security), admin, urls, tests, forms, views and templates. Note that these are the file names (models.py, admin.py, ...) except for templates. Also note that forms and admin should be defined in separate modules even though this isn't required. Also note that templates will be split between a generic templates directory for top-level stuff and application-specific templates.
Build the second use case: models (including security), admin, urls, tests, forms, views and templates.
...
n. Package for release. Tweak up the settings. Configure database and mod-wsgi
I personally can't make a template without writing the views (unless it's a photoshop draft) but in general that's the way I go after I have a plan.
What's extremely important for me is that I don't dive head-first into the code, and that I spend time mocking up the model structure based on the "screens" or "pages" that the user will see.
Once I have a user experience defined, I make sure the backend is robust enough to handle that experience. If I don't visualize the user experience, details get left out that are certainly accomplishable in the shell but not ideal for the website, default django admin, etc.
There are always tradeoffs between agile development and a huge spec: I think there's an important balance. Agile is good: there's no point planning every detail before writing your first line of code, as your needs will change by the time you get to the end. You don't know how your users will really use the site.
On the other hand, without a plan, you can end up with a messy foundation that affects all future code.
An educated guess is a good start. Don't think or assume too much, but definitely have a clear idea how your users will interact with your site for stage 1.
Always try to remember about a DRY rule. For example, why to write RequestContext every new view is defined, where you can simply write a function once, which will add it for you. Good description is here in another topic.
Try to keep a code written one way. Each time you upgrade a schema of your view, edit it in all already written views. That will help keep your code clear and save a lot time for you in future.
Generally good rule, and how do I write my applications is the rule of small steps. Start with writing a settings and urls, then add one model and one view. When it works, modify - add another models or another views. You won't even notice, when your project becomes bigger and bigger.
And the last useful rule for clarity of all the source. Keep files in folders. If you have two subsites based one one (for example "accounts" and "blogs") create two directories names the same. Remeber to put init.py file in each directory. It's really easy to forget. With this practice it's easy to write models and views dedicated to each category. By the way it's a good practice to keep urls like in a tree structure. Main urls.py should contain only links like this one:
(r'^accounts/', include('your_main_name.accounts.urls')),
and of course all media, static, css and so on. In accounts directory urls keep:
urlpatterns = patterns('your_main_name.accounts.views',
url(r'^$', 'index', name='index'),
)
with all views subdirectories.
Last one - keep code clear with actuall django version. Remeber, that the 3.0 release is comming soon.
Hope this will help.
I find that my process varies depending on a lot of variables, mainly whether I know something will work or if I'm experimenting and also whether I'm developing on my production server or in a development environment.
For example, I often do my development directly on the deployment server (most of my work is for intranet projects so there isn't any security risk, etc). But when I do this I really need to make sure the settings and urls are setup first and that gunicorn and nginx are configured.
If I know something should work, or am setting up a generic base set of code, sometimes I'll do all that coding for views and models before I even get enough setup to even run the development server. But when experimenting with new code I find it's good to be able to test every step of the way, so in that case you need your servers running.
In general I do settings, models, syncdb, views, urls, templates, collectstatic, graphics/aesthetics
In general I leave my base.html very plain until the everything else is working, then I add css/js etc.
I guess my point here is that there isn't really a wrong answer for how you do it, and there isn't even only one best practice (as far as I'm concerned). When you do more work, you'll find what you are comfortable with and it'll even vary from project to project.
Good luck, hopefully you learn to love django!
here is something I do in general,
configure basic settings
configure root url.py
configure settings, url.py for static (media) files
create model
sync db
write views (use simple template, if needed)
once you are done with back end implementation
think about UI
prepare styles, scripts
start working on template implementation
This may seem quite a weird question but I'm quite confused right now and don't know what to do.
I'm working on an intranet web app using django. Soon I found that almost all features I need are done in django-admin, like adding and editing entries, view and filter items in a list view and so on. The missing parts can be done with some other additional views.
Should I just wrap up the admin app or should I re-implement the admin by myself? Or I should use something other than django like GWT or extJS?
That depends on your motivation. If this is an exercise in sharpening yourself then I suggest reinventing it. Mainly because you learn so much in the process. If the main goal is just to have the functionality then use the django-admin and bolt on whatever you need that it lacks.
Has anyone implemented their own AdminSite? How easy/hard was the basic implementation?
I'm in the midst of building a "cms" that's going to be quite large and decently complex in some areas and I'm wondering if using something like AdminSite would save some time. I'd rather not have to make my own implementation for admin actions and inlines and the like (I know I can just use inline forms but that's not as simple as inlines = [Foo]).
When using a custom AdminSite, is further customization equivalent to customizing the standard Django admin?
You've read the admin site docs. It's a lengthy document, but two main hooks for adding custom functionality is through custom urls and modified standard views in your own AdminSite and ModelAdmin objects. Once you hook those in and the urls get mapped, it's just like building any other Django application, only that the templates aren't yours, so they're are a bit hard to manage and take getting used to. But it allows you to do additional gymnastics, like adding a form wizard to the admin site or splitting everything into multiple forms and rendering them in a single HTML form element in the templates, doing custom handling of GET/POST requests, etc.
I've used it in the past to create views for displaying custom reports and to create custom editing scenarios for the staff. My opinion is that you should KISS as much as possible. The admin site is all about generic views and generic presentation. Do expand, but be cautious if you override template blocks and think twice before you override something that's not wrapped in a block. Certain admin site features have certain presentation assumptions and the JS client app that's shipped with Django makes some too (that's what I've figured when working with adding dynamic inline models way back), so it'd be quite an undertaking if you'd like to roll a completely different presentation.
The answer in any case is YES! The admin site will provide you with more features for managing your model data interactively. I don't know how extensively you'd need to customize the admin, but there are CMSs, dedicated admin apps and admin integrated apps that are a real eye-opener. Django CMS, as I recalled, has been praised as the best open-source Django CMS out there and from what I can see it rolls it's own cust change/list views. Rosetta is an admin site only app that allows you to edit your translation files interactively and has an exhaustive admin interface! If you shop around on bitbucket and github you'll find many more examples, it should help you figure out best how much effort you'd need to put into it.
Both
If you are OK with it not doing exactly what you want its pretty much done for you automatically. If you need fine grain control over certain things it can be hard to customize without knowing the internals of the admin code.
the django admin is more of a one size fits all kind of ui which may not be intuitive for use in some cases ..
customizing its look is easy but extending it is some how hard. you are better off designing your own views in that case.
Are there any Django apps equivalent to Drupal's Views and CCK modules?
I find Django much more flexible and logically organized than Drupal. But I think Drupal's Views and CCK modules are killer apps. They let the webmaster very rapidly to build new data models and queries through GUI without touching the code. These modules are very useful for rapid application development. Do you know any similar apps in Django?
Django is a framework, this had been said, but if you look for functionality close to CCK, PINAX makes for python/Django, the equivalent of modules in Drupal, sort of ready to go modules, login/pass check, listing, input output, or CRUDs ect. But in no ways radio buttons and check boxes action programming. You will have to put your building blocks together and indulge some python programming. I found myself spending more time loading extra modules and themes tweaking in Drupal, than putting together a full blown site in Django, maybe because, I own many libraries wrote several times and improved over time, for cases encountered over and over. I focus only on new or cutting edge things. Both approaches are ok as long as you know what you want to go. The hard fact is that for a CMS that want to attract non programmers peoples if you want to build great sites, you have to be good in php/mysql and a good grip on css, and it kind of defeats the purpose. In France we say, "the best tool is the one you use every day". If you are frustrated with Drupal, learn Django, and in the same time needed to master Drupal, you will have a skill to write your own Drupal and others CMS, maybe. Good luck in your endeavor.
I don't think there is something similar and for a good reason. Django is a framework, while Drupal is a full scale CMS. One of the powerful things about Drupal, is how it handles content. Every piece of content is a node, and it lets developers make modules that can add to a node's functionality.
Django is a great tool to, but it's strength is more the ease of development, that lets you create applications very fast. That is what it was built for after all. It would be hard to make something CCK and Views like with Django, and I don't think it would make much sense either. I find that when developing with Django, you can very quickly create most CCK and views things, withe Django models and the orm. You can't do it in a GUI, but that was never the goal of Django. The admin interface also reflects that, as it is good mainly for one thing. Handling content, CRUD style operations. I guess that is why Satchmo created their own settings system for shops.
http://docs.djangoproject.com/en/dev/faq/general/#is-django-a-content-management-system-cms
...it doesn’t make much sense to compare Django to something like Drupal, because Django is something you use to create things like Drupal.
The lack of flexibility that you refer to is the price you pay for CCK and Views. I've used both Drupal and Django to complete major projects. You can use Drupal as a framework too, so in my opinion the two are absolutely comparable.
Django has a way better database abstraction than Drupal, follows more modern programming paradigms like OOP, MVC etc, is more flexible, and Python is just straight up superior to PHP.
...but I still usually use Drupal if either will do. It just gets the job done with less time spent, and works and performs well. Django has nothing like Views, and Drupal's form api is just light years ahead of Django's. Creating multi step ajax forms can be done without ever touching the markup or writing a single line of javascript in Drupal, and presenting dynamic lists to the user can be achieved without even leaving your browser.
Drupal has a much greater deployment rate than Django, not just because of PHP's popularity, but because it actually does some things really well.
My time is precious, and the end user doesn't give a damn as long as my system works.