ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


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


  ПРОГРАММЫ 



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












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

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

Re: use



On 06.07.2011 20:08, Un Lexx wrote:

для того, чтобы видеть полный конфиг - надо будет постоянно
переключаться между несколькими конфигурационными файлами,

т.е. в инклудах вас не устраивает то
что вы не знаете что написано внутри этого инклуда

нет. больше всего в инклудах не устраивает две вещи:

1. сравнительно большие затраты времени и сил на то, чтобы узнать,
что именно написано внутри какого-то файла, включаемого в конфиг сайта.

2. еще большие затраты времени и сил, чтобы понять какие сайты может затронуть модификация инклуда, поскольку все они имеют глобальную область видимости и в общем случае могут быть включены в какой
угодно сайт. особенно это актуально, если конфиги nginx
на сервере правит не один человек, а несколько админов.

Для языков программирования решение уже найдено - локальный
контекст и область видимости переменных, для конфига nginx -
пока что все фрагменты конфига могут иметь только глобальный
контекст и область видимости - как и глобальные переменные в С.

чтобы было понятно о чем я говорю - см. например,
http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#try_files

"Пример использования вместе с Drupal/FastCGI"

и

"Пример использования вместе с Wordpress и Joomla"

в каждом из этих примеров блок с fastcgi_param встречается
несколько раз в конфиге одного и того же сайта,
но для каждого из сайтов он будет уникальный.

так что вынесение общего блока в отдельный файл
будет только засорением глобальной области видимости
и дробление конфигурации на много мелких файлов,
что в результате будет только значительно затруднять
и замедлять чтение/понимание такого разделенного конфига.

а поскольку конфиг читается намного чаще, чем пишется,
то и получается, что проще и надежнее воспользоваться
старым индусским методом - через copy / paste, забыв
про принцип DRY. В результате - для внесения всего одного
изменения в конфигурацию nginx - надо будет править один
и тот же конфигурационный файл в нескольких разных местах.

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

выход из состояния такого deadlock`а и тупика - я и предлагаю,
с помощью новых директив block blockname { ... } и use blockname;

директиву block можно рассматривать как виртуальный файл,
который не занимает места в файловой системе, а директива
use - это практически то же самое, что и директива include,
только вместо имени файла задается имя "виртуального" файла.

И в этом случае - не будет проблем из-за большого количества
мелких файлов, потому что все будет внутри одного конфига сайта,
и не будет проблем из-за повторения фрагментов через copy/paste
при внесении изменений в такой конфиг. потому что теперь будет
одно логическое изменение конфига == одно физическое изменение.

--
Best regards,
 Gena


_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru

  • Follow-Ups:

 




Copyright © Lexa Software, 1996-2009.