On Mon, 2007-04-09 at 18:28 +0000, [EMAIL PROTECTED] wrote:
>
> There is a problem with:
> http://code.djangoproject.com/ticket/3247
> http://groups.google.com/group/django-developers/browse_thread/thread/50150b61aca46a7e
>
> I've made a first working version but my implementation reverses the
> changes described in the above ticket/discussion. Here's a summary of
> what I did:
>
> - cancel filtering of editable=False fields when creating forms for
> instances and models (ie the fields are in the form, hence the above
> remark)
> - added an editable (default value True) field in newforms.Field
> - added a DisplayWidget, and made Field use it when editable = False
Without seeing the patch, it's hard to comment on specifics, but this
feels like more machinery than I would have expected. Why isn't this
just a matter of inserting a single static string when they reference
{{ field_name }} in the form? You might need a dummy widget to give it
the right method, but I'm not sure why the editable attribute is needed
in Field. A non-editable field shouldn't ever participate in the form
submission process, for example.
The main argument *against* having any support at all for non-editable
fields in normal forms is that you can just insert their value directly
yourself. This argument breaks down a little in the case of the admin
app, since there is a benefit in being able to read the values of
non-editable fields when editing other fields. I would still have
thought it was close to a one-method class, though (okay, maybe a little
more than one method, but not a lot).
> Please tell if that is acceptable. Again, there seem to be an issue
> with naming. Maybe there should be a name for fields that can be
> created by the user but only seen afterwards, and purely internal
> fields which are not even displayed.
No. For a form created by a person, if you don't want the field
displayed, don't put it in the form. That's up to the template designer.
For the admin, there is the list of fields to display (presumably
there's something similar in newforms-admin).
If you want that sort of control, you may not be able to use
form_for_instance() and form_for_model(). Not a big deal. They're aids
for common cases. Uncommon cases, like treating different non-editable
fields differently might require the developer to write a helper
function.
> Maybe those options could be spread out between the model and the
> admin class ? The current semantics of editable make sense for models,
> but what I'm doing would be relevant only for the admin.
I don't understand this. Open a ticket and attach the patch might be
easiest. I can't see why this is admin specific.
[...]
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
