how can I clean a form field before the clean method?

[refreegrata]

Hello list, I want to do something like my_field = 1000(this value can
change depending of some situations, but the idea is a value injected
with Django, not with some data entered by the user in the HTML form.

I already try this:
-------------------------
def clean(self):
cleaned_data = self.cleaned_data
cleaned_data['my_field'] = 44
return cleaned_data
-------------------------
and this
--------------------------------
def clean_my_field(self):
return 44
--------------------------------

but don't work, I think that the exception is launched before of the
summoning to any of this functions. How can I solve this situation?
The idea isn't do an edition in the view of the request.POST

Thanks for read, and sorry for my poor english.

[wayne]

Well, it depends on how sensitive and dynamic my_field needs to be.
You could always pre-populate the form with my_field set to a value,
and mark its input type as hidden (if it is not sensitive).

If you are working with a ModelForm, you could use one of the methods
here: http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a-subset-of-fields-on-the-form.

Lastly, you could do it in the view during your processing of
request.POST, as you mention. Doing it in one of the validation
methods like you mention _should_ work, but I usually like to keep my
clean methods validation-only (and not use them to manipulate data).

Wayne

[refreegrata]

Ok, with hidden fields. But if the user manually, with some tool,
change the value, thats will be a problem. For my safety I must to use
the hidden fields and still keep the clean methods to overwrite any
possible editing over the fields value. Originally the idea of this
post was search a way to prevent the double assign(in the init and the
clean methods), but apparently isn't possible.

Thanks for the answer.

[wayne]

It isn't possible because you are, in actuality, asking two questions:

1. How can I set the value of a field on the server w/o client
interaction, and
2. Ensure that the client doesn't do something malicious

Number one is something that you should take care of in your view or
model (__init__, perhaps), and number 2 is a validation issue.

Since you said you didn't want to handle it in your POST processing,
which is the only way you can set it once and take care of both issues
(because you're doing it at the end of the chain), you will have to do
it twice, no matter what method/idea/framework you use.

[refreegrata]

Yes, you have reason. I prefer use something like an "exclude" or
"fields" tuple in the form meta, and set default values in the model
to the fields that I need, but some of the default values are foreign
keys.
I want to do something like:

aaaa.default = MyModel.objects.get(field=True)

and raise an exception if don't find in the table a row with a field =
True, but I don't have idea if something like this can be done.

Thanks for read and sorry for my newbies questions.

[wayne]

> I want to do something like:
>
> aaaa.default = MyModel.objects.get(field=True)
>
> and raise an exception if don't find in the table a row with a field =
> True, but I don't have idea if something like this can be done.
>

I'm not always real good at understanding what someone wants.
However, it sounds as though you want to build a dynamic form (some
fields set dynamically, in response to certain conditions), but NOT
have the user mess with these things. The ways you mention to keep
the fields out of the form are the normal ways, but if you are going
to build a dynamic form without doing it in the POST view, etc., you
would normally do it with a custom __init__ method for the form. But
since the fields have been excluded, I think this would put you back
into the problem of marking form fields as hidden or something.

This kinda gets to be a circular problem primarily because the
function of a form is to accept user input, not hide it. I'm sure you
can do it, but it really just becomes a case (in my opinion) of
trying to pound a square peg into a round hole.

If I understand you correctly, my advice would be to validate the data
in clean(), and then to handle the object lookup in a pre_save()
signal catcher (in the model) and bail from there if the value isn't
found.

> Thanks for read and sorry for my newbies questions.

No apologies; we're all just talking and learning here ;) I hope I've
been able to contribute to the overall conversation.

[refreegrata]

ok, thanks for the answer. I have a final question. The other way is
in the __init__ set initial values in hidden fields, but if the user
(malicious) edit the value in some of this fields the form is invalid,
and the form comeback, but with the values edited for the user and the
error messages. Can I reset the initial values for the hidden fields
before of return the form?

[Wayne Smith]

Sure.  Just override the clean method for the field, or the whole form if you wish.  The built-in "default" validation done by Django doesn't handle any logic; it just makes sure the format and type of each field is appropriate.

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>