HP-2387: refactor DateTimePicker #187
Conversation
WalkthroughThis change updates multiple DateTimePicker widget configurations across various views. The modifications adjust option keys and values—switching from Changes
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/views/order/_search.php (2)
58-58: Consider accessibility implications of using only placeholders without labels.While adding a placeholder for "Time" improves user experience, relying solely on placeholders without explicit labels can reduce accessibility for screen readers and other assistive technologies. Placeholders disappear when users start typing, which may also impact usability for all users.
Consider maintaining both the label and placeholder for maximum accessibility:
<div class="form-group"> + <label for="time-range"><?= Yii::t('hipanel', 'Time') ?></label> <?= DateRangePicker::widget([ 'model' => $search->model, 'attribute' => 'time_from', 'attribute2' => 'time_till', 'options' => [ 'class' => 'form-control', + 'id' => 'time-range', 'placeholder' => Yii::t('hipanel', 'Time'), ], 'dateFormat' => 'yyyy-mm-dd', ]) ?> </div>
74-74: Consider accessibility implications of using only placeholders without labels.Similar to the "Time" field above, using only placeholders without explicit labels for the "Profit period" field may reduce accessibility. Additionally, ensure the translation category 'hipanel:stock' is consistent with other translations in the stock module.
Consider maintaining both the label and placeholder:
<div class="form-group"> + <label for="profit-period-range"><?= Yii::t('hipanel:stock', 'Profit period') ?></label> <?= DateRangePicker::widget([ 'model' => $search->model, 'attribute' => 'profit_time_from', 'attribute2' => 'profit_time_till', 'options' => [ 'class' => 'form-control', + 'id' => 'profit-period-range', 'placeholder' => Yii::t('hipanel:stock', 'Profit period'), ], 'dateFormat' => 'yyyy-mm-dd', ]) ?> </div>
| 'dateFormat' => 'yyyy-mm-dd', | ||
| ]) ?> |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify DateRangePicker configuration consistency.
The dateFormat setting appears to be aligned with the DateTimePicker widget changes mentioned in the PR summary. Ensure that this format is consistent with other date-related widgets across the application and that it meets the requirements for displaying and parsing dates correctly.
Also applies to: 76-77
🏁 Script executed:
#!/bin/bash
# Search for other DateRangePicker/DateTimePicker usages to verify consistency
echo "Checking DateRangePicker/DateTimePicker usage patterns across the codebase:"
rg --type php "DateRangePicker::widget\(\[|DateTimePicker::widget\(\[" -A 10 -B 2 | grep -E "dateFormat|format"Length of output: 698
Action: Resolve Date/Time Format Inconsistency
It appears there’s an inconsistency in how date formats are defined across similar widgets:
- In src/views/move/_search.php, the widget uses
'dateFormat' => 'yyyy-MM-dd'(note the capital "MM"). - In src/views/order/_search.php (lines 60–61), the new change sets
'dateFormat' => 'yyyy-mm-dd'(with lowercase "mm"). - In src/views/part/_search.php, both variations appear—with one instance using the key
'format'and others using'dateFormat', mixing formats.
Please verify whether the intended standard is to use the uppercase "MM" (commonly used for months) or the lowercase "mm". Then, update all date-related widget configurations to use a consistent format that aligns with both display and parsing requirements.
Summary by CodeRabbit
New Features
Tests