Плюсы и недостатки CGI, PHP, ASP и др. - Компьютерный форум OSzone.net

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Программирование и базы данных (http://forum.oszone.net/forumdisplay.php?f=21)

- - Плюсы и недостатки CGI, PHP, ASP и др. (http://forum.oszone.net/showthread.php?t=30788)

Требуется сделать интерактивный сайт с поддержкой баз данных (скорее всего MySQL), по сложности сравнимый с часто посещаемым интернет-магазином или аукционом. Кто-нибудь делал нечто подобное? Ни как не могу решить, на чем остановиться - CGI или PHP?

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

В чем преимущества и недостатки CGI и PHP?

Если вам не трудно опишите преимущества и недостатки ASP перед CGI и PHP.

Огромное Спасибо!

1) PERL более всего распространен (видимо, под CGI он понимается), PHP - меньше, ASP/JSP - и того меньше.

2) Общая логика работы на всех веб-серверах (из которой несложно логически вывести все плюсы и минусы):

а) клиент запрашивает файл xxx.yyy.
б) сервер в своих настройках (в частности, httpd.conf) смотрит, кто отвечает за расширение yyy и передает запрос соответствующей программе/модулю.
в) модуль делает то, что от него требуется и отдает результаты веб-серверу в выходной поток данных.
г) сервер отдает данные клиенту.

тонкости в пункте б) - сервер определяет обработчик именно по расширению, более общо - по маске, но это не важно, а важно то, что в случае php возможна ситуация, когда php (точнее, все что не CGI) будет обрабатывать файлы, где нет его команд, а простой HTML, то есть, по идее, файл можно было бы просто отдать клиенту. выход - разделение по расширениям, однако, это не всегда удобно, так как адрес документа может не меняться, а его содержимое может меняться. У Perl-а тут все проще, Perl ВСЕГДА сам полностью обрабатывает файл (то есть, логика языка другая, это не вставки кода в HTML, а вставки HTML в код), и такой проблемы нет.

пункт в) заслуживает пристального внимания, потому как именно здесь и находятся самые существенные отличия в плане работы. Перл, как я писал, ПОЛНОСТЬЮ выполняет скрипт и выдает результат на выход, тогда как PHP не выполняет скрипт, он фактически правит его.

существенная тонкость - ограниченность возможностей PHP по сравнению с перлом. пример, с которым я сам столкнулся на работе - необходимо было с сервера отправить POST/HTTPS-запрос на другой сервер, PHP это будет уметь только начиная с версии 4.3.0, для которой вышел еще только 1-й пререлиз. Есть CURL, но извольте пересобрать PHP. Плюнул и сделал на Perl-е через Net::SSLeay. То есть, если возможности перла могут быть расширены доп. библиотеками, то в серьезных случаях PHP придется пересобирать, обычно с этим нет проблем, но в случае специфического окружения (например, Informix-овский клиент) - это все слишком геморойно.

Если же речь о MySQL - все примерно пофигу, лично мое мнение - если шарим в перле - пишем на перле, если шарим в пхп - пишем на пхп.

ASP - тот же PHP, только сбоку. несколько объектов, обеспечивающих доступ к переменным окружения/ сеанса/ запроса/... Все мои знакомые, работающие в организациях, где веб лабают на asp, в разговорах плюются. Это еще более высокоуровневая штука чем PHP, расширяется через COM, так что если не гнаться за модой и думать прежде всего о надежности и расширяемости, ASP я бы не юзал.

Вообщем Сергей прав: что знаешь, на том и пишешь

Однако вот фенечки ASP:
1) на JScript можно писать скрипты ОС, серверные скрипты, клиентские скрипты, создавать COM-объекты
2) ADO (унифицированный доступ к БД)
3) Server.Execute, Server.Transfer, переменные Application, Session

А вот и ложка дегтя:
ASP.Net (ASP+) не совместим с ASP по синтаксису (епрст ms)

Самое простое магазины писать на PHP. Все зависит от того насколько посещаем этот магазин.
PHP проще PERL. Но у PERL есть свои плюсы.

А вообще можно писать на чем угодно

Я не содбираюсь здесь разводить holy war'ов, но...

Цитата:

существенная тонкость - ограниченность возможностей PHP по сравнению с перлом. пример, с которым я сам столкнулся на работе - необходимо было с сервера отправить POST/HTTPS-запрос на другой сервер, PHP это будет уметь только начиная с версии 4.3.0, для которой вышел еще только 1-й пререлиз. Есть CURL, но извольте пересобрать PHP.

Госопда! Пользуйте PEAR -- идёт по умолчанию со всеми PHP4, в некотором роде аналог PAN, только намного меньше. В данном случае нужён был HTTP_Request...

Хотя против того, что для PHP мало библиотек, глупо, но всё же надо отметить, что для всех часто-используемых Web-фенек имеются встроеные/PEAR'нутые библиотеки (или просто функции).

ivank
У меня HTTPS, а твой пример с SSL не пашет.

vasketsov, Спасибо большое. Первый раз в своей жизни получаю в форуме такую исчерпывающую и полную информацию. Еще раз спасибо большое!

А как на этом фоне выглядит Python?

Как лучше его организовать в роли ВебСкриптового: как CGI или посредством mod_python PSP (Python Server Pages) ?
И правда ли, что одинаковые скрипты, по разному ведут (работают:) или не работают:( ) себя под ОС *nix и Win32?

P.S.
Я уже посмотрел здесь http://forum.ru-board.com/topic.cgi?forum=31&topic=1537, хочу узнать мнения народа здесь. (Как показал поиск что не особо про Python как ВебСкриптовый)

P.S.S
ivank
Я так понимаю, на том форуме тот же ник, так вот как насчёт связки
Apache+Python+modPython+PyGreSQL+PostgeSQL
Какие аргументы на смену составляющих, а так же где лучше: *nix/win32?

Moderators
Может быть, надо в название темы добавить слово Python

All
Спасибо за внимание

Admiral
Теме - четыре года, что здесь, что на руборде (на котором меня уже 3 года как нет). За это время много изменилось. Не стоит поднимать такое старьё. Лучше новую тему создать.

Цитата:

Я так понимаю, на том форуме тот же ник, так вот как насчёт связки
Apache+Python+modPython+PyGreSQL+PostgeSQL
Какие аргументы на смену составляющих, а так же где лучше: *nix/win32?

Лучше, очевидно на nix, ибо для питона всего сопутствующего - родное. Про mod_python молчу, из веб-фреймворков пробовал только Django да родной CGI (давно, да и фреймворком не назовёшь...). Постгре, конечно же, рулит.

Цитата:

Теме - четыре года

Питону ещё больше. Я хотел лишь хотел увидеть как он на фоне CGI, PHP, ASP и др.

Цитата:

Не стоит поднимать такое старьё. Лучше новую тему создать.

Сейчас решим с самим языком и создадим уже тему в ВебМастерской.

Цитата:

Про mod_python молчу

Скажу я: не с первого раз удалось настроить (настраивал под win32),
программы с Питоновским синтаксисом необходимо будет переписывать в mod_pythonовский

Цитата:

из веб-фреймворков пробовал только Django да родной CGI

А как можно Django и CGI в один ряд ставить? :blink:
Ведь Django требует адаптер в роли которого является CGI или mod_python.
Может, я чего не знаю? :(

Так как я новичок по теме Питон, и тем более под Линуксом, разъясните следующее.
Что б нормально заработал Питон как ВебСкриптовый необходимо:
1)Установить Apache любой из серий 1.3.Х.Х, 2.0.Х.Х, или 2.2.Х.Х, который уже может быть установленый под одним из *nix или *BSD.
2)Установить Python 2.X.X, который предустановленый почти во всех *.nix (н.с.ч. *BSD не в курсе)
Собственно можно юзать уже исходники, главное что б первая строка была

Цитата:

#!/usr/bin/env python

и httd.conf соответственно был настроен на обработку py файлов.
Или же настроить mod_python вместо cgi, причём исходник прийдёться переписывать на mod_pythonовский синтаксис
Далее:
3)Установить базу данных.
4)И ПитонВебПакет: Django, Spyce, Webware, Zope.

Всё ли так и что не так?
Спасибо.

Admiral

Цитата:

причём исходник прийдёться переписывать на mod_pythonовский синтаксис

Синтаксис не меняется. Просто меняется среда исполнения (и соответственно подход к организации скрипта, но синтаксис остаётся прежним)

Цитата:

А как можно Django и CGI в один ряд ставить?
Ведь Django требует адаптер в роли которого является CGI или mod_python.

Есть стандартный (древний) модуль CGI. Имелся ввиду он.

А когда приложение разрабатывается на Django, то какой адаптер использовать по сути всё равно (если не хочется чего-то особенного). Особенно когда есть WSCGI. Например, дома я использовал Apache+fcgi, а на сервере просто cgi (ибо это единственный способ, который не требует правки конфигов, до которых мне просто не добраться у моего хостера).

Благодарю за столь оперативный ответ ivank. :rolleyes:

Цитата:

Синтаксис не меняется. Просто меняется среда исполнения

Далеко ходить не будем, возьмём Hello World

для CGI будет

Код:

#!/usr/local/bin/python

print "Content-type: text/html"

print



print "<h1>Hello world</h1>"

а для mod_python уже

Код:

from mod_python import apache



    def handler(req):

        req.content_type = 'text/plain'

        req.write("Hello World!")

        return apache.OK

То есть структура программы меняется, а исходник Питоновский лёгко переделывается в Модовский? :blink:

Admiral
Синтаксис языка Питон задан один раз и весьма жёстко. Другое дело, что мод-питон фктически загружает скрипт один раз как модуль и затем просто вызывает из него функцию handler. Отсюда и различия в коде (но не синтаксические, а семантические; т.е. меняется не форма записи, а смысл того, что записано).

На ASP не советую. Недостатки: убогий синтаксис бейсика, плохие средства отладки и т.д. Программировать и делать отладку на ASP будет очень сложно по сравнению с PHP.
Связка PHP+Mysql будет гораздо лучше.
На крайний случай Perl - весьма мощный язык, но программировать сложнее, чем на PHP.