Applying a filter on a DateTime column in an aggregation was causing
an uncaught error to occur and prevent the page being rendered at
all. Fortunately, this turned out to be a very simple issue to resolve.
The datetime picker expects and produces dates / time pairs separated by
the "T" character, not a space. Further, it does not handle seconds at
all.
Therefore, we have to provide the timestamp in the input field separated
by a "T" and for consistency drop seconds altogether. Hence, it
becomes necessary to replace the "T" by a space again before providing it to jQuery
date picker fallback.
Further, we have to actually parse the "T" when validating the
timestamps we receive from the user.
Multiple inputs within a single label in invalid HTML. This bug can not
only occur in multi-fields but also in plugin-provided single fields
which may contain multiple input-fields which are then only combined by
javascript.
Thus, we provide an id which every type can assign to the edit-field
best suited. For multi-types this is usually the new-input-template.
Fixes#292
The filters coming from syntax should be grouped together in a subgroup
to that OR-filters cannot undo the filters on latest=1 etc.
Since we cannot know in the filter function whether there is already a
subgroup for us to use or which to use, the solution was to give the
correct subgroup to the filter function directly.
Instead of adding another parameter to the already long list of
parameters for that function, I have chosen to give the
QueryBuilderWhere a reference back to the original QueryBuilder.
With this the correct class will be set in all the scenarios (page-edit,
inline, lookup). Then changing the date via the datepicker will always
generate time-template as defined in script/EntryEditor.js
Fixes#204
This is another attempt to fix#140. The valueEditor() and
multiValueEditor() now always expect raw values to be passed. The Value
class was adjusted accordingly. It now allows to set the raw value
(which is what we get from POST). If done, the Value object is treated
as a rawonly Value that will throw an exception when you try to access
value or displayvalue.
We're not using strftime in our Date and DateTime types because we want
to be able to represent dates outside the unix timestamp range.
To reuse the strftime format string we have in DokuWiki it needs to be
converted to a date() compatible format. The class added for that could
ultimately be moved to a third party project.
