Comments 21
UFO just landed and posted this here
Имхо не стоит переносить такие задачи в шаблон
Изложенное выше — это моё имхо.
На уже упомянутом примере с датами пример из практики: в разных местах форума дата публикации сообщения выводится в разном формате: в списке сегодняшних сообщений — только время, а в топике — полная дата.
Я думаю, что это несколько нелогично, нагружать PHP код дополнительными преобразованиями под конкретные случаи. Поэтому это и решается на месте вывода. Нужна дата? Пожалуйста! Время? Ноу проблем! И то и другое? Всегда рады помочь!
Кое где доводилось дописывать и дополнительные short_date_format, но это уже частности…
На уже упомянутом примере с датами пример из практики: в разных местах форума дата публикации сообщения выводится в разном формате: в списке сегодняшних сообщений — только время, а в топике — полная дата.
Я думаю, что это несколько нелогично, нагружать PHP код дополнительными преобразованиями под конкретные случаи. Поэтому это и решается на месте вывода. Нужна дата? Пожалуйста! Время? Ноу проблем! И то и другое? Всегда рады помочь!
Кое где доводилось дописывать и дополнительные short_date_format, но это уже частности…
Хм. А куда ещё-то?
UFO just landed and posted this here
Может стоит выложить эти файлы где-нибудь отдельно, архивом. Просто хабр своим типографированием портит «кавычки», пользователям будет не очень удобно копировать/вставлять код.
Или как вариант — заменить на одинарные. А так — решение вполне забавное, хотя я уже давно не работаю со smarty.
Или как вариант — заменить на одинарные. А так — решение вполне забавное, хотя я уже давно не работаю со smarty.
Вот modifier.date.php и modifier.date_sql.php.
Сорри, но обновить статью почему-то не хватает кармы, хотя для переноса её хватило. Что-то я, видимо, не понимаю.
Сорри, но обновить статью почему-то не хватает кармы, хотя для переноса её хватило. Что-то я, видимо, не понимаю.
Мне в свое время очень не хватало модификатора substring
Чтобы отредактировать статью дополнительной кармы ненадо. Нажмите кнопочку рядом с названием статьи (у вас как у автора должна появиться).
По теме. Считаю неправильным вообще сам факт существования модификатора SQL_DATE, представление не должно знать откуда оно получает данные — сразу из базы, из формы или результат вычислений. Задача представления отобразить и все. А возвращать значение представлению должен контроллер. Просто возможно та дата, которая сегодня поступает из базы завтра будет вычисляться, придется лазить по всем шаблонам и менять модификатор?
По теме. Считаю неправильным вообще сам факт существования модификатора SQL_DATE, представление не должно знать откуда оно получает данные — сразу из базы, из формы или результат вычислений. Задача представления отобразить и все. А возвращать значение представлению должен контроллер. Просто возможно та дата, которая сегодня поступает из базы завтра будет вычисляться, придется лазить по всем шаблонам и менять модификатор?
«Чтобы отредактировать статью дополнительной кармы ненадо. Нажмите кнопочку рядом с названием статьи (у вас как у автора должна появиться).»
Вроде бы так и делал, а мне писало, что не хватает кармы. Сейчас получилось, хотя значение кармы не поменялось. Спишем это на мою неопытность в хаброписательстве :)
Ближе к теме: по поводу date_sql я уже выказался в статье и полностью согласен с тем, что должен быть один модификатор для даты. У меня же по историческим причинам получилось 2.
Вроде бы так и делал, а мне писало, что не хватает кармы. Сейчас получилось, хотя значение кармы не поменялось. Спишем это на мою неопытность в хаброписательстве :)
Ближе к теме: по поводу date_sql я уже выказался в статье и полностью согласен с тем, что должен быть один модификатор для даты. У меня же по историческим причинам получилось 2.
Ой, промахнулся :)
Это был ответ для beq
Это был ответ для beq
С почином :)
Тема про обмен опыта по Smarty отличная, целиком и полностью поддерживаю, как морально, так и материально.
А вот насчёт плагинов с датой — разрешите покритиковать. Получается, что Вы должны изначально знать тип даты, на которую кастуете фильтр. Это не совсем правильно, по-моему. Гораздо лучше было бы, если бы плагин был всего один и сам определял тип даты и, в случае необходимости, переводил YYYY-MM-DD в UNIX_TIMESTAMP через strtotime.
Тема про обмен опыта по Smarty отличная, целиком и полностью поддерживаю, как морально, так и материально.
А вот насчёт плагинов с датой — разрешите покритиковать. Получается, что Вы должны изначально знать тип даты, на которую кастуете фильтр. Это не совсем правильно, по-моему. Гораздо лучше было бы, если бы плагин был всего один и сам определял тип даты и, в случае необходимости, переводил YYYY-MM-DD в UNIX_TIMESTAMP через strtotime.
Я бы посоветовал заменить регулярки одной функциие strtotime(), функционала сразу прибавиться и скорости тоже ;)
Я долго думал, зачем же я использовал strtr() вместо strtotime(). Вспомнил даже свою боязнь отрицательных timestamp'ов…
На самом деле, это для несколько специфичного случая дат рождения. Во многих создаваемых сайтах ввод даты рождения был необязательным, и даже более того, можно вводить дату рождения частично: т.е. могу указать свой день рождения без года (чтобы все меня поздравляли, но никто не знал сколько мне лет), или же просто год (мой возраст известен, а вот дата рождения — нет). Поэитому даты рождения вида «1980-00-00» или «0000-01-19» лучше обрабатывать вручную. strtotime() тут бессилен.
На самом деле, это для несколько специфичного случая дат рождения. Во многих создаваемых сайтах ввод даты рождения был необязательным, и даже более того, можно вводить дату рождения частично: т.е. могу указать свой день рождения без года (чтобы все меня поздравляли, но никто не знал сколько мне лет), или же просто год (мой возраст известен, а вот дата рождения — нет). Поэитому даты рождения вида «1980-00-00» или «0000-01-19» лучше обрабатывать вручную. strtotime() тут бессилен.
После второго совета на эту тему решил попробовать преодолеть свои детские комплексы по поводу отрицательных unix_timestamp'ов; лени и осторожности в объединении вышеописанных плагинов.
Резульатат — обновлённая версия плагина была добавлена в статью.
Резульатат — обновлённая версия плагина была добавлена в статью.
Сейчас обнаружил интересный блог — habrahabr.ru/blogs/smarty/
Он пока пустой, т.к. все статьи по Smarty выкладывают в блог PHP. Может стоит их перенести в отдельный блог? Думаю это избавит от холиваров, ведь там будет в основном заинтересованная публика.
P.S. Сам давненько использую Smarty, есть ряд своих наработок, готов поделится ими с сообществом.
Он пока пустой, т.к. все статьи по Smarty выкладывают в блог PHP. Может стоит их перенести в отдельный блог? Думаю это избавит от холиваров, ведь там будет в основном заинтересованная публика.
P.S. Сам давненько использую Smarty, есть ряд своих наработок, готов поделится ими с сообществом.
Перенёс.
Вообще не помешало бы что-нибудь типа smarty russian community :) Как бы только это лучше оформить? Форумом, что ли. Вот, например, проблемка: в схеме colorer (far, mc) для smarty — баги. И в одиночку их править — скучно :) github.com/colorer/Colorer-schemes/issues/75
Sign up to leave a comment.
Мои плагины для Smarty