Какой лучший способ написать приложение Perl CGI?

Каждый пример, который я видел в CGI/Perl, в основном представляет собой набор операторов печати, содержащих HTML, и это не похоже на лучший способ написать приложение CGI. Есть лучший способ сделать это? Спасибо.

EDIT: я решил использовать CGI:: Application и HTML:: Template и использовать следующий учебник: http://docs.google.com/View?docid=dd363fg9_77gb4hdh7b. Спасибо!

Ответ 1

Абсолютно (вы, вероятно, смотрите учебники с 90-х годов). Вы захотите выбрать фреймворк. В Perl-land это самый популярный выбор:

  • CGI::Application - очень легкий с большим количеством плагинов сообщества.
  • Catalyst - тяжелее с большим количеством колоколов и свистков
  • Jifty - более магический, чем выше

Ответ 2

Это действительно большой вопрос. Короче говоря, лучший способ называется Model/View/Controller (aka MVC). С MVC ваше приложение разбивается на три части.

Модель - это ваши данные и бизнес-логика. Это материал, составляющий основу вашего приложения.

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

Наконец, у вас есть контроллер. Это отвечает за объединение модели и представления. Он принимает запрос пользователя, получает соответствующие объекты модели и вызывает соответствующее представление.

mpeters уже упомянули несколько инфраструктур MVC для Perl. Вы также захотите выбрать шаблонный движок. Двумя наиболее популярными являются Template Toolkit и Mason.

Ответ 3

Оставив вопрос о структуре CGI vs MVC на данный момент, то, что вам нужно, это один из модулей шаблонов вывода из CPAN.

Инструмент Template Toolkit очень популярен (Template.pm на CPAN) Также популярны Text:: Template, HTML:: Template и HTML:: Mason.

HTML:: Mason - это гораздо больше, чем шаблонный модуль, и, как таковой, может быть слишком тяжелым для простого приложения CGI, но стоит немного разобраться, когда вы решаете, что было бы лучше для вас.

Текст:: Шаблон достаточно прост и использует Perl внутри шаблонов, поэтому вы можете перебирать данные и выполнять логику отображения в Perl. Это воспринимается как профессионалом, так и людьми.

HTML:: Шаблон также мал и прост. Он реализует свой собственный небольшой набор тегов для обработки if/then/else, настройки переменных и циклирования. Это. Это рассматривается как как pro, так и con для противоположных аргументов в виде Text:: Template.

Инструмент Template Toolkit (TT) реализует очень большой языковой язык, содержащий цикл и логику, и многое другое.

Я использовал HTML:: Template one и нашел, что мне нужны еще несколько функций. Затем я использовал Text:: Template с успехом, но нашел, что он хочет немного обмануть пространство имен, чтобы немного раздражать. Я узнал и полюбил Template Toolkit. Для меня это просто кажется правильным. Ваш пробег может отличаться.

Конечно, по-прежнему существует старый метод "print HTML", иногда достаточно нескольких инструкций печати. Но вы столкнулись с идеей ветки вашего дисплея от вашей основной логики. Что хорошо.

Это первый шаг вниз по пути к Model/View/Controller (MVC), в котором вы сохраняете отдельную модель данных и бизнес-логику (ваш код, который принимает вход, что-то делает с ним и решает, что нужно выводить), ваш ввод/вывод (шаблоны или операторы печати - HTML, PDF и т.д.) и код, который соединяет эти два (CGI, CGI:: Application, Catalyst MVC Framework и т.д.). Идея состоит в том, что изменение структуры данных (в модели) не должно требовать внесения изменений в ваши выходные процедуры (представление).

Ответ 4

Perl5 Wiki предоставляет хороший (хотя еще не полный) список веб-фреймворки и templates.

Статьи сравнения, связанные в записи wiki-шаблонов, заслуживают внимания. Я бы также рекомендовал прочитать эту систему шаблонов стилей стиля на PerlMonks.

Для шаблонов тогда Template Toolkit является тем, который я использовал больше всего и могу очень рекомендовать его. Существует также книга O'Reilly и, вероятно, самая используемая система шаблонов в королевстве Perl (внутри или вне веб-фреймворков).

Еще один подход, который я все больше привлекал, - это решения без шаблонов. Модули, такие как Template:: Declare и HTML:: AsSubs установите этот счет.

Ответ 5

Одним из решений, которое, как я считаю, является правильным равновесием в дилемме Framework/Roll-your-own, является использование трех ключевых модулей perl: CGI.pm, Template Toolkit и DBI. С помощью этих трех модулей вы можете создавать элегантные MVC-программы, которые легко писать и поддерживать.

Все три модуля очень гибки в Template Toolkit (TT), позволяя вам выводить данные в html, XML или даже PDF, если вам нужно. Вы также можете включить Perl-логику в TT, даже добавьте туда интерфейс базы данных. Это делает ваши CGI-скрипты очень маленькими и удобными в обслуживании, особенно когда вы используете "стандартную" прагму.

Он также позволяет помещать объекты JavaScript и AJAXy в сам шаблон, который имитирует разделение между клиентом и сервером.

Эти три модуля являются одними из самых популярных на CPAN, имеют отличную документацию и широкую пользовательскую базу. Кроме того, развивая эти средства, вы можете быстро перейти к mod_perl, как только вы прототипировали свой код, давая вам быстрый переход к встроенной среде perl Apache.

В целом компактный, но гибкий набор инструментов.

Ответ 6

Вы также можете отделить презентацию от кода и просто использовать систему шаблонов, не требуя при этом всех накладных расходов на полномасштабную инфраструктуру. Template Toolkit может использоваться сам по себе таким же образом, как Mason, хотя я склонен считать, что это скорее структура, замаскированная под систему шаблонов.

Если вы действительно gung-ho о разделении кода из презентации, имейте в виду, что TT и Mason позволяют (или даже поощрять, в зависимости от того, какие документы вы читаете) исполняемый код, который должен быть встроен в шаблоны. Лично я считаю, что код внедрения в вашем HTML не лучше, чем вложение HTML в ваш код, поэтому я предпочитаю HTML:: Template.