ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] mod_php + mod_include



>>>>> On Mon, 17 May 1999 17:10:48 +0300 (IDT), "Stanislav Malyshev a.k.a 
>Frodo" <frodo@sharat.co.il> said:

 AC> Это ты не про Perl, случаем? :-) Понимаешь ли, в чем дело... Написать
 AC> заковыристую авторизацию через три таблицы в базе данных (пароль, доступ
 AC> к данной странице юзеров и групп и распределение юзеров по группам) на
 AC> mod_perl можно за час. Ты на PHP сможешь? Далее, посчитать по таблице,

 SMakaF> Думаю, да. См. PHPLIB, например - на нем сейчас подобное пишу. Правда,
 SMakaF> полных групп пока нету - недосуг (пока только административные и
 SMakaF> неадминистративные юзеры), но PHPLIB их умеет. Кстати, удобнее, чем
 SMakaF> средствами HTTP - во-первых, пароль все время по сети не бегает, во 
вторых
 SMakaF> - авторизация в моем случае индивидуальна по страницам и частям 
страницы
 SMakaF> (т.е. какую-то часть можно всем, какую-то - только авторизованным, а
 SMakaF> какую-то - только самому главному администратору). mod_perl тут 
помощник
 SMakaF> небольшой - надо систему авторизации включать в код страницы. 

То есть? Что, не точно так же? То есть ты хочешь сказать, что ты делаешь 
вывод о том, что отдавать данному юзеру, а что нет, не на основании его
имени? На mod_perl это делается тупо и цинично - либо функция
авторизации, либо код в начале страницы (как удобнее) устанавливает три
переменных (попадает ли данный юзер в категорию "любой",
"авторизованный", и "самый главный администратор"), и действует в
соответствии. 

 AC> А обработка разного
 AC> заковыристого ввода из формочек, форматирование текста, хранящегося в
 AC> базе в HTML на лету (хранить в HTML не предлагать, он еще и в виде
 AC> текста должен выдаваться)?

 SMakaF> Если сложнее простого regexp - тут выгоднее на Perl. я же говорю -
 SMakaF> *инструмент под конкретную задачу*. Приведение задач, в которых 
инструмент
 SMakaF> не работает, сам инструмент ничуть не умаляет. 80% задач (по счету, не 
по
 SMakaF> времени работы :) - простое сунуть-вынуть в базу данных :) Там Perl 
просто
 SMakaF> не нужен.

Ну вот ради того, чтобы решить 20% задач, все равно приходится
использовать Perl, все равно приходится цеплять mod_perl. Чтобы решать
не связанные с вебом задачи, тоже приходится использовать Perl. И нафига
тогда учить PHP, функциональность которого mod_perl перекрывает? О чем
тебе, собственно, Витус и писал. Если у тебя нет задач на вебе под Perl, 
тогда, может быть, PHP и более осмыслен. И то никто еще не считал...

-- 
Artem Chuprina                             E-mail: ran@pirit.com
Network Administrator                        FIDO: 2:5020/371.32
PIRIT Corp.                              Phone: +7(095) 115-7101
=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.