Hi, all I have a project going that requires the users to fill-out many different tabular data forms. So, I thought I would develop yet another table-generator. The main class (descended from OFS.SimpleItem) has a reorderable list of information (MT_ColumnInfo(Persistent)) about the columns (title, name, type, size, etc.) and another reorderable list of information about the rows (MT_RowInfo(Persistent)) (title, name), so that the column names and row names can be put together and I do not have to worry about getting R*C names right for each table. Anyway, I do not want to return any of these classes to DTML for processing. I want another class, CellInfo, which has the concatenated row and column names as name, and the type, size, etc. information from the Column information. A list of these with the title of the Row would be a row_data, so what I have to work with in DTML is the column_headings list and a list of row_data objects containing a list of CellInfos. All of these can be generated on-the-fly, so should not need to be descended from a Persistent Class. Less stuff to change if the table needs to be modified / reordered. But: In my usual trial-and-success blundering about, I find that unless these objects participate in the security system, I get "the login window that will not leave". So, I descend these objects from OFS.SimpleItem and give them default __ac_permissions__. Everything works as expected. Looking closer, I see that the thing really working is: descent from AccessControl.Role.RoleManager and __allow_access_to_unprotected_subobjects__=1. So I make these modifications, and everything seems fine. Allowing access to unprotected subobjects is cool, since these are non-persistent. Now for the question: What happened when I created un-attached Persistent descendents on-the-fly while testing earlier? I presume they garbage-collected away when I was done with them. Is this correct? I have a nagging worry about ghost objects and the types of programming errors that might create them. -- Jim Washington