#9739: Admin does not correctly prefill DataTimeField from URL
     Reporter:  gilhad         |                    Owner:  Fabian Binz
         Type:  Bug            |                   Status:  assigned
    Component:  contrib.admin  |                  Version:  1.0
     Severity:  Normal         |               Resolution:
     Keywords:                 |             Triage Stage:  Accepted
    Has patch:  1              |      Needs documentation:  0
  Needs tests:  0              |  Patch needs improvement:  1
Easy pickings:  0              |                    UI/UX:  0
Comment (by Fabian Binz):

 I've looked at this ticket for quite some time during and after the recent
 sprint at the Cologne Django Meetup.

 For now, I've come to the conclusion, that - while there are definitely
 ways to build the functionality that's requested in the ticket - it's
 actually quite hard to do that in a manner that's general enough to cover
 all cases.

 What follows is a lengthy discussion of my current understanding of the
 problem, partly to just have a record of this for myself, but maybe we
 could also discuss a way forward:

 1. Handling of initial data for multi-value fields
 2. Parsing of localized datetime strings
 3. Deviation from the way HTML forms normally work

 The source of the "bug" is actually pretty simple: The
 SplitDateTimeWidget.decompress method expects its input to be a datetime
 object, which is not the case when the initial data is passed via a query
 parameter. According to the docs, this is a reasonable behavior, since the
 decompress method actually should only receive valid inputs (i.e. a
 datetime object). So, I guess it's not unreasonable to crash if passed a
 plain string.

 So, why is this contract violated in this case? Because the initial data
 specified via query parameters is passed verbatim - via a bunch of
 indirections - to the widget's decompress method, without any form of
 validation or parsing.

 Now, how could we actually parse or validate the input properly? In the
 case of a datetime field, I think we'd either have to settle on some
 standard way of formatting datetimes (datetime.isofromat seems reasonable
 as opposed to a comma- or space-separated representation discussed above)
 or we could take into account the DATETIME_FORMAT setting that the user
 has set. However, this doesn't really seem feasible.

 Fundamentally, I think the issue is that POST and GET data are not handled
 in a similar manner for MultiValueFields/MultiWidgets:
 Let's say we have a datetime field named "created_at". The
 SplitDateTimeWidget would render HTML similar to the following:

 <input name="created_at_0" ...>
 <input name="created_at_1" ...>

 Normally, we'd use query parameters like "created_at_0=2024-01-02" and
 "created_at_1=15:31:23" to pre-fill both the date and the time. For multi-
 value fields however, we expect that we can set both values using a single
 query parameter.
 When data is POSTed, we don't have that problem, since both inputs are
 simply separate values and can easily be passed to the
 MultiValueField.compress method.

 For my taste, having this difference between POST and GET does not make
 much sense and it would seem more consistent to just use the individual
 input names to pre-fill fields. This also enables partially pre-filling
 inputs, which is much harder when expecting to have a single
 representation of a value.

 But I also see the convenience of having a single URL parameter to set
 multiple fields. There are even test cases which kind-of test this
 behavior (though not for the SplitDateTimeWidget). So maybe an alternative
 would be to make the serialization/deserialization to/from string a part
 of the interface of the MultiValueField/MutliWidget classes, so that those
 methods can be used where needed.
Ticket URL: <https://code.djangoproject.com/ticket/9739#comment:29>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to