Стратегия переноса Perl CGI на Template Toolkit?

У меня есть относительно большое наследие Perl/CGI/DBI веб-приложение, которое генерирует HTML-код "на лету" по частям. Мы перерабатываем созданный HTML, чтобы соответствовать требованиям HTML 5/CSS 3. Это было бы подходящее время для перехода к какой-либо системе шаблонов. Мы НЕ хотим участвовать в полной перезаписи и, следовательно, НЕ хотим мигрировать в инфраструктуру, такую как Catalyst.

Я думаю, что Perl Template Toolkit может быть нашим самым низким эффектом. Я перечитываю почтенную книгу Бадджера, чтобы изучить возможность.

Мой вопрос в том, что. Кто-нибудь здесь перевел "старый школьный" веб-код Perl на Template Toolkit? Есть ли какие-либо трюки, которые вы можете использовать для минимизации необходимости перезаписи/переделки? Мы также не приняли решение о Template Toolkit на 100%. Если есть альтернатива, которую мы должны рассмотреть?

Какую проблему, в частности, мы пытаемся решить? Мы генерируем недействительный HTML-код и должны его очистить. Поскольку мы очищаем, мы хотим создать полностью действующий HTML 5 и, насколько это практически возможно, действительные CSS3 и Javascript. Мы используем jQuery, jQuery UI-виджеты и AJAX через jQuery. У нас есть типичная MVC-архитектура контроллера страниц, за исключением слоя "Просмотр" как такового. Мы хотели бы перейти к какой-то системе шаблонов, но не хотим переписывать все (или многое другое!) Для миграции.

Спасибо! Ed Barnard, Cannon Falls MN

Ответ 1

Вот что я нашел, так как я перевел свою практику с CGI.pm на TT, и то, что я также изучил, используя HTML:: Mason, HTML:: Template, Text:: Template, и работа с ERB и HAML в Rails.

Чем больше логики вы используете в своих дисплеях, тем более, если она написана на определенном языке с дисплеем, тем меньше вы будете иметь удовольствие.
Я пришел, чтобы предпочесть HAML для уменьшения размера содержимого моих шаблонов [В HAML закрывающие теги подразумеваются отступом]
Выполняйте большую часть логики для вычисления различных динамических битов страницы перед тем, как заглянуть в шаблон на родном языке приложения. [вызвать методы просмотра, прежде чем заниматься рендерингом].
В отношении (3), используя методы, вместо встроенной логики отображения/воспроизведения вы можете сделать свои шаблоны декларативными, поэтому, хотя вы можете выполнять логику в середине рендера, ваши шаблоны не имеют пучок логики IF/THEN/ELSE, вызывающий беспорядок.

Представьте себе достаточно маленькую, надуманную веб-страницу, состоящую из заголовка, нижнего колонтитула и тела. Предположим, что нижний колонтитул полностью статичен, тело изменяется каждый раз, когда загружается новая страница, но заголовок изменяется только тогда, когда пользователь входит в/из.

Вы можете представить заголовок, содержащий код следующим образом:

<header>
[% IF $user.is_logged_in THEN %]
   Hello [% $user.name %] - <a href="/logout/user/[% $user.id %]">Log Out</a>
[% ELSE %]
   Please <a href="/user/login">Log In</a>
[% END %]
</header>

Но вам лучше в долгосрочной перспективе сделать это в header.tt:

<header>
  [% user_info($user) |html %]
</header>

и это в View:: Helpers:: Header.pm:

sub user_info {
   my $user = shift;
   if ($user->{is_logged_in} ) {
     return "Hello $user->{name} - " . logout_link($user->{id});
   }
   else {
     return "Please " . login_link();
   }
}

sub logout_link {
  my $userid = shift;
  return qq(<a href="/logout/user/[% $userid %]">Log Out</a>)
}

Вы можете, конечно, реализовать помощников вида в TT, а не в чистом Perl, и у меня нет никаких чисел для вас, но если вы уже сделали всю свою логику в Perl, вы можете реорганизовать Perl в модули (если его еще нет), вместо того, чтобы перекодировать их в TT.

Ответ 2

Как часть вашего тестового набора, рассмотрите HTML-валидатор, например HTML:: Lint или HTML:: Tidy.