I'm working on a Django (1.11.1) app which allows users to request reimbursement for certain purchases. Part of the request form (using django.forms) is an itemized list of purchases. I could, of course, hard code some number of rows into the form and make users submit a separate form if they need more rows. But that seems rather inelegant.
My preferred solution would be to allow users to add rows as necessary via JavaScript, then handle that dynamically in forms. However, everything I've found on the subject relates to situations where the number of elements required can be determined at the time the form is rendered to HTML. It isn't clear to me how to apply such an approach to my situation.
As dynamically adding form elements is extremely common, I'm a bit surprised that such functionality isn't baked into Django already.
By the way, as this is intended to be an incredibly simple app, I don't want a solution that will require a lot of work. If there's no easy solution, it'd be better to just hard-code the form HTML directly into the template.
Of course it is covered by django.
You need to use formset https://docs.djangoproject.com/en/1.11/topics/forms/formsets/
And then in the template you need to add more forms dinamically to that formset, better via javascript. Dynamically adding a form to a Django formset with Ajax
It could result hard to understand all the options that django provides with formsets, but it's quite powerful and the simplest way.
Related
I'm working on a pretty large Django project, which has over 60 different forms layout (can be more than this when needed). I pretty confuse that how can I build all such forms manually??. I've came up with an idea is that I'm gonna store form layout in database and with every new forms, I just need to config in database and then using crispy layout to dynamically generate those forms...
Do you guys have any better ideas?
Thanks
When I worked on a form heavy project I used to rely on mixin.
Try to identify what are the comonly used type of field and create them in mixins.
If it's a lot of them then create some 'base' forms that incorporate certain set of fields.
Then you just have to compose the form you want from the diffrents mixins and bases and add anything specific to the new one you want to create.
Or you could create your own mapping structure for form and store the logic on how to build your form in a JsonField for exemple.
a json containing such thing as name, label, widgets, placeholder, (and whatever you need). It can be really simple or really complex if you have complicated structure...
Crispy-forms has dynamic layouts which may help for this use case.
https://django-crispy-forms.readthedocs.io/en/latest/dynamic_layouts.html
I'm about to create a form in my website made in Django with elements that have complex input types from different plugins (like calendar plugins). Also, I'll be using a Validator plugin which validates the input before submission.
My question is do I need to create forms.py and like model the form or can I just create the form manually? The former seems like a very hassle process. Which one is more efficient and recommended?
As #dmitryro said you can create your forms manually in the templates and then getting in the request. It's recommended to use the forms api provided by Django since it allows you to reuse, validate, and customize your forms.
As to whether or not it is a good practice that depends completely on you but if you are trying to scale an application I would recommend use the forms.
It is good to use Django's built in form.
If we use django's form then we only have to write python code and django will create corresponding html for it. And our code will be short and clean.
I'm trying to write a simple CRM app in Django; partly as a learning exercise and partly for in-house use.
My schema is slightly complex, as rather that have a single Contact model (with a home phone, work phone, home email, etc.), I have stripped down Cntact model plus a Phone model, an Email model, etc., with a ForeignKey pointing back to a Contact. The point is to let Contacts have an arbitrary number of phone numbers, email addresses, etc. Simple, right?
I have some working views and templates for displaying the data - no issues there. And with only a very small amount of poking at admin.py I have a um...eight different TabularInlines set up, and the admin interface works to create and edit the data...but it's ugly and clunky to the point of unusability, and of course there's no conception of permissions or anything. I'm also not really a fan of having a completely different interface for displaying and searching through the data than for editing and adding contacts...I'd like as much as possible to be done inline, so that I can search for a name, look at the record, click "add note", have it popup a form, fill in the details, click submit, and be done, all with AJAXy goodness so there's no page reloads.
Question: Should I plug away at modifying the admin interface to try and make it usable for a user-facing app? And if so, can anyone point me to a good guide or example where someone has really changed the admin interface to make it work for user-facing CRUD operations?
Or should I just go ahead and write my own CRUD views? And if so, can anyone point me to a good guide or example where someone has written custom CRUD views that work with lots of ForeignKeys and inlines? Ideally I want a form that displays a single Contact, all his Email records, plus a blank form to add a new Email record, plus a button to add more blank forms, plus his Phone records, plus a blank form, and so on for all 8 of my associated models.
(Or am I thinking about this all wrong? Any advice appreciated.)
For our intranet, we use ModelAdmin subclasses (not mounted on the admin site via admin.site.register) for most of our C(R)UD views. By using custom templates for the views, it doesn't look like Django admin at all. What is very convenient though, is that it already handles all the validation/saving for us.
In general, I found admin-"hacking" quite useful to quickly write up C(R)UD views and usually with relatively small changes to your ModelAdmin subclass, you can make it work for your use case.
So I'd vote for use ModelAdmin, but not the one you use in admin, hook a different template and come up with some fancy CSS.
I successfully created a software on top of admin.
The admin hooks (these days) allow very fine-grained customizations, i.e. in general you only need to touch what you want to change.
The changes can go from a trivial cosmetic adjustment to a complete swap-out:
If you provide templates/admin/base.html your admin site can look any way you like. And of course, a navigation bar at the top could include links to some of your own views. Watch out not to hardcode URLs in your links, always reverse.
You can overload ModelAdmin's "change_view", "changelist_view" etc. and swap them for your own views. For example I replaced a default changelist and its simple filtering with a search interface that allows dynamic queries to be built, result columns to be customized by the user, and loading/saving of these searches. That didn't affect any of the other views of that ModelAdmin.
Overloading a ModelAdmin's "get_urls()" let's you rewrap existing admin urls to go to your own views. I did the latter for one model where I wanted the simple Add screen to be replaced by a totally customized Wizard (only leaning on ModelForm).
Don't forget the simplest approach, esp. regarding your "AJAXy goodness": Just define "css" and "js" in your ModelAdmin's Meta. Want to move an inline from the bottom to sit between third and fourth field, and that's not possible via parameters? A one-liner in jquery.
Check out "django-grappelli" for an example of how to improve admin look and feel.
What did you mean by "and of course there's no conception of permissions or anything"?
Please share your thoughts abouts the following
When to use Django Forms to produce the HTML fields
When to avoid it and use the plain HTML
Any other tips and best practices
I use django forms or maybe another forms helper if I need something specific in every case, no matter what. I never compose forms using plain-old html.
Many aspects of form processing are not related to presentation. What kind of information needs to be collected and how to validate that certainly falls outside of the domain of presentation. Using a forms helper can help to unify all of this work in a pretty convenient way.
The fact that a forms helper can also render html is sort of coincidental to it's use. Certainly, if that's all they did, they wouldn't be worth much, but since they do all of that and stay in sync with the needs of the business logic, it somewhat requires using the html rendering from the form helper to reap the maximum benefit from the assistance it offers the rest of the app.
When to use Django Forms to produce the HTML fields
Django forms provide HTML forms for models, user-built as well as combination of both. One should be using Django forms most of the times since it considerably reduces the redundant templating effort. The tightly controlled security provided by Django forms along with the strong validation support is worth the effort to use Django forms.
When to avoid it and use the plain HTML
A good use-case to avoid Django forms is when you need to fire javascript events or there is a lot of style deviation from your main stylesheet.
Any other tips and best practices
Derive maximum advantages of the framework by using maximum features of the framework as possible.
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.