[Zope-CMF] Re: CMFSetup content I/O

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Florent Guillaume wrote:
> What the status of people's various projects dealing with I/O of content
> using CMFSetup? That's something I'll be working on for CPS in the next
> few weeks, and also maybe at the Castle Sprint if there's interest.

I have a functional prototype (more than that really, but it would need
a slight bit of tweaking), and a half-done proposal which I am due to
finish this week, which uses the import and export contexts of the setup
tool to dump and reload content using adapters.  Enfold has some work
underway to make the Marshall product supply those adapters for AT
content types.

> Has anybody thought about the begining of standardization for the
> document structure? For the hierarchy itself? And CPS will have to deal
> with versioning.
> 
> I guess the dublin core is easy to export as RDF, but for the rest, for
> instance generic fields? File or Image fields will probably end up as
> real files, but how about their metadata?

The framework I am specifying avoids mandating specific file formats,
because they vary so much due to external customer requirements.

To preview the proposal:  the basic requirement is that the application
register adapters for IFilesystemExporter and IFilesystemImporter
interfaces for the types to be dumped.  Those interfaces look like::

- --------------------- 8< ------------------------------
class IFilesystemImporter(Interface):
    """ Plugin interface for filesystem import of content/structure.
    """
    def import_(import_context, subdir):
        """ Import our 'context' using the API of 'import_context'.

        o 'import_context' must implement
          Products.GenericSupport.interfaces.IImportContext.

        o 'subdir', if passed, is the relative subdirectory containing
           our context within the site.
        """

class IFilesystemExporter(Interface):
    """ Plugin interface for site structure export.
    """
    def export(export_context, subdir):
        """ Export our 'context' using the API of 'export_context'.

        o 'export_context' must implement
          Products.GenericSupport.interfaces.IExportContext.

        o 'subdir', if passed, is the relative subdirectory containing
          our context within the site.
        """
- --------------------- 8< ------------------------------

A typical adapter, for content which can be represented as CSV text,
would be as follows (the content has methods 'as_csv' and 'put_csv')::

- --------------------- 8< ------------------------------
class CSVAwareFileAdapter(object):

    implements(IFilesystemExporter, IFilesystemImporter)

    def __init__(self, context):
        self.context = context

    def export(self, export_context, subdir):
        """ See IFilesystemExporter.
        """
        export_context.writeDataFile('%s.csv' % self.context.getId(),
                                     self.context.as_csv(),
                                     'text/comma-separated-values',
                                     subdir,
                                    )

    def import_(self, import_context, subdir):
        """ See IFilesystemImporter.
        """
        cid = self.context.getId()
        data = import_context.readDataFile('%s.csv' % cid, subdir)
        if data is None:
            import_context.note('CSAFA',
                                'no .csv file for %s/%s'
                                    % (subdir, cid))
        else:
            stream = StringIO(data)
            self.context.put_csv(stream)

- --------------------- 8< ------------------------------

I would like to add a 'listExportableContent' method to the exporter
interface, to allow the adapter to dictate which subobjects get dumped;
my current implementation does something like::

  subobjects =filter(None, [IFilesystemExporter(x, None)
                              for x in context.objectValues()[)

One interesting thing about the current implementation is that it is
built atop the GenericSetup tool (the project for which I built it has
no CMF dependencies at all).

The proposal will likely address a couple of additional issues:

  - "lossless" versus "lossy" formats

  - "standardized" representations of certain types of data (e.g.,
    your intuition that some serialization of RDF would be a good
    representation of Dublin Core)

  - comparison with efforts like the JCR export format.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHG7I+gerLs4ltQ4RAsQZAJ95KnkXsLM+CET58+mDWm+DWyf+ggCfdHU1
DCoDq/9SY+xFUcjzPsRnWfs=
=WDkI
-----END PGP SIGNATURE-----