I'm trying to refactor some (4 in number) ajax views which work almost same as the following procedure:
Get some (2-4 in number) of objects using args
Return a json if any of the objects were not found, else continue
Then we extract another object (using the objects found in step 1) to update and create one if not found
Create a new form depending on the type of the object we got in step 3 and validate and update the object
Return a json in the end depending on form validity
The first 2 steps are common in all 4 ajax views. Even the models from which they try to extract the objects using args is common.
However, step 3 onwards things are very distinct in nature. The model used to extract the object and in turn the form used for validation. Also depending on the model there are certain more stuff happening in 2 of those ajax-views.
I'm quite new to Class-based Views and read this and this. Yet, I'm unable to see if I'd be making a drastically convenient future in terms of maintenance if I convert those 4 ajax-views to CBVs. And yeah, there's possibility that we create another such ajax-view once every year.
Question is: Should I use CBV or not, given that I can only stop replication of first 2 steps if I used CBV?
Personally I find class based views easier to read. Ability to use inheritance to not repeat the same code is nice even i you use it just a little bit. I find that the class based views really shine when you develop RESTful APIs, since you can process all the different request methods in the same class.
Related
I want to have a template which has a listing of objects in the column on the left while showing a detail of an object at the same time. Can I somehow make use of generic ListAPIView and RetrieveAPIView? In REST API, a client would just do two requests and compose the data together itself. Is a similar approach possible using TemplateHTMLRenderer?
I think, there are two ways of doing it.
The most common way is to make two async requests on frontend (one for list, second for retrieve).
The second way is to go away from REST and overwrite retrieve method - it should return both information about specific object and about all objects.
If you want to get HTML, try StaticHTMLRender
I am currently designing a 3-step form to achieve orders in my website.
The client will start on step 1, fill some fields, then validate and go to step2 is the form is valid, and so on until the end.
As I'd like to do it without using Javascript, I'll create 3 Django views and 3 Django templates for each step.
The thing is I must wait until the end of step 3 before creating and saving objects in the DB. This means at the end of the step3, I should get information of the 3 steps before processing data.
The question is: what is the best way to store information from step 1 and 2 during the process (ex: session )?
Hope it's clear. Thanks for help.
Take a look at form wizards - it is designed for exactly that. You can use either sessions or cookies to store data, both methods have a default WizardView that takes care of storing the data for you.
I'm tackling learning a little AngularJS and have come across an issue that seems like it should have an easy resolution, but my searching of the docs and various forums are proving it's either a little more complicated or I just don't know the right terminology. Anyway, here's the short of it. I want to bind to an arbitrary number of input fields and total their values (so I can, for example, display a running total of user inputted numbers). However, not only are the number of input fields arbitrary, but the fields themselves may have different names every time.
Specifically, my data backend is Django, and for various reasons the form itself must be generated by Django's modelforms and then sent via an ajax call to the Angular front-end. I really want to avoid coupling too closely to each form (i.e. I don't want to write an Angular function for each possible permutation of form that Django might send, but instead want a single one that knows how to select the proper things to bind to).
I do have control over the construction of the forms via Django, and have been attempting to figure out what Angular directives I need to inject, but as I'm still on my way up the learning curve any guidance would be greatly appreciated.
How about using javascript array?
You can make a form with ng-model that refer to the array element.
And total() function to iterate though the array element and get the sum.
It can support arbitrary number of input elements this way.
If it is only about input elements and total function, it satisfies the requirement.
http://plnkr.co/edit/ZJCQ2m
Should I be writing application logic in my view code? For example, on submission of a form element, I need to create a user and send him an activation email. Is this something to do from a view function, or should I create a separate function to make it easier to test down the road? What does Django recommend here?
I found it very hard to figure out where everything goes when I started using django. It really depends on the type of logic you are writing.
First start with the models: model-methods and managers are a good place to perform row-level logic and table level logic i.e. a model manager would be a good place to write code to get a list of categories that are associated with all blogposts. A model method is a good place to count the characters in a particular blogpost.
View level logic should deal with bringing it all together - taking the request, performing the necessary steps to get to the result you need (maybe using the model managers) and then getting it ready for the template.
If there is code that doesn't fit in else where, but has a logical structure you can simply write a module to perform that. Similarly if there are scraps of code that you don't think belong, keep a utils.py to hold them.
You shouldn't perform any logic really in your templates - instead use template tags if you have to. These are good for using reusable pieces of code that you you neither want in every request cycle nor one single request cycle - you might want them in a subset (i.e. displaying a list of categories while in the blog section of your website)
If you do want some logic to be performed in every request cycle, use either context processors or middleware. If you want some logic to be performed only in one single request cycle, the view is probably the place.
TLDR: Writing logic in your view is fine, but there are plenty of places that might be more appropriate
Separating the registration code into it's own function to make testing easier is a good reason. If you allowed admins to register users in a separate, private view, then a registration function would be more DRY. Personally, I don't think a little application logic in the code will do to much harm.
You might find it instructive to have a look at the registration view in the django-registration app -- just to see how it's written, I'm not saying you should or have to use it. It has encapsulated the user registration into it's own function (there's a level of indirection as well, because the registration backends are pluggable).
This is more of a best-practices question, and given that I'm quite tired it mightn't make much sense.
I've been putting together a blog app as a learning experience and as an actual part of a website I am developing.
I've designed it like most apps so that you can list blog posts by multiple criteria i.e.
/blog/categories/
/blog/authors/
/blog/tags/
/blog/popular/
etc.
On each page above I also want to list how many entries are a part of that criteria
i.e. for "categories", I want /blog/categories/ to list all the different categories, but also mention how many blog posts are in that category, and possibly list those entries.
Django seems to give you lots of ways of doing this, but not much indication on what's best in terms of flexibility, reusability and security.
I've noticed that you can either
A: Use generic/very light views, pass a queryset to the template, and gather any remaining necessary information using custom template tags.
i.e. pass the queryset containing the categories, and for each category use a template tag to fetch the entries for that category
or B: Use custom/heavy views, pass one or more querysets + extra necessary information through the view, and use less template tags to fetch information.
i.e. pass a list of dictionaries that contains the categories + their entries.
The way I see it is that the view is there to take in HTTP requests, gather the required information (specific to what's been requested) and pass the HTTP request and Context to be rendered. Template tags should be used to fetch superflous information that isn't particularly related to the current template, (i.e. get the latest entries in a blog, or the most popular entries, but they can really do whatever you like.)
This lack of definition (or ignorance on my part) is starting to get to me, and I'd like to be consistent in my design and implementation, so any input is welcome!
I'd say that your understanding is quite right. The main method of gathering information and rendering it via a template is always the view. Template tags are there for any extra information and processing you might need to do, perhaps across multiple views, that is not directly related to the view you're rendering.
You shouldn't worry about making your views generic. That's what the built-in generic views are for, after all. Once you need to start stepping outside what they provide, then you should definitely make them specific to your use cases. You might of course find some common functionality that is used in multiple views, in which case you can factor that out into a separate function or even a context processor, but on the whole a view is a standalone bit of code for a particular specific use.