|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Sergey Skvortsov 2:5020/400 05 Sep 2005 21:57:19
To : Slawa Olhovchenkov
Subject : Re: perl модули
--------------------------------------------------------------------------------
Slawa Olhovchenkov wrote:
>
> для use можно будет написать
>
> foreach $f (@kwelwords) {
> use $f;
нет. надо:
eval "use $f;";
> }
>
> и это будет чем-то удобнее?
чем require? смотря как модуль написан.
> >> Я не собираюсь писать немерянного размера веб-приложение. Порядка 1000
> >> строк, строк по 200 на модуль.
> SS> И что? Посмотри на Maypole - вот замечательный пример про пиво:
> SS> http://maypole.perl.org/?About
>
> У меня есть эмпирическое наблюдение, что все такие тулзы только для пива и
> годятся. Шаг влево-вправо -- и ты в жопе и тратишь время на то, что бы
> натянуть ихнюю недокументированную косную модель на твою логику, которая ну
> совсем ими не предусматривалась. Причем времени уходит больше, чем если
> настругать без всяких тулзов.
1. Твоя эмпирика неубедительна, поскольку неясна её репрезентативность.
2. Эти "тулзы" уместны именно в том случае, если ты хочешь на разработку
потратить минимум времени при немедленной отдаче.
3. Сложную логика предметной область всё равно вылезет за любой
framework - но это же не тот случай?
Ты в данной случае ратуешь за "чтение how-to" вместо "чтения
rfc/manpages", что странно. Уж не говоря о принципиальной
несовместимости твоих начальных условий "идеологически правильно" и
"минимум времени на изучение/разработку".
> SS> Hе хочешь вообще тратить время - пользуй require. Года через 2 не
> SS> вспомнишь, как оно всё работает.
>
> Через два года я не вспомню что это за maypole. И с какого конца к нему
> подходят и какую связку модулей он требует.
Модель MVC придумана во времени становления Smalltalk'а и тех пор ничего
умнее не появилось (разве что некоторые паттерны).
Я понимаю, что "наколенные скрипты" появились ещё раньше Cobol'а. Hо
зачем их и дальше плодить? Они жизнеспособны лишь при очень малой
сложности задачи. Если это твой случай - к чему тратить время?
> Hе, мне нужно максимально самодостаточное решение.
Hо "самодостаточное решение" в первую очередь предполагает отсутствие
привязки к разработчику. А быстро склёпанные поделки - имеют краткий
срок, когда их можно считать maintainable.
> Hе говоря уж о том, что он идет в сад только за его требования к наличию SQL
> (которого часто просто не бывает) и Template::Plugin::Class которой за собой
> тянет столько всякого барахла, что у меня терпения недостанет ставить это все
> в каждое нужное место.
О да, "portupgrade -NP www/p5-Maypole" - это изматывает.
> >> Плюс я ставил всякие темплэйты и массоны -- каждый за собой такой хвост
> >> всякого говна тащит -- мама не горюй. И все это утяжеляет систему. Что
> >> для CGI приводит к увеличению времени отклика.
> SS> mod_perl
>
> обучишь его suid -- предлагай.
Тебе шашечки или ехать? sudo покрывает 90% потребности в suid.
Все эти suexec - извращение, поскольку в этом случае катят FastCGI и
просто application backend'ы.
> SS> Открою ужасный секрет - не обязательно писать handler'ы под mod_perl.
>
> Впрочем, mod_perl обладает такими забавными побочными эффектами... в общем, в
> сад.
У тебя позиция человека не евшего устриц и, на основе сторонних отзывов,
вдумчиво их изучив, понял что вкус ясен и пробовать не стоит. Hе смеши.
--
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
