Re: The Dexterity storage layer story is a flaw

On 11/30/14, 12:31 AM, Asko Soukka wrote:
> Andreas Jung wrote:
>> or an external database. Content types can have multiple XML fields
>> with arbitrary field names and arbitrary storage strategies.
> An alternative approach is possible relying on supermodel, schemaeditor
> and z3c.form, but it would exclude behaviors and would not extend to
> direct attribute access:
>
> - supermodel can be extended with a feature, which tags XML schema
> fields with a marker interface
>
> - that feature could have a field-specific "use XML store"-flag in
> dexterity schemaeditor
>
> - custom z3c.form data managers could be implemented for that marker
> interface for reading and writing data into custom storage
>
> So, agreed, not as straightforward or complete as with Archetypes.
>
> Of course, you could just have a custom base class for your Dexterity
> types, which implements this feature in pythonic attribute acccess level
> (and it could still use TTW editable XML schema hints for mapping data
> to external storage).
>
Yes, Dexterity doesn't really have any built-in support for storage 
mechanisms other than attribute storage. I occasionally miss Archetypes' 
storage abstraction, but since this issue has come up infrequently in 
Dexterity's multiple years of existence, I don't feel too bad that it's 
missing from Dexterity. I agree a custom base class is probably the way 
to go since the standard Item/Container base classes don't help you with 
this.


------------------------------------------------------------------------------
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