Re: read / write / visible fields

I had the same problems you describe (doing a "persons profile" type of 
object).
I am glad to hear that it is not only my lack of Archetypes zen that did 
provoke them.
Robert
Am Dienstag, 10. Juni 2003 15:05 schrieb Geoff Davis:
> 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.
> _______________________________________________
> Archetypes-devel mailing list
> Archetypes-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/archetypes-devel

-- 
mit freundlichen Grüssen

Robert Rottermann
www.redCOR.ch



-------------------------------------------------------
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.