Должен ли я использовать функционально-ориентированные или объектно-ориентированные интерфейсы CGI?

Question

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

Answer 1

Когда мне нужно собрать очень простой скрипт CGI, я использую интерфейс OO модуля CGI.

Я использую интерфейс ООП, потому что стандартный императивный интерфейс импортирует тонну символов, которые могут конфликтовать с моими собственными символами. Мне это не нравится, поэтому я всегда запрещаю ввоз символов. Я не use CGI;. Вместо этого я use CGI ();.

Я также ограничиваю свое использование генерацией параметров заголовка и разбора. Я всегда генерирую HTML как HTML или еще лучше, использую шаблонный модуль, такой как TemplateToolkit.

Я строго избегаю функций генерации HTML в CGI. Почему?

• Я (как и многие другие люди) уже знаю HTML, и не вижу никакой выгоды в изучении псевдо-html-интерфейса CGI.
• Когда скрипт растет и его необходимо использовать в другой среде, проще извлечь блоки или шаблоны HTML и использовать их повторно.

Не интерпретируйте то, что я написал, как общее осуждение CGI.pm. В CGI.pm есть что любить. Это дает право генерации типа контента. Это делает анализ параметров тривиальным. Это основной модуль. Это облегчает отладку и тестирование командной строки.

Answer 2

Я думаю, что нашел ответ на свой вопрос

http://perldoc.perl.org/CGI.html#PROGRAMMING-STYLE

При чтении часто задаваемых вопросов приведен пример многократного использования объектов CGI: я могу сохранить CGI и загрузить предыдущийCGI объекты, что весьма полезно.

Answer 3

Помимо преимуществ, на которые вы ссылаетесь, я также хотел бы отметить, что использование CGI.pm в ООП намного удобнее для чтения (по крайней мере для меня) и управления, чем для функциональной версии.

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