editable attribute limitation
Philipp...@gmail.com
models but this make them disappear from the admin interface, both
when creating and modifying an object. I think it would be useful to
be able to specify readonly fields that would be defined and validated
when the object is created and not editable later.
Regards,
Philippe
Malcolm Tredinnick
There is already a ticket open about this in Trac. We'll get to it at
some point. Somebody could move it along by posting a patch for
newforms-admin if they wanted to.
Regards,
Malcolm
Philipp...@gmail.com
http://code.djangoproject.com/ticket/1714
http://code.djangoproject.com/ticket/342
I'm currently trying to create a patch but I'm not really confortable
with changing options so I'd rather have input from the devs.
Currently, "editable=False" for a field really means private, because
it never shows in the admin forms. The behavior I'm trying to
implement would be more like a const value in OO: you can set it when
creating the object and then only read it. I'd suggest that we rename
"editable" to "private" and add a "const" option but those are really
OO concepts/words. Anyone has more database-related ideas ?
Regards,
Philippe
Malcolm Tredinnick
Just leave it as "editable" and have it behave as its name says: if
editable is True, you can edit it, otherwise only display it in forms.
The current behaviour is only because we don't display non-editable
field.
Editable only applies to form (and other front-end, if the developer
wants to use the attribute for that) handling. It would be
counter-intuitive to try and graft a true "const" into models, because
we are writing in Python, after all, and Python does not have a const
type. The editable attribute describes form access bheaviour. So just
make it displayable as a static string in the form/page when editable is
False.
This shouldn't be too hard. You dont' (and shouldn't) have to worry
about HTML widgets or anything like that. Just display them as static
fields. In the past, people have tried to argue that these should be
"readonly" or "disabled" and use the same widget as if they were
editable, but that's not useful: they are not editable, so are never
going to become enabled or readable and you would only have to check
that the field values hadn't changed (or ignore them, so iterating
through the field list is now harder) if they were part of the form
input.
Regards,
Malcolm
Philipp...@gmail.com
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
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.
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.
Adrian: I've cc'd you so because you seem to be working on newforms-
admin. The context of this message is at
http://groups.google.com/group/django-developers/browse_thread/thread/1d7d8cb0662181c6
Regards,
Philippe
Malcolm Tredinnick
>
> 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
Aidas Bendoraitis
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
Philipp...@gmail.com
http://code.djangoproject.com/ticket/3990
Please note that the submitted is different from what we discussed. I
have created a new option for the AdminModel class and left the non-
editable fields out of the picture.
Aidas: what you're looking for is editable=False :)
Aidas Bendoraitis
only this discussion, but not the ticket information.
Regards,
Aidas Bendoraitis aka Archatas
James Stembridge
On Apr 10, 1:41 pm, "Philippe.Rao...@gmail.com"
<Philippe.Rao...@gmail.com> wrote:
> http://code.djangoproject.com/ticket/3990
Perhaps a simpler way of handling things:
1. Leave the current behaviour of "editable=False" as is, i.e. if set
the field will not by default appear in the admin interface.
2. Allow "editable=False" fields to be included in the "fields" Admin
option to override the default behaviour and display whatever they
contain.
Any thoughts?
James.
Baptiste
patch... which fits exactly to what I needed. It is imo an useful
change - and not only because I would need it - that should be
integrated in the core.
On 10 avr, 14:41, "Philippe.Rao...@gmail.com"
Philipp...@gmail.com
I like your idea because it doesn't add a new option to the admin
class. I went for the simplest possible implementation while this
would require modifying a bit newforms to allow editable=False fields
to be forced in. On the other hand, one might want to have some
editable=True fields as readonly in a specific admin interface
(newforms-admin now makes it possible to have multiple admin sites
AFAIK) so your solution wouldn't cover as many use cases.
Ultimately it's up to the core devs to decide whichever makes more
sense.
Regards,
Philippe
Malcolm Tredinnick
I would hope that is what we end up doing. It's exactly what the
"fields" attribute in the Admin class (or it's equivalent in
newforms-admin) is for.
Regards,
Malcolm
Philipp...@gmail.com
I don't think one it's possible to add to the "fields" admin option,
so you'll end up having all editable fields in it:
class MyModel()
field1 = models.CharField(editable=False)
field2 = models.CharField()
...
fieldn = models.SomeField()
Class MyModelAdmin()
fields = {"field1", "field2", ... "fieldn"}
Which is not very DRY, because all fields except field1 would have
been there anyway.
Besides, we still need the "readonly_fields" option to make
editable=True fields readonly in the admin interface. For example:
Class MyModelAdmin()
readonly_fields = {"field1", "field42"}
would made field1 and field42 editable in the add form and readonly in
the change form. It has the added benefit of being more consistent
because fields in the "fields" options are editable and fields in
"readonly_fields" are readonly. Otherwise we end up doing "magic"
depending on whether a field in "fields" is editable or not.
I thus propose to update my patch to do the following:
1) add a "readonly_fields" options in the admin class
2) said option will accept a list of model fields (regardless of their
editable status), which will be editable in the add form and displayed
in the change form
3) editable = False fields will raise an error when added to the
regular "fields" list
I'm really not so sure about 3. We could make "fields" move non-
editable silently to "readonly_fields" instead (and then rely on the
behavior described in 2).
I will update my patch to support feature 2 and wait on input as for
3.
Regards,
Philippe
Malcolm Tredinnick
>
> I don't think one it's possible to add to the "fields" admin option,
> so you'll end up having all editable fields in it:
>
> class MyModel()
> field1 = models.CharField(editable=False)
> field2 = models.CharField()
> ...
> fieldn = models.SomeField()
>
> Class MyModelAdmin()
> fields = {"field1", "field2", ... "fieldn"}
>
> Which is not very DRY, because all fields except field1 would have
> been there anyway.
In the relatively rare case when you want to display a non-editable
field in admin, you might need to list them all. This is part of making
the easy things easy and the harder things possible. I don't see it as
worth it to add a whole extra piece of infratsructure for a relatively
rare situation when you can just list the fields using existing
mechanisms. The act of writing them out *once* in that list won't kill
people.
> Besides, we still need the "readonly_fields" option to make
> editable=True fields readonly in the admin interface. For example:
Why is this needed? The field is marked as *editable*, hence it's not
read-only. The admin app is for trusted users to edit records. If you
want fine-grained control where administrators should not be editing
particular fields that they could edit when they are not administrators,
write a custom form. Even the current admin application allows custom
forms for model editing and newforms-admin will, presumably, as well.
> Class MyModelAdmin()
> readonly_fields = {"field1", "field42"}
>
> would made field1 and field42 editable in the add form and readonly in
> the change form. It has the added benefit of being more consistent
> because fields in the "fields" options are editable and fields in
> "readonly_fields" are readonly. Otherwise we end up doing "magic"
> depending on whether a field in "fields" is editable or not.
>
> I thus propose to update my patch to do the following:
> 1) add a "readonly_fields" options in the admin class
> 2) said option will accept a list of model fields (regardless of their
> editable status), which will be editable in the add form and displayed
> in the change form
> 3) editable = False fields will raise an error when added to the
> regular "fields" list
I think you are trying to graft too much fine-grained control into the
admin app. I don't like this design for that reason. -1 from me.
This whole thread started out as adding support to forms for read-only
fields. That really isn't a hard thing to do. It seem to be have become
overly complicated trying to graft the equivalent of C's "const"
behaviour into form fields, which feels wrong on a number of levels.
Regards,
Malcolm
Baptiste
customization to make it user-friendly. That may be a feature, but
that is really boring to need to write its own admin because of the
limitations of the existing one.
In my case, I just have a ForeignKey to an User. At the first save,
user is automatically filled with the request.user. But after that, I
would like to display the author on the editing page, for information.
Simple (and generic) demand, and that patch allows it.
I am just against the special "readonly_fields" because that would
prevent us to organize fields like we want.
I would prefer that, imo :
fields = (
(None, {'fields': ('title','url','text')}, {'readonly_fields' :
('author')}),
(_("Options"), {'fields': ('date','lang'), 'classes':'collapse'}),
)
On 16 avr, 11:47, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> On Mon, 2007-04-16 at 08:58 +0000, Philippe.Rao...@gmail.com wrote:
> ...