In Rails, I used the application_controller to control things like user sessions, and create objects to populate parts of the site like the menu.
How should this be done in Django, since there is no kind of "application view"? Do you have to use custom filters and partial templates to be included, for instance in the base template to do this?
I have also been looking at class-based views, but am unsure if that is it.
There are several ways to accomplish this:
Template Tags
Context Processors
Class Based Views
Middleware
It just depends on what you're needing to do. request.user is always present in the request object, even if it's an anonymous user, so you don't have to do anything special to access that object from within a template or server-side code.
Inclusion tags are as close as you'll get to render partial in Rails.
Signals and Class-Based views are close to what you'd find in controller filters.
One of the books I found most helpful when learning Django (I went to Django from Rails) was Practical Django Projects. The Definitive Guide to Django is also available for free.
Related
The age-old question: How can I automatically save last_modifed_user in django models?
I found in several places this general process how to do it using thread local. I'm hesitant to simply implement it that way because I'm not entirely sure of the consequences it has and because all these posts are old.
Is using thread local still the "recommended" way of doing this in django 3? Or does django3 have a better options of doing it?
No, this hasn't changed. Simply because separation of concern is an architectural principle of MVC (model-view-controller), which is also how Django (model-view-template) and most web frameworks with ORM are architected. Models know nothing about the request, it's not available (and in many cases there isn't a request at all when a model is saved, think of management commands or regular tasks running in the background).
The alternative to thread local is to make sure you implement it yourself in the controller layer (view layer in Django):
Create a view mixin that you can mix with all the generic views that use the ModelFormMixin to save the user into the model (ModelFormMixin.form_valid()). Or combine it with a form mixin where the user is passed to the form (FormMixin.get_form_kwargs()) and saved when the form is saved (ModelForm.save()).
Create a ModelAdmin mixin that does the same when saving a model in the django admin site.
This of course means someone on your team may forget to do it when creating new views and forms. The link you posted contains an answer as to the advantages and disadvantages of using thread local.
I stuck in code where i want to use model-form in flatpage template.
I create model-form and that form need to serve in flatpage template with save functionality.
(I know this is old, but just in case other are looking at it)
I don't think you can as flat-pages are associated 'simple “flat” HTML content'. This include stuff like 'About-us' pages or private policies.
Usually you want to maintain Forms data within Views which you can access their data from it. This allows you to use the data to send emails or process logins.
Consider a very simple dashboard application in Django. It has 2 models:
Page
Widget
Naturally, Page and Widget have a ManyToMany relationship.
Like any good dashboard implementation, the designers can change 3 things in a widget:
Data source that drives the widget
Placement of widget on the Page
Presentation of Data inside a widget
The Data is specified using a URL field in the Widget and is being served by a REST API based on Django REST Framework with the django-filter backend.
The Placement on the Page is catered using the excellent Gridster.
This leaves the Presentation part. I have two possible solutions:
Attach a template TextField with the Widget. Data will be fetched from web services in JSON format and rendered according to the template (handlebars) defined in Widget on the client side.
Pass the template name as query string in the URL to the REST API and render the Data using the user-specified template.
Now that the context is clearly defined (hopefully), following are my questions:
Is there any way I can choose the first solution and still be able to use the automatic forms generated by the DRF Serializers?
If not, and I choose the second solution, are there any potential pit-falls regarding security, code maintenance, code quality, testing and the like? Why have I not seen anyone else doing this i.e. letting the user select the template via query string?
Is there any other solution that I am missing?
Your first options seems most promising: fetch the data as JSON and insert it into templates on the client. All good.
So can you do that "and still be able to use the automatic forms generated by the DRF Serializers"? — Short answer, it depends what you mean by "automatic forms".
Serializers take a data dictionary, validate it and (for ModelSerializer subclasses) convert it into a (model) object instance for you. If by "automatic forms" you mean will you still be able to this validation behaviour, then the answer is yes. Create your JSON payload on the client and send an appropriate HTTP request to the API. Django Rest Framework's Serializers will work as expected.
If (though) by "automatic forms" you mean will you still be able to use the HTML forms that DRF provides in its web broweasble API, then the answer is no. The browseable API is built around an HTML renderer returning entire web pages. These include a pretty-printed representation of the JSON you'll be using as well as the web-forms that, on this assumption, you're interested in.
If you go this route you'll need to generate the forms on the client, using whatever model, view, template and binding features your chosen library (libraries?) offer(s).
I hope that helps. Good luck.
I have models with datetimefields and timefields. When the user interacts with these fields in a form they often just need to enter the current time. I need a now link almost exactly like what shows up in the django admin, so the user can just click it and the current time gets put in the field.
I tried looking through the django source but it seems to utilize some frontend javascript which I'm not very familiar with. Is there a simple way to make a widget that can be easily used in a timefield and datetimefield?
So this is not on the admin panel? As in on the site? Then this is not really a question to be posed to Django, I suggest tagging javascript. If you are unfamiliar with javascript, then tag jquery, they have things for this.
In case you're lazy, here's a start:
Here
jQuery premade
Javascript methods
Sorry, but this is more of a UI issue than a Django issue. Hope I helped, though.
So in my Django project I have a few different apps, each with their own Models, Views, Templates, etc. What is a good way (the "Django" way) to have these Apps communicate?
A specific example would be a Meetings App which has a model for Meetings, and I have a Home App in which I want to display top 5 Meetings on the home page.
Should the Home App's View just query the Meetings App's Model?
It feels like that is crossing some line and there might be a more de-coupled way to do things like this in Django.
At some point your apps will have to couple in order to get any work done. You can't get around that.
To achieve decoupling as much as possible,
You need to have a Project specific app, that does all the hooking up things between each other.
Using signals from models to create new models in a decoupled apps helps. But doing too much of this, is foolish.
Should the Home App's View just query the Meetings App's Model?
Yep, that's how it's done. If you really want to decouple things, you could make your Home app use generic foreign keys, and some sort of generic template system, but there's not really a good reason to, unless you have grand plans for your home app being pluggable and working with a bunch of other different Django apps.
Writing tightly coupled Django apps is really easy, and writing decoupled Django apps is really hard. Don't decouple unless you have a reason to, and you'll save yourself a lot of work (and happiness!).
If it were me, I would make a template tag in your meeting app that produces the desired output and include that template tag in the home app's template.
That way you are only coupling them in the View portion of the MVC and makes it easier to maintain if you change your models in the meeting app.
For your specific example, I would use a Django templatetag.
Having a templatetag "display_top_meetings" in your Meetings app, and calling it with {{ display_top_meetings 5 }} from your index template, loading it first.
You can read more about templatetags here:
Django Official documentation about TemplateTags
B-List's article on writting 'better template tags'
I hope this help!
yes. I think thats a design feature. All models share a backend, so you'd have to do extra work to have two models with the same name in different apps.
Projects should not share Models