Pull to refresh

Comments 16

Интересно, мне всегда казалось, что в PHP для локализации стандартом де-факто является расширение intl, надо заметить, что оно сильно упрощает вывод дат. В Symfony, например, эта проблема решается в расширении к шаблонизатору, которое зависит от intl.
Плюс, мне кажется, что всё-таки форматирование данных находится за пределами ответственности модели, т.е. метод getCreatedAtAttribute излишен, а код, в нем реализованный, попадает в зону ответственности вьюхи.
И кстати, зачем суффикс ...Attribute в геттере? Разве не любое значение, возвращаемое геттером, будет являться атрибутом объекта?
А, ясно, это Ларавеловские штуки то есть. Спасибо за ссылку, теперь понятно.
К примеру, многие пишут приложение в связке с AngularJS (либо другие frontend-фреймворки), то контроллер отдает данные в json-формате.
Если во всех контроллерах циклически обрабатывать модели, где нужно преобразовать даты — получится большое скопление дублирующегося кода.
А в проектах на подобии блог/информационный портал/соц. сеть и т.д. — таких мест будет очень много.
Ну, на мой взгляд это и не ответственность контроллера. В стеке должен быть выделен шаг сериализации, который на входе получает модель, а на выходе у него JSON, в котором даты трансформируются так, как вам удобно.
Если у вас более сложный случай, когда данные модели приходят в одном представлении, а отображаться должны в другом — вы можете всегда возвращать таймштампы в едином формате, а на клиенте использовать Moment.js или аналог. Правда, в этом случае локализация тоже переедет на клиент, но на мой взгляд это скорее плюс — работать будет быстрее.
Откройте для себя jms/serializer
Сам частенько реализовывал такие вещи серверно, но сейчас практически уверен, что локализация даты — задача клиента.
Особенно сейчас, когда есть семантичный и удобный тег <time>.
Даже простенькую библиотечку для этого написал — https://github.com/maximal/time.js/.
Есть ещё всякие штуки потяжелее: moment.js, например.
Не задумывался над этим ранее… Действительно, лучше формат даты делать на стороне клиента (тем более можно подхватить часовой пояс и корректировать время от его значения). Круто, нужно будет попробовать. Только нужно сделать генерацию json-файла с необходимыми переводами на различные языки.
Это как раз то, чего давно не хватает, и что давно просят добавить, в моей библиотечке localized-carbon. Сейчас она только умеет локализовывать разницу во времени, типо «3 часа назад», «5 лет назад» и т.д.
это умеет оригинальный carbon
Тогда было бы великолепно на github в описании к пакету написать его применимость относительно текущего положения дел в самом carbon.
Спасибо, хорошее решение, только пару нареканий по стилю.
Для работы с датой стоит использовать имеющуюся библиотеку Carbon и не стоит вешать это на get*Attribute чтобы не сломать поведение в других местах. Это логика отображение и её нужно делать во вьюхе или навешивать через Decorator-Presenter.
Спасибо за полезный комментарий!
Only those users with full accounts are able to leave comments. Log in, please.