Каков наилучший подход к переносу 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

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

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

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

Answer 4

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

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

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

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

Answer 5

Одно из предположений, которые делают фреймворки, заключается в том, что 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.Вы должны оценить, какова будет стоимость перехода на это.

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