The Dexterity storage layer story is a flaw

Hi there,

in the Archetypes world I could explicitly specify the storage layer
(attribute storage, annotation storage etc.) as part of the schema
definition on the field level.

Now with Dexterity it became much more complicated to implement
a different storage strategy for fields. In my case I want to implement
an XML field (holding XML data). The XML data could be stored in Plone
or an external database. Content types can have multiple XML fields
with arbitrary field names and arbitrary storage strategies.

It is widely considered that behaviors should be in charge for
implementing a different storage strategy. At least with the current
implementation of behaviors this is not possible for the most general
case. Behaviors can introduce new fields with a fixed field names and
a fixed storage strategy. A behavior does not work very well with
changing the behavior of fields defined and introduced outside the
behavior. There are ways to implement this through behavior but
the approach feels broken and inconsistent.

So there remains the way to implement different storage strategies
on the field level (e.g. through two different field implementations
like XMLAttributeStorage and XMLExternalStorage....this is against
the widely considered best practice that fields are the wrong place
to implement storage strategies.

Thoughts?

-aj

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk