Re: read / write / visible fields

Hi!

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

I also was thinking about these issues. My usecase was basically that
I need different views for an object starting from a basic one to
a more complex one depending on user experience or preferences.

I actually was thinking about some separation of the actual storage
definition done in the schema and the visual represenation (also discussed
with Ben a bit about it). 

My first though was to create some fascade in front of an archetype object
in order to "filter" the fields and let it create some view. Then I thought
that it also migth be possible with some xml document describing the
fields to display with their validators in this case (maybe even general
validators which test more than one field).  Also Labels and widget could
then be defined there and a field might even be represented by different
widgets in different views (e.g. one time some predefined list and one time 
some text field for the more experienced).
read/write etc. could then stay in the schema as validators for the storage
part. 

The most basic approach would of course be to write separate views manually
replace base_edit etc. but this is not the best way I think ;-)

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

Hm, here I also wonder if it's possible to remove this cmf relict that objects
are first created and then edited for the first time instead of first showing
the form and only after sending this creating the object. Right now it leads
to lots of empty objects created by users who just click on everything looking
what might happen. Then it would also be possible to define some add view
with the ID and then normal edit views without it.

-- christian


-- 
COM.lounge                                          http://comlounge.net/
communication & design                                 
info-WV3Fc3dYO6sqcZcGjlUOXw@xxxxxxxxxxxxxxxx


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