Description

form = Form(request.GET)
if form.is_valid():
name = form.cleaned_data['name']

Then initial value of name is lost even if request.GET does not contain name as key.

Why there is not just "default" attribute that would maintain the default value until being explicitly overwritten by request data? There are so few things I find inconvenient in Django but this is one of them.

Oldest firstNewest firstThreaded

Show commentsShow property changes

Change History (5)

Sorry, but your use case is not very well explained. When providing an initial value, it should show up in the form, and then it's the user's ability to change it to something else. For any special use case, you are free to subclass any clean_[field_name] methods to implement any additional logic you'd like to have (like some default).

Seems quite natural to me. But I have found out that checkboxes in frontend are not checked after the initial page load (without any query params). And later I have found out it is because form has been bounded to request.GET data. But mainly the crag_list was empty because the initial values has been lost. So I have decided to do this in the view:

But I have worked on and discovered yet another problem with order_by and order_asc fields. These fields are not part of the frontend form (by graphic design and provided templates) but it seemed natural to put them into the backend/logic form anyway so that I can simply pass these parameters to model (to the method get_objects) with others and then in the model differentiate what to put as param of .filter() and what to put as a param of .order_by(). This approach simply makes view simpler (which is good, I think). Backend form does not "match" the frontend/rendered form but it was (and should be) possible to do it like this without any javascript hacks and it worked well. Except from initial values because checking if request.GET is empty before passing it to the filter was no longer working. Basically, if querystring has not been populated, submitting the form trashed initial values for ordering and submitting the ordering trashed initial values for filtering. In the end I needed to do something like this in view:

which was really painful. Maybe there is some other option with some clean_[field_name] methods but that is painful too.

Well, allright I understand that I can't expect "the initial" values to behave like "default values" (except I totally did when I was learning about forms.) but I don't understand why there is not the "default functionality" that would work in the same way like that one for models. It would cover the "initial functionality" but also would be more solid, robust and intuitive...basically it would decouple frontend (rendering) functionality from backend (logic) functionality.

Thanks for sharing your use case. You have to admit that it is somewhat specialized, and do not match the traditional form usage. So I maintain my original opinion, and with using clean_order_by-type methods you can easily achieve your goals.

I think the role of a framework is to 1. provide easy-to-use tools for the 80% of use cases, 2. provide ways/hooks to customize for the 20% special needs. And I think the current implementation does a rather good job in this regard.

But of course, you are free to discuss that and get opinions from others on django-developers mailing list and point to this ticket for more details.