You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
petri
changed the title
add configurable form storage
make form storage configurable
Jul 11, 2017
petri
changed the title
make form storage configurable
make form storage retrieval configurable
Jul 12, 2017
@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.
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.
The text was updated successfully, but these errors were encountered: