Comments 9
Не ожидал такого от «шаблонизатора», круто
Когда использовал mason, то поленился внимательно изучить доку(
В итоге сделал так: есть один корневой компонент, в нем реализованы шапка и подвал. В середине, на основе переданных в <%args> данных, вычилялся и инклудился компонент с содержимым. Теперь понимаю, что стоило воспользоваться autohandler'ами.
В итоге сделал так: есть один корневой компонент, в нем реализованы шапка и подвал. В середине, на основе переданных в <%args> данных, вычилялся и инклудился компонент с содержимым. Теперь понимаю, что стоило воспользоваться autohandler'ами.
Вопрос к автору: а приходилось вам реализовать локализацию (не мультиязычность) сайта средствами mason? Если да, не опишите ли общий подход?
Приходилось, но результат не понравился.
Первый вариант локализации видел в Request Tracker. Детали не помню, кажется реализовано через фильтры. Лучше посмотрите сами.
Второй вариант пришел в голову кому-то из нашей команды, и были созданы ресурсные файлы с хешами, где ключами были упрощенные до предела английские фразы, а значения — локализованный контент. Разработка сильно замедлилась (словарь рос на глазах, ключи никто не помнил), быстродействие тоже не блистало.
Третий вариант — максимально разделить логику от локализованных шаблонов и попытаться выехать на переплетении файлов с «чисто локализованными текстами» и «логики без признаков текстов». Например, можно завести отдельные папки для разных языков и общую с логикой, и расплодить масоновские обработчики, чтобы каждый из них искал файлы сначала в локализованной папке (в «своем» языке), а потом в общей. Если будет алгоритм выбора нужного обработчика (скажем, по куке), схема будет работать. Но разделить логику и тексты красиво получается далеко не всегда. Если у Вас это получится — можно попробовать. У меня не получилось.
А вообще я бы с удовольствием прочитал про более удачный опыт локализации.
Первый вариант локализации видел в Request Tracker. Детали не помню, кажется реализовано через фильтры. Лучше посмотрите сами.
Второй вариант пришел в голову кому-то из нашей команды, и были созданы ресурсные файлы с хешами, где ключами были упрощенные до предела английские фразы, а значения — локализованный контент. Разработка сильно замедлилась (словарь рос на глазах, ключи никто не помнил), быстродействие тоже не блистало.
Третий вариант — максимально разделить логику от локализованных шаблонов и попытаться выехать на переплетении файлов с «чисто локализованными текстами» и «логики без признаков текстов». Например, можно завести отдельные папки для разных языков и общую с логикой, и расплодить масоновские обработчики, чтобы каждый из них искал файлы сначала в локализованной папке (в «своем» языке), а потом в общей. Если будет алгоритм выбора нужного обработчика (скажем, по куке), схема будет работать. Но разделить логику и тексты красиво получается далеко не всегда. Если у Вас это получится — можно попробовать. У меня не получилось.
А вообще я бы с удовольствием прочитал про более удачный опыт локализации.
Спасибо, сильно не сталкивался с Mason'ом, но все же приятно видеть добряка Perl'а…
Хотя визуально сейчас, субъективно замечу, что всё это выглядит неуклюже в сравнении с шаблонами RoR'а :)
Хотя визуально сейчас, субъективно замечу, что всё это выглядит неуклюже в сравнении с шаблонами RoR'а :)
Sign up to leave a comment.
Применение наследования в шаблонах Mason