calendar.js depends on jsi18n but date widgets using it do not specify as required media

[tblanchard@…]

Its nice that we can just use the admin widgets in our own public forms - except trying to include the split date/time widget results in a need for gettext which is in the jsi18n package which requires a separate urlconf entry and view to pull into my app. This is messy. Dependent code should automatically pull in its dependencies.

[Ramiro Morales]

IMHO being able to reuse admin widgets in out own apps isn't parr of the design objectives of thes widgets. I think being able to achieve that should be possible but the developer needs to perform all the steps needed for the integration, just like with any other front end component. I particularly don't like at all having to devise a way to magically add a view like the one serving the jsi18n catalog to the URL map of the third party app.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Adam Zapletal]

It looks like this is still valid. Supporting this idea doesn't seem very straightforward given the dynamic nature of django/views/templates/i18n_catalog.js. I agree with the comment above that it's ok if a user wanting to use admin-specific widgets that aren't designed to be used outside of the admin may have to do a bit of extra integration work.

If a user wants to use the widgets without internationalization, they should be able to define simple JavaScript stubs for gettext, pgettext, and get_format to get things working. If they want to use internationalization, I feel like having to do the same kind of integration that the admin does is acceptable.

Considering the above, does this bit of the docs on form media seem misleading? ​https://github.com/django/django/blob/73df8b54a2fab53bec4c7573cda5ad8c869c2fd8/docs/topics/forms/media.txt#L21-L32

[Natalia Bidart]

Tom, Claude, would you have further insights for the comment:5 above?

[Tom Carrick]

I agree completely. In my mind, the admin widgets aren't really that suitable for use in user code. If people want to use them, fine, but I think it should be at their own risk and we shouldn't add any extra maintenance burden in supporting this.

With this piece of documentation, I feel like it's suggesting that any visible change we make to a widget could be backwards incompatible and I don't think we want that, at least I personally would like the freedom to change the admin widgets between releases to make improvements without worrying too much that they might affect someone's site otherwise.

I think we should discourage this by at a minimum removing this paragraph and closing this ticket.

Just my opinion, anyway :)

[Adam Zapletal]

Thanks for the activity here! I'm happy to open a pull request when a consensus is reached.