Каков наилучший подход для переноса CGI на платформу?

Question

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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