Hi all,

Marcos Romero and Juan Pablo Gimenez have contributed a nice branch to help us 
get rid of the anachronistic use of AnnotationStorage and ATFieldProperties 
currently used in the archetype template's atschema local command.  I have some 
questions about the work, and about the issues surrounding this usage, and I'd 
like to solicit some input from the zopeskel community.

First, Marcos and Juan Pablo have removed the parts of the recipe that put 
'title' and 'description' into annotation storage and create automatic field 
properties for them.  I think we can all agree that this is a good move and I'm 
all on board with it.  Are there any objections from the peanut gallery about 

Second, they have discontinued the use of annotation storage by default for all 
field types except 'file', 'image' and 'text' fields.  Here is where I start to 
have some real questions.

1.  Is there a reason that annotation storage is more appropriate for these 
three field types than for other field types?  IOW, is it to be considered 
solid best practice that these three field types use annotation storage in the 
general case?

2.  Since only these three field types use annotation storage, fields of this 
type are also the only ones that get ATFieldProperty python property bridges 
set up, and they are also the only fields that end up in the zope schema for 
the new content type.  If you have a mix of fields including these types as 
well as others (string, integer, boolean etc), then you end up with a zope 
schema defined for your content type which differs a great deal from the 
archetypes schema.  Is this a good idea?  It seems problematic to me.  Any 
suggestions of a better way to handle the issue?

I see two ways right off the bat for handling the second issue.  On the one 
hand, we could simply relegate the concept of ATFieldProperties and the 
creation of a zope schema for AT-based content types to the dustbin and stop 
generating either.  On the other hand, we could establish a pattern of creating 
ATFieldProperties with some sort of prefix on their names to avoid collision 
with attribute-stored AT fields and create zope schema which include _all_ the 
fields defined in the at schema (probably including title and description).

Any other possibilities?  Any advice on what the best way to clean this up 
might be?  What is considered to be 'best practice' for this issue?

Thanks for your input,


Cris Ewing
Webmaster, Lead Developer
Department of Radiology Web Services
University of Washington
School of Medicine
Work Phone: (206) 616-1288
Cell Phone: (206) 708-9083
E-mail: cew...@u.washington.edu
Web: http://www.rad.washington.edu

ZopeSkel mailing list

Reply via email to