On 1/29/07, Thierry Benita <[EMAIL PROTECTED]> wrote:

This makes sense. I'll work with other sprinters in order to make this
piece of work more conform to Z3 model and use adapters on items that
implement IFileContent.
Is there some work in progress on the rewrite of portal_transforms ?
There is still an issue if we want to store sub-objects either in zodb
or filesystem. We'll investigate that.
Also the view will stay in skins as far as Plone can't support Z3 views
with correct caching policies.

I don't know if anything has been done on transform work. If I were
doing it, I'd start with a blank sheet of paper and design a generic
Zope 3 transform service. Off the top of my head, this would involve:

- An ITransformer interface; objects could be adapted to this to
perform a transform

- An ITransformData interface, which the ITransformer would adapt its
context to in order to get data to transform. This means that code
needing to transform "the data" of an object could adapt to the
ITransformerInterface, which would support generic functionality, but
would rely on the object having an ITransformData adapter to fetch the
data part.

- The transformer would probably take a callback object, an
adaptation to ITransformReceiver. This could be called synchronously
or asynchronously depending ont he ITransformer implementation, and
would be responsible for doing something with the transformed data.
Alternatively, sync/async could be an option when calling the
transform, e.g. have one method which would get the transformed data
(e.g. during rendering, when async makes no sense) and another which
could do it asynchronously (e.g. when saving an object).

- Mimetypes could be registered as named utilties implementing
IMimetype. No need for a separate tool, I don't think. Persistent
configuration could happen with local utilities.

- Available transforms would be named utilities as well. Or they
could be adapters of two mimetypes, but that gets a bit tricky because
you could quite easily have ambiguity. On the other hand, a transform
will be closely related to an input and an output mimetype, so maybe
it's a named multi-adapter from IMimetypeOne to IMimetypeTwo, where
both those are sub-interfaces of IMimetype.

I think a generic design like that wouldn't be too hard to dream up.
It could be a plain zope 3 package (plone.transform) - best to check
no-one has one of those yet. A lot of the actual transform code could
be lifted straight from AT (but the API to the transform function
should be less dumb). I don't think this is terribly hard and possibly
qutie fun. :)


Framework-Team mailing list

Reply via email to