[Zope-dev] Python Product Style - on-the-fly objects to DTML

[Jim Washington]

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