Folderish + Behavior + NameChooser = oddness

Hi,

I just found an effect that needs at least documentation or further 
discussion how to deal with it:

Given you have a behavior defining a field `foo` and add this to a 
folder and fill in the field `foo`. Now (by default) an attribute `foo` 
is set on the folder.

Now someone adds content (i.e. document) to the folder and name its 
Title `Foo`. It tries to get the lowercased title as id (Default 
NameChooser).

This goes down to `OFS/ObjectManager.py(106)checkValidId()`. There is 
also a check for Attributes, finds a `foo` already, so it is not allowed 
and it falls back to `foo-1`.

Now, for an average editor this does not make any sense. Because this 
happend silently he looks for a document namend `foo` and there is no. 
So he files a ticket in the projects tracker and bugs the developer.

So happend at a customer of mine.

And I'am sure this will happen again in future somewhere in the world in 
a different project.

Questions:

- Do we need to check for attributes?

- Why do we not make a clear difference between dict and attribute 
access (so dict=contained, attributes=...well...attributes/data.

- Can/Shall/Must we change this or is documentation of this oddness enough?

Jens
-- 
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/