[Zope-CMF] Class based vs TTW for Schemas.

[Sidnei da Silva]

On Wed, Feb 25, 2004 at 05:28:25PM +0100, Lennart Regebro wrote:
| In CPS, we do the member management through directories. In CPS3, these 
| directories are based on CPSSchemas, which makes it possible for us to 
| define the schema of a user and then have the directories display this 
| schema (just like Archetypes) for each user without any actual member 
| objects existing.
| I'm not sure if this is possible with Archetypes, maybe it is. But as I 
| understand it you create a python class for each schema, which would 
| only complicate things. So that is one point.

Not necessarily. By default, a schema is defined on the 'schema' class
attribute of a given class, and then retrieved via the Schema()
method, which default to just return the schema attribute of the
object (which may have been overriden on the instance or not, thus
defaulting to the class attribute). The schema is an instance of the
'Schema' class. This 'Schema' instance can be shared between many
content types if you wish to. You can even combine schema instances
(schema1+schema2=newschema). From what I understand about your
description, you would like to have a 'schema repository' where you
can see (and maybe modify) existing schemas. Thats a nice goal,
IMHO. It would also allow for one to tie a schema to a class using a
name, which would be looked up on this 'schema repository'.

| A next point is that CPS by default sets up a member schema with  first 
| name and last name, and such. No problem there. However, the NuxWebMail 
| product needs to have a IMAP username and password associated with the 
| user. This is simply done by adding these two fields to the schemas in 
| the NuxWebMail setup. I don't se how this can be done with a schema 
| defined in a python file.

It's an instance of a 'Schema' class, which has methods for modifying
the schema. (addField, removeField, etc).

| Also, the ttw design of CPSSchemas means that we have a TTW interfaces 
| for managing vocabularies, so that a manager can change them. No Python 
| hacking, not even fiddling with dictionaries in a skin is needed.

You can do the same on Archetypes, though its not the default setup
and we dont have a vocabularies tool. Usually, you tell a field to use
a method to get the vocabulary, and then this method can build the
vocabulary from a TTW-editable tool or object or catalog query or
whatever. The PublisherInventory (collective) uses this feature.

class Foo:

  schema = Schema(....
              StringField('vocabfield',
                          vocabulary='_getVocab',
                          widget=SelectionWidget())
       )

  def _getVocab(self, instance=None, field=None):
      v_tool = getToolByName(self, 'portal_vocabularies')
      vocab = v_tool.getVocabFor(instance, field.getName())
      return DisplayList(vocab)

| And last, and maybe least, already two years ago I started working 
| together with Johan Carlsson on something we had an idea of. Something 
| we wanted instead of ZClasses, namely a way to create useful classes 
| without programming, or possibly with only very basic simple scripting, 
| all TTW. I have often found a need to create simple classes that really 
| need almost no programming, just a bunch of properties. For me as a 
| programmer that is of course no problem to create a disk based class, 
| but for others? I have always felt that ZClasses is supposed to fill 
| that slot, but fail, because they are even more complicated to wrap 
| their head around than disk based classes. I think CPS Schemas comes 
| very close to that vision. You can have a site manager that adds and 
| changes classes without having to program python.

I've given some thought to this subject too, and I came to the
conclusion that this could be easily achieved by having a 'Dummy'
cmf-aware content type, that would be then used to create new portal
types using the types tool, and then one could just attach archetypes
schemas to this portal type. (optimally using Kapil's Annotations tool)

-- 
Sidnei da Silva <sidnei at awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

The program isn't debugged until the last user is dead.