Ticket #13450 (closed PLIP: wontfix)

Opened 3 years ago

Last modified 2 years ago

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:2 Changed 3 years ago by tom_gross

  • Description modified (diff)

comment:3 Changed 3 years ago by kleist

  • Status changed from new to confirmed

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:

  1. simplify the existing AT datetime picker widget
  2. provide ONE datepicker for all datepicking purposes in Plone
  3. 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.

comment:11 Changed 2 years ago by davisagli

  • Milestone changed from 4.4 to 5.0

Milestone 4.4 deleted

Note: See TracTickets for help on using tickets.