Ticket #6705

[James Bennett]

Ticket #6705 [1] proposes that 'form.errors' be changed to somehow
provide a "prettier" display not based on the underlying field name
(which is currently used as the key in the errors dictionary).

The person who opened this ticket contends that it is a common issue,
and that there is no existing way to work around the desire to simply
do '{{ form.errors }}' in a ticket and have it display as he desires.

Personally I'm of the opinion that granular error output and
customizable error classes, though not precisely the solution asked
for in this ticket, provide adequate options at both ends of the
spectrum (granular output for fine-grained form display, custom error
classes for the simple case of printing a form), but the submitter has
repeatedly reopened the ticket and asked for broader consideration.
Since the submitter has not followed repeated advice/trout-slapping to
the effect that this list is a better discussion medium, I'm bringing
it up on his behalf.

Thoughts?

[1] http://code.djangoproject.com/ticket/6705

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Dj Gilcrease]

On Tue, Mar 4, 2008 at 10:59 AM, James Bennett <ubern...@gmail.com> wrote:
> Thoughts?

he cant do something like http://dpaste.com/38006/ ?

[Collin Grady]

Dj Gilcrease said the following:

> On Tue, Mar 4, 2008 at 10:59 AM, James Bennett <ubern...@gmail.com> wrote:
>> Thoughts?
>
> he cant do something like http://dpaste.com/38006/ ?

Should probably be field.label instead of field.label_tag, no? :)

--
Collin Grady

"I don't think so," said Descartes. Just then, he vanished.

[James Bennett]

On Tue, Mar 4, 2008 at 9:22 PM, Dj Gilcrease <digit...@gmail.com> wrote:
> he cant do something like http://dpaste.com/38006/ ?

The desired case is for {{ form.errors }} to somehow do something
similar, but automatically.

[Malcolm Tredinnick]

On Tue, 2008-03-04 at 12:59 -0600, James Bennett wrote:
> Ticket #6705 [1] proposes that 'form.errors' be changed to somehow
> provide a "prettier" display not based on the underlying field name
> (which is currently used as the key in the errors dictionary).
>
> The person who opened this ticket contends that it is a common issue,
> and that there is no existing way to work around the desire to simply
> do '{{ form.errors }}' in a ticket and have it display as he desires.

Given that the unicode() form of ErrorList is apparently intended as a
string that is intended to be inserted directly into an HTML form, I
suspect the submitter has a valid request. The form field label should
be used as the default display name for a field attribute, when it
exists and ErrorList.__unicode__() (which is ErrorList.as_ul()) seems to
be intended as something for display output.

It's by no means a showstopper, since subclassing is a pretty easy
option to change this, but, on balance, using the field label is
probably the more natural thing there. My thinking here is that it's
never going to be wrong to use the field display name, when it exists,
in a case like this.

Malcolm

--
Why can't you be a non-conformist like everyone else?
http://www.pointy-stick.com/blog/

[oyvind....@gmail.com]

The problem with form errors is that this is not the ErrorList, but
the ErrorDict.

Two problems with this, ErrorDict has no way to find out what the
label of the field is and a ErrorDict subclass cannot be passed in to
the form like Errorlist using error_class.

Should ErrorDict be passed a tuple, (fileld.label, e.messages) instead
of just e.messages as it currently does?

http://code.djangoproject.com/browser/django/trunk/django/newforms/forms.py#L212

Should it be possible to pass in ErrorDict too changing error_class to
error_list and adding error_dict?

On Mar 5, 12:29 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Emilian Felecan]

So you are ubernostrum ;-) Saw your talk on the reusable apps.

Thanks for bringing the issue to the dev group.

This is an issue I would like to work for at the sprint, if anybody is
willing to hold my hand so to speak.

Thanks,
Emilian

[Emilian Felecan]

There seems to be another issue related with
the form errors.

For example, in the ValidationError class the
error messages are an instance of ErrorList regardless
of if you have error_class defined or not.

So even if you are passing in a different error_class
(to the form) the field level errors would still be ErrorList.

Thoughts on how to handle this?

Emilian

[oyvind....@gmail.com]

Take a look at http://code.djangoproject.com/ticket/6790