Каков наилучший подход для миграции CGI в Framework?

Question

У меня есть большое веб-приложение, работающее на Perl CGI. Он работает хорошо, он хорошо написан, но, как это было в прошлом, все html определены жестко закодированными в вызовах CGI, так что, как вы можете себе представить, это трудно поддерживать, улучшать и т. Д. Итак, теперь я хотел бы начать добавить некоторые шаблоны и интегрировать с каркасом (катализатор или CGI :: application). Мой вопрос: у кого-нибудь здесь есть такой опыт? Есть какие-то вещи, на которые я должен обратить внимание? Я знаю, что с обеими платформами я могу запускать нативные CGI-скрипты, так что это хорошо, потому что я могу запускать обе версии («встроенный» код CGI-рекламы) вместе без какой-либо травмы. Любые советы?

Answer 1

Сначала напишите тесты (например, с Test::WWW::Mechanize). Затем, когда вы меняете вещи, вы всегда знаете, что что-то ломается и что ломается.

Затем извлекайте HTML в шаблоны, а часто используемые подпрограммы - в модули. После этого переходить на рамки становится проще простого.

В общем, делайте шаг за шагом, чтобы у вас всегда было работающее приложение.

Answer 2

Извлечение HTML из логики обработки в CGI-скрипте. Определите весь код, который влияет на вывод HTML, поскольку они являются кандидатами на получение переменных шаблона. Разделите это на HTML-файл, где идентифицированные части будут помечены переменными шаблона. В конце концов вы сможете реорганизовать страницу так, чтобы вся обработка выполнялась в начале кода, а HTML-шаблон вызывался в конце всей обработки.

Answer 3

Одно из предположений, которые делают фреймворки, заключается в том, что URL-адреса соответствуют коду. Например, в рамках вы часто видите следующее:

http://app.com/docs/list
http://app.com/docs/view/123

Обычно, хотя старые CGI-скрипты не работают так, у вас больше шансов получить что-то вроде:

http://app.com/docs.cgi?action=view&id=123

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

Кроме того, фреймворки обеспечивают поддержку некоторого вида ORM (объектно-реляционного картографа), который абстрагирует вызовы базы данных и позволяет работать только с объектами. Для Catalyst обычно это DBIx::Class. Вы должны оценить, сколько будет стоить переход на это.

Вы, вероятно, обнаружите, что хотите выполнить полную переписку, используя старый код в качестве эталонной платформы. Это может быть гораздо меньше работы, чем вы ожидаете. Однако начните с нескольких игрушечных сайтов, чтобы почувствовать, какой фреймворк / шаблон / шаблон вы решите использовать.

Answer 4

Вот как я это сделал, используя Python вместо Perl, но это не должно иметь значения:

1. Разделяет HTML и код на отдельные файлы. Для этого я использовал шаблонный движок .
2. Создано функций из кода , которое отображало шаблон с набором параметров.
3. Организовал функции (которые я назвал views , вдохновленные Джанго) разумным способом. (Представления администратора, Представления пользователя и т. Д.) Все представления следуют одному и тому же соглашению о вызовах !
4. Рефакторинг базы данных и запросов, так что views будет содержать только определенный код вида (читай: обработка GET, POST-запросов и т. Д., Но ничего низкоуровневого!) , Для этого сильно полагался на существующие библиотеки.

Я сейчас здесь. :-) Следующий очевидный шаг - это, конечно:

• Напишите диспетчер , который сопоставляет URL с представлениями . Это также приведет к более приятным URL-адресам, более приятному 404- и обработке ошибок, конечно.

Answer 5

В такой ситуации, переписывая с нуля, старый код полезен для A) тестирования и B) деталей проекта. В идеале вы должны сделать набор тестов для всех основных функций, которые вы хотите тиражировать, или, по крайней мере, тестов, которые анализируют страницы конечных результатов, чтобы вы могли видеть, что новый код возвращает ту же информацию для тех же входных данных.

Детали дизайна в коде могут быть бесполезны, в зависимости от того, насколько полно фреймворк обрабатывает автоматически. Если у вас есть хороший набор тестов, и прямое преобразование работает хорошо, все готово. Если поведение нового не соответствует старому, вам, вероятно, нужно глубже вникнуть в «почему?». и это, вероятно, будет выглядеть странно, на первый взгляд не имеет смысла.

Прежде всего нужно запомнить одну вещь: выяснить, не делал ли кто-то нечто подобное в используемой вами платформе. Вы можете сэкономить много времени и денег.