Shouldn't there be a possibility to have fields that were not visible in the admin at all, like sorting paths for multilevel objects (i.e. categories), pickled objects, or other system data that makes no sense to "normal human beings". I would propose to have some attribute like visible=False or hidden=True, that would hide the system fields. Or field names with the underscore at the beginning could be handled as invisible from content administrators.
Regards, Aidas Bendoraitis aka Archatas On 4/10/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > 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 django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
