plone.app.caching caches the form view too strong when modifying descriptions

[prakharjoshi]

When I use collective.easyform in a site in production mode with plone.app.caching enabled and I change the description of a field, the browser will upon requesting the form's /view receive a 304 not modified. Changing the title of a field does force a new reload.

[agitator]

I'd say this is a configuration issue of p.a.caching

[fredvd]

I see the same behavior and I don't think this a problem with plone.app.caching per sé. Easyform has to register hooks to activate cachepurging for the urls' on which the form can be viewed when its contents is modified.

The image and file content type for example also purges several @@images/image /@@Download etc urls when the file field is modified. This is different from the default / and /view pages which are by default registered as purge urls by zope and Plone DX.

I've done a quick search through collective.easyform and I see nothing of these registrations for easyform. Furthermore the field editor is not on the default @@edit view so any changes there will not necessarily be picked up automatically like with other /edit views

[mauritsvanrees]

The real problem is that the catalog counter is not updated, so the catalogCounter ETag stays the same, so any caching that relies on this ETag (pretty standard) will conclude that there are no changes, and give a 304 not modified.
My PR #243 fixes it.