Bind with code

There's two ways to use FSS from content types.

# Usual Zope/CMF/Plone/Archetypes imports
...
from Products.FileSystemStorage.FileSystemStorage import FileSystemStorage
...
my_schema = Schema((
    FileField('file',
    ...
    storage=FileSystemStorage(),
    widget=FileWidget(...)
    ),
    ...
)
...

...
from Products.FileSystemStorage.FileSystemStorage import FileSystemStorage
from Products.ATContentTypes import atct
...
field = atct.ATFile.schema['file']
field.storage = FileSystemStorage()
field.registerLayer('storage', field.storage)
...

Bind by configuration

Well, the best option is... Creating a ZCML directive for this. Let's have a look on how to store ATFile content using FSS service from any "configure.zcml":

<configure
   xmlns="http://namespaces.zope.org/zope"
   ...
   xmlns:fss="http://namespaces.ingeniweb.com/filesystemstorage">
  ...
  <fss:typeWithFSS
     class="Products.ATContentTypes.atct.ATFile"
     fields="file" />
  ...
</configure>

Self explanative, doesn't require any comment for Plone integrators, doesn't expose or require any specific API.

Now I have defined this, we now need to add the machinery that makes the glue between that elegant ZCML bunch and the deep inners behind the scene.

Digging deep into the Zope startup process, notably through Five, and we can notice that:

• Five processes a bunch all "meta.zcml", that define the various namespaces and elements that may be used in the "configure.zcml".
• Then it processes all configure.zcml, those configure.zcml mainly make the high level glue between the various components and products of the instance.
• Finally it processes overrides.zcml, if any that may change standard settings provided in the above configure.zcml.

This is a short version and curious people will have a look at $INSTANCE_HOME/etc/site.zcml to see the details on how to customize the ZCML setup. Note that with some magic of Five, you don't need to change anything here if your main zcml files (meta.zcml, configure.zcml and override.zcml) are in a Zope 2 style product.

Okay, aren't you asleep or lost reading this long and boring technical recipe? No? So let's continue and grab into the depth of the code!

As stated above, I need to define the schema and handler of the element <fss:typeWithFSS ... from a meta.zcml and a bunch of Python modules.

The meta directive

In my case, this is a simple element [†] and stuff will be somehow easy since I got the ZCML enlightenment. We can define the such primary definition in the "meta.zcml":

 1 <configure
 2    xmlns="http://namespaces.zope.org/zope"
 3    xmlns:meta="http://namespaces.zope.org/meta">
 4   <meta:directive
 5      name="typeWithFSS"
 6      namespace="http://namespaces.ingeniweb.com/filesystemstorage"
 7      schema=".zcml.ITypeWithFSSDirective"
 8      handler=".zcml.typeWithFSS"
 9   />
10 </configure>

Let's dig into it:

• Line 3: Don't forget to say we're defining a meta, defining its namespace.
• Line 5: We define a simple directive, the simplest possible.
• Line 6: The name of our diective.
• Line 7: The namespace for this directive as seen above in the sample configure.zcml.
• Line 8: The schema (read attributes in our case) of that directive is defined by a Zope3 interface.
• Line 9: The handler function that will be invoked for each <fss:typeWithFSS ... directive found at Zope startup.

To keep the things simple, the schema and the handler belong to the same module, zcml.py

The schema

The people who already made components based on Zope 3 formlib will be familiar with such notation. A scema is just a Zope 3 interface that defines in its Python attributes the XML attributes expected from your directive.

from zope.interface import Interface
from zope.configuration.fields import GlobalObject, Tokens, PythonIdentifier
...
class ITypeWithFSSDirective(Interface):
    """Schema for fss:typeWithFSS directive"""

    class_ = GlobalObject(
        title=u'Class',
        description=u'Dotted name of class of AT based content type using FSS',
        required=True)

    fields = Tokens(
        title=u'Fields',
        description=u'Field name or space(s) separated field names',
        value_type=PythonIdentifier(),
        required=True

All these configuration fields are defined in the zope.configuration.fields package. Have a look to this package to see what other attribute types I could have used. Note that the attribute types inherit from zope.schema resources that are familiar to Zope 3 formlib developers.

Some comments:

• If your attribute is not required, you may give a default value.
• You may use a Tokens attribute type where you need multivalued attributes from the configuration, as I needed for the "fields" attribute. In that case, you define the type for each single value in the value_type keyword argument.

In our case, you can notice the class attribute of the interface maps automatically to the class attribute expected from the configuration directive. This is a magic that maps all XML attributes named with a Python keyword as class, "for" and the rest.

The handler

The handler will be invoked with all directive objectized attributes as arguments.

def typeWithFSS(_context, class_, fields):
    """Register our monkey patch"""
    _context.action(
        discriminator=class_.__name__,
        callable=patchATType,
        args=(class_, fields)
        )

def patchATType(class_, fields):
    """Processing the type patch"""
    for fieldname in fields:
        field = class_.schema[fieldname]
        field.storage = FileSystemStorage()
        field.registerLayer('storage', field.storage)
        LOG("Field '%s' of %s is stored in file system.", fieldname, class_.meta_type)
    return

The signature of the handler:

• _context: a context object defined and documented in details in zope.configuration.interfaces.IConfigurationContext interface. We'll talk about it later.
• The various attributes in the order of the schema. Optional attributes should be passed as keywords args with a default value, but we have no optional argument in our example.

You can see that we could immediately patch the content type, using directly the "patchATType" function body inside the handler.

But it's a much better practice to let the zcml machinery execute as late as possible that function, and warn on potential conflicts of ZCML configuration directives.

In that intent, I prefer to register the FSS in the content type invoking the _context.action(...) with a discriminator on the class name that will automatically warn on duplicate FSS patch on the same content type class.

Have a look at the interface of the _context object. There are in lots of other valuables services that you may use in other situations.