|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Sergey Skvortsov 2:5020/400 05 Sep 2005 23:01:08
To : Slawa Olhovchenkov
Subject : Re: perl модули
--------------------------------------------------------------------------------
Slawa Olhovchenkov wrote:
>
> А можно кратенько для тех кто в танке и все пропустил?
> А то я сейчас man perlmod читаю и основная суть от меня что-то ускользает.
"require My::Module" - это как "require /path/to/My/Module.pm", но
загружается лишь единожды.
"use My::Module (@args)" - это лишь "require My::Module;
My::Module->import(@args)".
в целом "require" используется ну очень редко.
> >> SS> Hе хочешь вообще тратить время - пользуй require. Года через 2 не
> >> SS> вспомнишь, как оно всё работает.
> >>
> >> Через два года я не вспомню что это за maypole. И с какого конца к нему
> >> подходят и какую связку модулей он требует.
>
> SS> Модель MVC придумана во времени становления Smalltalk'а и тех пор ничего
> SS> умнее не появилось (разве что некоторые паттерны).
>
> SS> Я понимаю, что "наколенные скрипты" появились ещё раньше Cobol'а. Hо
> SS> зачем их и дальше плодить? Они жизнеспособны лишь при очень малой
> SS> сложности задачи. Если это твой случай - к чему тратить время?
>
> Добавление/убавление функциональности в монолитный скрипт неудобно. Удобнее
> положить еще один файлик (новую версию файлика).
Тогда просто делаешь refactoring. Берешь скрипт script.cgi:
script.cgi:
#!perl
...MEGA CODE...
и засовываешь в основной модуль My/Module.pm:
script.cgi:
#!perl
use My::Module;
My::Module->process();
My/Module.pm:
package My::Module
sub process {
...MEGA CODE...
}
ну и дальше всё аккуратненько раскидываешь по отдельным модулям.
В итоге выйдет что-то типа (это не есть реальный код! не пробуйте это
дома!):
script.cgi:
#!perl
use My::Module;
use My::Module::Admin;
use My::Module::User;
if($query->path_info() =~ /^admin/) {
My::Module::Admin->process();
}elsif(if($query->path_info() =~ /^user/) {
My::Module::User->process();
}else {
My::Module->process();
}
My/Module.pm:
package My::Module;
sub util_1 {
... common code ...
}
sub process {
...FALLBACK CODE...
}
My/Module/Admin.pm:
package My::Module::Admin;
use base My::Module; # inherit common code
sub process {
...SPECIAL CODE...
}
ну и т.д.
> SS> Тебе шашечки или ехать? sudo покрывает 90% потребности в suid.
> SS> Все эти suexec - извращение, поскольку в этом случае катят FastCGI и
> SS> просто application backend'ы.
>
> Hе suexec. suidный скрипт. И как ты предлагаешь мне sudo в mod_perl применять?
> Мне из скрипта надо выполнить модификацию фалов, недоступных на запись апачу и
> ты предлагаешь что?
либо делать system("sudo -u root /path/to/script"), где sudo разрешен
для www, либо делать отдельный демон (громко сказано), который висит под
нужным uid/gids принимает запроса и выполняет их. Идеально для этого
POE, хотя нетривиально на первый раз. Или тупо xinetd на localhost.
mod_perl - это в первую очередь либа, прилинкованная к apach'у и
хранящяя некое общее состояние между процессами (у нас же preforked
model?). требовать от него suexec - как требовать этого от libxml.
> Берем скрипт под mod_perl. Ставим. Думаем -- надо поправить. Создаем в апаче
> еще один виртуальный хост для отладки, копируем туда этот скрипт, модифицируем
> его. И о, черт, у нас в двух скриптах венигрет из старых и новых
> имплементаций. Уж не помню куда что попадало, но никакой изоляции. Что-то
> изменилось в этом плане?
Код является общим для процесса(ов). Виртуальные хосты - это лишь контексты.
Проблемы не будет, если разбить скрипт на packages.
--
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
