logo       

read / write / visible fields: msg#00044

web.zope.plone.archetypes.devel

Subject: read / write / visible fields

Hi all--

I have been making a lot of use of Archetypes in building CMFMember, and I
have run into some headaches with a couple of aspects of the current
mechanisms for determining whether fields are displayed or not. In looking
through the code, I am noticing some convolutions appearing for dealing with
similar issues, so I think that the time is ripe for examining the issue.

I need fairly fine-grained control over when specific fields appear.
Archetypes provides some mechanisms for allowing me to do so, namely the
mode, read_permission, and write_permission attributes, but they are all
lacking in some regards.

Here are the kinds of things I would like to be able to do:
* I want users to be able to set their IDs at registration time but not
change them later. I would like to let administrators change user IDs.
* Similarly, in some scenarios I want users to not be able to set their
passwords at registration time, but I would like them to be able to set them
later on.
* I have some fields that I want to write to via code, but I do not want the
user to be able to write to them (e.g. last_login_time). I would like these
fields to be searchable.

The general problem I want to solve is:
(1) I want to display a subset of the available fields on a given form,
and
(2) I want to validate only the fields that I choose to display.

* Schemata address these issues to some extent, but the mechanism is not
sufficiently general. For my particular use case, I don't want to have to
have separate tabs for changing the ID or the password, so schemata aren't
appropriate.

* The mode and write_permission attributes address the issue to some extent,
and these are what I am currently using in combination with workflow, but
these mechanisms are slightly broken: if I use permissions to prevent a
required field from appearing on an edit form, I get validation errors.

One possible way to address this would be to do something like the
following:
* Define a convention for setting field attributes that can be used by
page templates to determine whether or not fields should be rendered. For
example, I could have a form that would only render fields in a particular
schemata for which attribute 'foo' is set.
* Force every widget to put something in the request if it is rendered on
a form. I think this would only require code changes for check boxes.
* Validate only fields that appear in the request.

I think the above procedure would give developers a lot more control of
forms and would simplify some of the core Archetypes code. In particular,
Schema.py's validate() method has some plone-specific cruft involving
validate_id that really shouldn't be in there..

Thoughts?

Geoff





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise