Ticket #13450 (closed PLIP: wontfix)
Better and single! datetime widget
Reported by: | tom_gross | Owned by: | vangheem |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | User Experience and Interface | Version: | |
Keywords: | Cc: |
Description (last modified by tom_gross) (diff)
Picking dates and times is an important task in CMSes. Plone has a very stable but hard to use date widget with a JavaScript helper a couple of years old. Lately there was made some approaches to improve this situation. There is plone.app.widgets and plone.formwidget.datetime. This reminds me on the situation we have with content selection in Plone. There are several solutions but none of them is really optimal. The problem of different content finder strategies is tackled by the new contentfinder initiative. This PLIP tries the same for date and datetime selectors.
I propose to implement a widget for Archetypes and z3.form base on the HTML5 date-input field with a JavaScript fallback.
Pros:
- A fairly small & simple approach
- A coherent UI
- A widget which is/will be optimized for different devices
- Remove 1.2 MB of ancient 3rd party code with PHP traces
- No extra product
Cons
- The HTML5 widget is not stylable
I have a prototype working with jQuery UI datepicker as a fallback. I don't care too much which fallback we are using. There are a lot of options around.
Risks: The risk of changing a widget is low. Tests and careful input validation are needed. On browsers which do not support the HTML5 widget the input is a stanard text input field. We need to make sure only valid dates are processed. If this is needed the current datetime picker can be bundled to a seperate product (like collective.searchform).
Implementation: There is a prototype for Archetypes ready at https://gist.github.com/tomgross/4956024. It has to be included in Plone and a z3c.form variant is still TBD.
Change History
comment:1 Changed 3 years ago by tom_gross
- Owner set to vangheem
- Component changed from Unknown to User Experience and Interface
- Version 4.3 deleted
- Type changed from Bug to PLIP
- Milestone changed from 4.x to 4.4
comment:4 Changed 3 years ago by vangheem
Great! garbas has done work on integrating the bootstrap datetime widget with plone in plone.app.widgets. Any additional widget improvements should be done it the plone.app.widgets package.
What are your thoughts of the new datetime widget in plone.app.widgets? http://status.plone.org/mockup/widgets.html
comment:5 Changed 3 years ago by tom_gross
This PLIP serves three goals:
- simplify the existing AT datetime picker widget
- provide ONE datepicker for all datepicking purposes in Plone
- use the existing structure and don't introduce new packages
The widgets of plone.app.widgets look great but especially for the datepicker I think using the HTML5 datepicker rather than a triple selection is better in terms of simplicity and multi device support. I'm -1 in introducing a new package for Archetype widgets. For Dexterity this is OK I guess but for AT there almost every addon will break (or simply not use the new widgets) with the at.schemaextender method plone.app.widgets uses. IMO AT widget improving should only be done in Archetypes/Widget.py to have a coherent UI among a Plone site. What could be a reason to have the widgets in a separate package?
comment:6 follow-up: ↓ 7 Changed 3 years ago by vangheem
The main purpose of plone.app.widgets to provide updated widgets that work with toolbar. It was an easy way to provide updated widgets for users to test. Maybe the end goal can be to move it back into Archetypes but it didn't seem like a good idea to put experimental widgets into archetypes that also required newer versions of jquery, resourceregistries, etc.
Why would every addon break from using plone.app.widgets though? I can't think of any reasons why.
Let's just ignore plone.app.widgets right now then. Your plip addresses an immediate issue and will work nicely with the existing UI.
comment:7 in reply to: ↑ 6 Changed 3 years ago by tom_gross
Replying to vangheem:
The main purpose of plone.app.widgets to provide updated widgets that work with toolbar. It was an easy way to provide updated widgets for users to test.
We have widgets in Products.Archetypes, in plone.app.form.widgets, in z3c.form and in several other places. I like the widgets currently in plone.app.widgets and I like the approach but I really don't see the need for yet another package
Why would every addon break from using plone.app.widgets though? I can't think of any reasons why.
Break is not really correct. Not picked up is the term I'd use here. As I understand the technique of plone.app.widgets it uses archetypes.schemaextender to override widgets. Fields/Widgets which are not explicitly defined there (as found in 3rd party products using from Products.Archetyps.Widgets import *')' will not picked up.
Let's just ignore plone.app.widgets right now then. Your plip addresses an immediate issue and will work nicely with the existing UI.
+1 I see this PLIP as a "quick win" which could (and should IMHO) be picked up by plone.app.widgets or whatever the new place for widgets is.
comment:8 Changed 3 years ago by vangheem
A little off topic, but do you have an opinion on where widgets should be located? Thinking about it more, the idea of plone.app.widgets is that it would have widgets for all the form libraries and would share the same js or perhaps other logic since all widgets should behave the same across libraries.
Hopefully it'd then also prevent people from creating those one-off widget packages. Maybe it doesn't happen as much for archetypes but our z3cform widgets are all over the place...
comment:9 Changed 3 years ago by vangheem
Does this need a PLIP anyways. Widget improvements should be natural improvements of the product and should not always require a PLIP unless there are large-scale changes.
Additionally, a plone.app.widgets plip has been submitted for plone 4.4.
comment:10 Changed 3 years ago by tom_gross
- Status changed from confirmed to closed
- Resolution set to wontfix
I guess the effort should go into plone.app.widgets. And Archetypes should use these widgets per default. I retract this PLIP.