Hi Skip,

>> It clearly isn't in use in this folder. Is this some kind of reserved >> word in Zope?

Jamie> yes

Is there some way to discover what these reserved names are, or do people have to just stumble upon them? For example, I have an SQL table I'd like to populate via Zope. It makes sense for me to name the fields in my Formulator form the same as the column names in the table. I can't always do this however, because I run into name clashes (like "title"). It's frustrating to me that there is no namespace separation between names used internally to Zope objects and objects created by users. If anything, it seems to me it should be Zope's internals which are forced to qualify names with special prefixes and suffixes, not Zope programmers. The affected population will be much smaller.

If one would make this distinction programmatically, these "internal" names would be no longer available for use; e.g. it would not possible to reach the ZMI via the "/manage" url. You would have to write a script or something for everything that should be public accessible (e.g. there has to be a "manage" script if the root accessing the "programatic" manage-method, if this method should not be reachable via the web.) If there would be just prefixes/postfixes naming conventions, this could have been possible, but beside of the "manage_" prefix naming convention this did not happen. I guess one had decided much earlier it is not very convenient to type "container.zope_id" and the like. Actually most of the "internal" names not supposed for public usage are prefixed with an underscore, thus You are already protected from a lot of things. Changing the current approach is also not an option due to backwards compatibility problems. I guess it would help You out of Your frustration if You would get a list of the "reserved" method names? (I have never tried to find out the "reserved" names (e.g. the python attributes of an object); this could be possible via an ExternalMethod hack using the python "dir" build-in, I guess. For names of acquired attributes I have no good idea, either). About the name clash issue with the SQL data fields: You could do pretty the same the Formulator does: prefix every field id with a fixed string which guarantees there are no naming conflicts. (E.g. "manage_" may be a bad option ;) "field_" should do nicely.) This is quite the opposite to the approach You propose, but it has the advantage it can doe in practice ... regards, clemens