zopefoundation / z3c.form

An advanced form and widget framework for Zope 3
Other
9 stars 39 forks source link

make form storage retrieval configurable #63

Open petri opened 7 years ago

petri commented 7 years ago

z3c.form uses adaptation for configurable data managers (IDataManager), to customize writing and reading data to/from the storage (whatever it may be).

However that is only half of what should be be there: we do not have same configurability for fetching the storage itself. Instead, the form getContent implementation is hardcoded to return the context object (using context in the normal Zope/Plone sense here).

This is fine in typical Zope/Plone cases when the editable (context) object attributes are used for storage. But already when storing form data in the context object annotations (with the z3c.form DictionaryField data manager), a custom form with overriden getContent (to return the annotation instead of context object) is required.

Furthermore, what if the form data storage is not the context object or some part of it? Perhaps there is a separate storage, such as one provided by Souper? Or, what if we want to use z3c.form to store data in a SQL database, Apache Kafka, or persist it over the network somewhere?

For such use cases, it would be useful if getContent used a multi-adapter (context, request) to fetch and return the "content (storage) object", (say, IFormStorageProvider), resorting to current behavior if no adapter is found.

I volunteer to provide a PR if this idea is accepted.

icemac commented 6 years ago

@petri The idea seems to be interesting but I am not sure if it will actually work as expected to get rid of overwriting getContent() in all cases: If you have a form for an object and another form for some of its annotations context would be the same and the adapter lookup has to be prevented for one of the forms by overwriting getContent() to not use the adapter.

Maybe it is easier discuss this on the actual code of the PR.