[Zope] folder name problem

[Clemens Robbenhaar]

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