The Dexterity storage layer story is a flaw

classic Classic list List threaded Threaded
3 messages Options
ajung ajung
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Asko Soukka Asko Soukka
Reply | Threaded
Open this post in threaded view
|

Re: The Dexterity storage layer story is a flaw

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

Regards,
Asko

------------------------------------------------------------------------------
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
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
David Glick (Plone) David Glick (Plone)
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers