plone.app.z3cform defines marker interfaces for date/datetime fields. I am assuming this is for making mockup widget lookup specificity easier? But what happens when an add-on wants to override one of the default (mockup/plone) widgets (see note below)?
IDateField and IDatetimeField interfaces are defined in:
plone.app.z3cform.interfaces (for Plone 5).
and
plone.app.z3cform.widget (for Plone 4 using plone.app.widgets 1.x).
These appear to be earlier in the specification resolution order in the component registry than zope.schema.interfaces.IDate and zope.schema.interfaces.IDatetime.
The implication of this that is not documented, but should be:
To override a widget defined in plone.app.z3cform/plone.app.widgets, one must declare IFieldWidget factory/adapters for plone.app.z3cform.interfaces.IDateField or plone.app.z3cform.interfaces.IDatetimeField, not merely zope.schema.interfaces.IDate or zope.schema.interfaces.IDatetime, and must also:
Ensure your add-on's browser layer interface subclasses z3c.form.interfaces.IFormLayer;
Ensure your widget factory/adapter declares that it adapts IDateField and your add-on's browser layer interface;
Both of the above conditions are sufficent to ensure that component lookup for your widget, on a site with your add-on installed, is more specific than the registration for the default widgets provided.
This peculiarity seems isolated to just these two field types (I am not sure why that is)?
I am happy to document this on docs.plone.org somewhere if anyone has suggestions on what page/section I should document this in?
A long time has passed since your post. However, do you have example code that you can share or a link to a repository which implements this? It would be helpful if posted here while it is not yet in the documentation.
It would be helpful to understand if the problem you are asking about concerns the binding of the widget on the server side or the customization of the widget's pattern in mockup/client-side.
In the case of the former, the example I have is very old code here — this example overrides the default widget where it is assumed that your add-on's layer interface is subclassing plone.app.widgets.interfaces.IWidgetsLayer. Given that I have not needed to do this nor tried this again in almost a decade, and have not tested this since Plone 5.0, YMMV.
Thank you for the clue and the example code. It helped me understand the reason why p.a.z3cform did not register a widget template. The adapter in p.a.z3cform used mockup to render the field widget.
Some explanations for Date(Time)Widget in plone.app.z3cform input/display mode:
latest version (respectively since version 4.4.0) uses extensible attributes feature from z3c.form==5.1. this means, that the widget sub-classes have the property attributes which compute the input fields attributes. For Datetime widget this means the type attribute is set in the subclasses here plone.app.z3cform/plone/app/z3cform/widgets/datetime.py at master · plone/plone.app.z3cform · GitHub and therefore it uses the text_input.pt template, which is enough.
There is NO mockup involved for the datetime input widget, because it uses the browser native datetime picker (see data-pat-datetime-picker option behavior: native in the markup).
When it comes to display, there is a boolean flag in the registry called Products.CMFPlone.i18nl10n.override_dateformat.Enabled which is False per default (plone.base/src/plone/base/i18nl10n.py at main · plone/plone.base · GitHub) , which means (to me), that the displayed value is generated with zope.i18n.format.DateTimeFormater... I could not dig deeper, but you could try to set this configuration flag to True and check if your displayed value is the one from the registry ...