Ticket #9319 (closed PLIP: wontfix)

Opened 7 years ago

Last modified 7 years ago

Merging archetypes.fieldtraverser into Product.Archetypes

Reported by: thet Owned by:
Priority: minor Milestone: 4.0
Component: Archetypes Version:
Keywords: Archetypes, traverse Cc: plip-advisories@…

Description

Proposer: Johannes Raggam
Seconder: Jens Klein

Motivation

archetypes.fieldtraverser implements an mechanism to traverse to fields and access it's contents.

Use Cases:

  • Access to images, files or other binary data via AnnotationStorage instead of traditional AttributeStorage. archetypes.fieldtraverser eliminates the need to hack __bobo_traverse__ for this.
  • You can use archetypes.fieldtraverser for simple Web Services which return just the content of Archetypes fields without the HTML rendered by widgets.

In Product.Archetypes 2.0 there is an existing apporoach (see traverse.py, registered in configure.zcml) which must have been developed aproximately at the same time than archetypes.fieldtraver. But the implementation in archetypes.fieldtraver is more generic, because it allows to traverse to any archetypes field. Therefore the archetypes.fieldtraverser approach should be used.

Assumptions

The implementation of archetypes.fieldtraverser does not cover DataGrid or Lines-fields yet. But these cases can be implemented with moderate effort.

Proposal & Implementation

Usage:

In an URL this traverser can be used to access a fields data by use of the fieldname and the storage variant (if needed, such as image sizes):

obj/++atfield++FIELDNAME

or

obj/++atfield++FIELDNAME-STORAGENAME

Example:

To access an original image from a field named 'photo':

obj/++atfield++photo

To access its thumbnail with size named 'thumb':

obj/++atfield++photo-thumb

Deliverables

  • Integration into Product.Archetypes
  • Support for more field types like LinesField and DataGrid field
  • Testcases for these new field types

Risks

The current implementation patches Product.Archetypes, but there are some issues in context of the module loading order. ATContentTypes are loaded bevore archetypes.fieldtraverser can apply the patches because of the Zope/Five loading mechanism which loads modules in the Product.* namespace at the very beginning. This is documented in the README.txt file. But this is not an issue when archetypes.fieldtraverser would be merged into Product.Archetypes.

Participants

Johannes Raggam (thet) Jens Klein (jensens)

Progress

For an implementation see archetypes.fieldtraverser at:

 http://pypi.python.org/pypi?:action=search&term=archetypes.fieldtraverser

 http://svn.plone.org/svn/archetypes/archetypes.fieldtraverser/

Change History

comment:1 follow-up: ↓ 2 Changed 7 years ago by pupq

(It's not clear enough to me: the existing API for getFieldname() would still work, right? As long as that's the case, I don't see why the integrators wouldn't like this.)

comment:2 in reply to: ↑ 1 Changed 7 years ago by thet

Replying to pupq:

(It's not clear enough to me: the existing API for getFieldname() would still work, right? As long as that's the case, I don't see why the integrators wouldn't like this.)

yes, the existing API still works.

comment:3 Changed 7 years ago by erikrose

  • Owner nouri deleted

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:4 Changed 7 years ago by alecm

Would this involve getting rid of the existing traversal behavior (e.g. directly accessing 'image_thumb')? This would seem to be a pretty huge break in backwards compatibility. I don't fully understand the motivation for this PLIP. Do we really need another way to access AT field data? I understand that it might be useful for developing external semi-RESTful web-services using AT, but I'm not sure that is enough to make it directly valuable for the core.

comment:5 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:6 Changed 7 years ago by MatthewWilkes

I'm unconvinced by the necessity to this. Accessors already work and are a generic way of getting AT data.

FWT Vote: -1

comment:7 Changed 7 years ago by rossp

FWT vote: +1. I think this is the kind of API feature that will find great uses once widely available and is very appropriate for a major release. I've often wished for such a feature. Also, field permissions would have to be obeyed by the traverser. Finally, who is the implementor?

comment:8 follow-up: ↓ 13 Changed 7 years ago by davisagli

FWT vote: -1. I don't see a use for this within Plone itself. (Traversal to image scales has already been rewritten to use a custom IPublishTraverse adapter instead of bobo_traverse.)

This would be a win for accessing the value of schema-extender fields -- context/++atfield++myfield instead of python:context.getField('myfield').getAccessor(context)() ...but we don't ship with archetypes.schemaextender.

comment:9 Changed 7 years ago by calvinhp

FWT Vote: -1 for the same reasons as davisagli

comment:10 Changed 7 years ago by raphael

I'm not sure everybody understands the motivation behind this PLIP. At least as I understand it the development of archetypes.fieldtraverser has been initiated by the fact that our current machinery does NOT work for binary data when using AnnotationStorage (AS). AS on the other hand has several advantages over todays default (AttributeStorage) like better performance, lower risk of name clashes, possibility to turn fields into properties (in the Python sense) etc.

At least for those reasons I'm using archetypes.fieldtraverser today already myself.

The fact that archetypes.fieldtraverser also adds an expanded convenience API might come in handy but I'd consider that secondary.

Now, this could continue as an add-on but (1) it has to monkey patch Archetypes quite a bit and that should be avoided (2) it would let us move to AnnotationStorage as default storage for all field types - and don't tell me Archetypes is going to die any time soon ;-) It's used so much in the wild that it will continue even after Plone itself moved away from it if only through all those add-ons that will then pull it in as a dependency.

Therefore, I'm +1 on this PLIP.

comment:11 Changed 7 years ago by alecm

I don't understand what the specific issues are with AnnotationStorage and binary objects? If there is such an issue, a bug should be filed and this can be resolved without a PLIP or any new APIs. There are some major disadvantages to using AnnotationStorage, particularly for attributes which are likely to be used for all views of the content.

If there are reasons beyond the new traversal API for including these changes, the PLIP needs to be clearer about those.

comment:12 Changed 7 years ago by erikrose

The FWT is curious whether the implementation in Archetypes itself could be fixed to be more generic, rather than adding our own reimplementation. Could the PLIP author go into more depth comparing fieldtraverser and Archetypes' implementation and comment on the feasibility of improving the Archetypes version?

comment:13 in reply to: ↑ 8 Changed 7 years ago by witsch

Replying to davisagli:

This would be a win for accessing the value of schema-extender fields -- context/++atfield++myfield instead of python:context.getField('myfield').getAccessor(context)() ...but we don't ship with archetypes.schemaextender.

just as a note: plone.app.blob currently requires archetypes.schemaextender, so unless it sees a major rewrite (and if the blob plip is accepted, of course), we might end up shipping with it. please see my comment over in #7822 for the motivation behind this...

comment:14 Changed 7 years ago by esteele

  • Status changed from new to closed
  • Resolution set to wontfix

Rejected for Plone 4.0 by FWT vote.

Note: See TracTickets for help on using tickets.