Comments 16
Интересно, мне всегда казалось, что в PHP для локализации стандартом де-факто является расширение intl, надо заметить, что оно сильно упрощает вывод дат. В Symfony, например, эта проблема решается в расширении к шаблонизатору, которое зависит от intl.
Плюс, мне кажется, что всё-таки форматирование данных находится за пределами ответственности модели, т.е. метод
Плюс, мне кажется, что всё-таки форматирование данных находится за пределами ответственности модели, т.е. метод
getCreatedAtAttribute излишен, а код, в нем реализованный, попадает в зону ответственности вьюхи. И кстати, зачем суффикс ...Attribute в геттере? Разве не любое значение, возвращаемое геттером, будет являться атрибутом объекта?
Если заглянуть во внутренности Laravel, то можно увидеть, что модель Illuminate\Database\Eloquent\Model ищет метод «getНашАтрибутAttribute».
Подробнее: github.com/laravel/framework/blob/4.2/src/Illuminate/Database/Eloquent/Model.php#L2499
Подробнее: github.com/laravel/framework/blob/4.2/src/Illuminate/Database/Eloquent/Model.php#L2499
К примеру, многие пишут приложение в связке с AngularJS (либо другие frontend-фреймворки), то контроллер отдает данные в json-формате.
Если во всех контроллерах циклически обрабатывать модели, где нужно преобразовать даты — получится большое скопление дублирующегося кода.
А в проектах на подобии блог/информационный портал/соц. сеть и т.д. — таких мест будет очень много.
Если во всех контроллерах циклически обрабатывать модели, где нужно преобразовать даты — получится большое скопление дублирующегося кода.
А в проектах на подобии блог/информационный портал/соц. сеть и т.д. — таких мест будет очень много.
Ну, на мой взгляд это и не ответственность контроллера. В стеке должен быть выделен шаг сериализации, который на входе получает модель, а на выходе у него JSON, в котором даты трансформируются так, как вам удобно.
Если у вас более сложный случай, когда данные модели приходят в одном представлении, а отображаться должны в другом — вы можете всегда возвращать таймштампы в едином формате, а на клиенте использовать Moment.js или аналог. Правда, в этом случае локализация тоже переедет на клиент, но на мой взгляд это скорее плюс — работать будет быстрее.
Если у вас более сложный случай, когда данные модели приходят в одном представлении, а отображаться должны в другом — вы можете всегда возвращать таймштампы в едином формате, а на клиенте использовать Moment.js или аналог. Правда, в этом случае локализация тоже переедет на клиент, но на мой взгляд это скорее плюс — работать будет быстрее.
Откройте для себя jms/serializer
Сам частенько реализовывал такие вещи серверно, но сейчас практически уверен, что локализация даты — задача клиента.
Особенно сейчас, когда есть семантичный и удобный тег
Даже простенькую библиотечку для этого написал — https://github.com/maximal/time.js/.
Есть ещё всякие штуки потяжелее: moment.js, например.
Особенно сейчас, когда есть семантичный и удобный тег
<time>.Даже простенькую библиотечку для этого написал — https://github.com/maximal/time.js/.
Есть ещё всякие штуки потяжелее: moment.js, например.
Это как раз то, чего давно не хватает, и что давно просят добавить, в моей библиотечке localized-carbon. Сейчас она только умеет локализовывать разницу во времени, типо «3 часа назад», «5 лет назад» и т.д.
Спасибо, хорошее решение, только пару нареканий по стилю.
Для работы с датой стоит использовать имеющуюся библиотеку Carbon и не стоит вешать это на get*Attribute чтобы не сломать поведение в других местах. Это логика отображение и её нужно делать во вьюхе или навешивать через Decorator-Presenter.
Для работы с датой стоит использовать имеющуюся библиотеку Carbon и не стоит вешать это на get*Attribute чтобы не сломать поведение в других местах. Это логика отображение и её нужно делать во вьюхе или навешивать через Decorator-Presenter.
Sign up to leave a comment.
Локализованное форматирование даты в Laravel