Вопросы о том где вызывается start_response наводят на мысль что в middleware превращены на самом деле зависимые компоненты которые лучше реализовать обычными библитечными вызовами. Если говорить о XSLT-преобразователе применямом к любому WSGI-приложению, то я думаю такое наверняка уже кто-то реализовал (wsgi+xslt).

Ранее работал со SkunkWeb-ом. В нем меня устраивало маппирование URI в имя файла в файловой системе. Кроме того для удобства разработки было предусмотренно исключение, генерация которого говорила серверу “ответ готов, отсылай клиенту” (патч для ReturnValue). Другие исключения выдавали ошибку 5xx. Вообщем была сильна “вуду”. Часть этого вуду хочу сохранить, ибо удобно, по крайней мере мне.

Собственно сам вопрос – никак не могу понять, куда и каким местом приделать start_response во всем стеке исполнения мидлварин? Просто вариаций масса, хочется же остановится на чем-то предпочтительном.

daevaorn, хоть вопросы и не ко мне, я мог бы ответить только одним образом: попробуйте и так и так и сравните. Если не выйдет выигрыша, то и ладно, оставьте такой подход тем, кому так удобнее. С другой стороны, я не понимаю людей которые довольны фреймворками, я вот никогда не был доволен. Пользовался, потому что не представлял как иначе, но борьбы с фреймворком, чтения доков итп всегда было больше чем дела. Вот нашел как делать иначе и забыл фреймворки как страшный сон. Более того, плюсы подхода всплывают в самых неожиданных местах, что для меня всегда признак во всех отношениях лучшего решения.

Насчет отличий применения Джанго и библиотек это извините сами разберитесь, если разницы вообще не видно, то мои соболезнования.

Сделать один сайт, два или три. Но когда идет поточная работа над сотней проектов, и у каждого своя специфика, использовать “сферическую лошадь” становится невозможным. Издержки от использования фреймворка растут прямо пропорционально количеству разрабатываемых и обслуживаемых проектов. Проектов, подчеркиваю, а не “частных порталов Васи Пупкина”

А расскажите про издержки использования Джанго? И как это зависит от количества проектов? Серьезно, очень интересно. Особенно в сравнении, если в этих проектах был бы полностью собственной code base.

Единственное, что меня заботит – это экономическая эффективность.Стоимость развертывания масштабируемых проектов, издержки на содержание обслуживающего эти проекты железа. Время – деньги?

А от скорости разработки это не зависит? Т.е. если собственный code base пишетсы в два раза дольше это эфективнее?

Перманентно ковырять транки/SVN и адаптировать свой код, каждый раз заново? Может техноманьякам это и нравится, но такой подход очень вреден для бизнеса. Мне было бы любопытно посмотреть на “экономящих время” программистов, когда “неожиданно” придется вносить изменения в сотню проектов из-за новых мулечек свежей версии фреймворка.

А что мещает не изменять? И как отлично это от того, что свой доморощенный фремворк тоже будет расти со временем?

Использование же чистого кода, оставляет наши руки свободными и позволяет дописывать нужные нам и нашим клиентам “фичи”.

А у вас клиенты часто выдвигают изменяющиеся требовния к web request stack как к таковому?

И главное, чем отличает применение джанго от применения разных библиотек?

Спасибо.

Как я уже сказал у Ивана, я не против Django. Мне нравится этот проект, но он применим ровно в своих задачах. Сделать один сайт, два или три. Но когда идет поточная работа над сотней проектов, и у каждого своя специфика, использовать “сферическую лошадь” становится невозможным. Издержки от использования фреймворка растут прямо пропорционально количеству разрабатываемых и обслуживаемых проектов. Проектов, подчеркиваю, а не “частных порталов Васи Пупкина”. Да, я старый зануда, брюзга и сноб.

Code is poetry – есть такой слоган. А писать стихи, будучи зажатым требованиями цензуры фреймворка, несколько проблематично, хотя и коньюнктурно. Использование отдельных библиотек, предоставляет существенно больше свободы маневра и снижает издержки ресурсов. Многие программисты обленились, увы. Как было выше замечено, многие уже хотят, чтобы фреймворк выполнял за них всю работу. Дескать, это экономит время. Честно говоря, меня мало беспокоят затраты времени программистами. Поменьше в игрульки играть будут Единственное, что меня заботит – это экономическая эффективность. Стоимость развертывания масштабируемых проектов, издержки на содержание обслуживающего эти проекты железа. Время – деньги? Согласен на все сто процентов. Но время сэкономленное при разработке проектов с использованием умных фреймворков, рано или поздно выходит “чревато боком”. Особенно это чревато выходило до релиза джанги номер 1. Перманентно ковырять транки/SVN и адаптировать свой код, каждый раз заново? Может техноманьякам это и нравится, но такой подход очень вреден для бизнеса. Мне было бы любопытно посмотреть на “экономящих время” программистов, когда “неожиданно” придется вносить изменения в сотню проектов из-за новых мулечек свежей версии фреймворка. Использование же чистого кода, оставляет наши руки свободными и позволяет дописывать нужные нам и нашим клиентам “фичи”. И особенно в этом нам помогает тот же WSGI. Хоть я и большой нелюбитель “прокладок”, но в данном случае использование этой технологии весьма целесообразно, поскольку помогает с легкостью подключать и модифицировать библиотеки, без затрагивания самого кода бизнес-логики. И позволяет делать это быстро и чрезвычайно эффективно.

Спасибо за Ваш цикл статей, Уважаемый Сергей.

Другой вопрос, что многие исподтишка уже юзают что-то такое и не признаются в этом – это факт

Paster впору было бы назвать copy-paster’ом, потому что именно это он и делает — создает тонны бойлерплейта под проект (например посмотрите обзор содержимого пустого проекта на Pylons). Я не знаю чем для себя оправдывают такой подход его адепты, но по-моему это полный.. в общем это ужасно.

Я ко всему стараюсь относиться скептически, так что не знаю насколько много людей действительно поймут многое из написанного, хоть и надеюсь что из статей есть что вынести. Если пригодится хоть одному человеку, то уже хорошо — осчастливить весь мир я и не пытаюсь. Человек без опыта попытавшись писать код таким образом наверняка наделает немало косяков, но мне кажется всё таки результат всё равно будет лучше чем с фреймворком. Я осторожничаю такое утверждать, ведь это только домыслы, но мне было бы интересно услышать про опыт тех, кто всё же попробует на свой страх и риск.

Насчет отзыва.. ну кто-то Ивана вяло одергивал, а кто-то писал “в пух и прах”, “спасибо наставили на путь истинный” или “там учат плохому!”. Особо порадовали говноблогеры видящие во всем поиск популярности )) Вот уж точно каждый со своим аршином. Я как прочитал комментарии сразу задумался, а зачем объяснять в чем там ошибка? Если люди сами не видят, что критика вообще непонятно на что направлена (Иван потом сам признался что критика не просто не про мои статьи, она вообще про точку зрения которую он затруднился назвать где вообще встречал). Так вот если я им обьясню, условно, что наоборот WSGI — рулит, а Джанго — говно, то что с того? Какая разница что будут думать люди которые сами не думают? Ну и не стал потому поначалу отвечать.

Джанго это “коммюнити”, а приблизительно 100%-м людей нужно принадлежать какой-то клике, клану, сообществу, нации, так что она отвечает тем запросам, которым просто выполнение своей работы отвечать не может. Понятно, что недостаток реверансов в сторону великой и могучей Джанги сразу обозначило меня как “чужого”, поэтому не нужно далеко ходить за настоящей причиной неприятия. Толпа она и в Интернете толпа, всегда есть исключения, так что кто-то конечно использует фреймворк потому что действительно, обьективно для него это лучше, но чем больше об этом разговоров, тем больше у меня на этот счет сомнений.

К слову, как раз по этому же поводу обсуждал Джанговские темплейты и родился новый смайлик (в качестве шутки конечно):
{% – Я ДЖАНГИСТО!!

Пятая статья уже написана и сверстана, должна появиться на днях.

У вас все хорошо получилось. Продолжайте писать о своем опыте.