Django 1.3 вышел в свет

Пока не сделают нормальный шаблонизатор - не нужно.

А что подразумевается под словом «нормальный»?:)

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

Кто-то на лоре писал что Django ущербен by-design. Это так?

Он офигенен by design.

есть словарь:

d = {'a':1, 'b': 2}

есть ключ с заведомо неизвестным значением k.

как отобразить в шаблоне d[k]?

посмотри вопрос ниже твоего поста.

никак. нужно это сделать во view.

//КО

>> Он офигенен by design.

Ну-ну.

Подрастешь — поймешь.

Дано: есть каша в шаблоне.

Решить: как по консинстенции и типу каши узнать стаж автора в php.

Если ты покажешь способ решения проблемы, тогда я поклонюсь тебе и назову Мастером, а до того ты просто балабол.

И да, реши проблему без написания собственных фильтров, а в view, как советовал твой колега.

Основанные на класса представления (view)

Fix required!

И да, пост-детектор получился;)

Написать свой тег если уж так хочется это сделать в шаблоне.

http://www.linux.org.ru/jump-message.jsp?msgid=6053645&cid=6054154

> И да, реши проблему без написания собственных фильтров, а в view, как советовал твой колега.

Если мсье сторонник решения проблем методом «назло маме обморожу лучше», и ищет не лучшее решение проблемы, а усложняет себе жизнь - то он точно только вчера с php слез.

Проблемы свои решай самостоятельно. А шаблон - это всё таки шаблон.

> Если ты покажешь способ решения проблемы, тогда я поклонюсь тебе и назову Мастером, а до того ты просто балабол.

Заниматься самоунижением, чтобы один недалёкий во что-то поверил или не поверил? Детский сад, игра «кто круче».

Когда оно будет поддерживать Python 3?

Когда оно будет поддерживать Python 3?

А его кто-то всерьёз воспринимает? :)

(Я про Python 3)

Когда оно будет поддерживать Python 3?

есть форки, на сколько они живы хз

А его кто-то всерьёз воспринимает? :)

(Я про Python 3)

Большинство вменяемых программистов на Python понимают необходимость миграции на третью ветку рано или поздно. Ряд основополагающих проектов, например, numpy/scipy и pyQT уже реализовали поддержку Python 3.x.

лет через 5 наверное. я вот думаю пока изучать cherrypy там поддержку python3 добавили да и вообще более питонистый и простой фреймворк.

Каша в шаблонах - это плохой тон программирования даже в том же php. Логика отображения во view-хах.

Я, archlinux, etc.

А, ну так может им это...проще опять на этот свой PHP залезть?:)

Не может, а НУЖЕТ

он ущербен by-design из-за того, что написан на питоне

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

> Основанные на класса представления (view)

Раз уж исправляете, так хоть за логикой предложения то следите:)

А на чём его надо было писать?

В джанге хреновый urls.py. Из очевидного.

> В джанге хреновый urls.py. Из очевидного.

а можно с примерами? что там хренового?

на джаве/grails, очевидно же

> Кто-то на лоре писал что Django ущербен by-design. Это так?

да

> а можно с примерами? что там хренового?

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

> что его вообще не должно быть

А что должно быть? Где сделано так как нужно?

> а можно с примерами? что там хренового?

Из явного --- занудное задание регулярных выражений для целых чисел и получение их в виде строк во view-методы

Во flask-е
Но я предпочитаю немного иной подход (похоже на pylons — там тоже лучше чем в django, но есть несколько совершенно лишних шагов):

Заводится каталог controllers
В каталоге controllers создаются модули cont1.py, cont2.py и т.д.
В этих модулях все функции декорированные action привязываются к URL
вида /controllers/contX/<func name>/arg1/arg2… . В питоне 3 с его аннотациями можно будет ещё автоматически вешать нужные условия на argX. Вот, всё прозрачно, определяется в одном месте — это pythonic. А как сделано в джанго вообще непонятно.

Вот тут у меня нет уверенности, что это будет удобно.

Это очень удобно. Если нужно какое-то особое имя пути — всегда есть соотв. декоратор.

> на джаве/grails, очевидно же

Платформу JVM оставьте Ъ-ентерпрайзу, пожалуйста. Вам никто не запрещает ею пользоваться, а я, к примеру, хочу писать с удовольствием.

> Основанные на класса представления (view)

Такие view можно было делать всегда. Другое дело, что добавили class-based _generic_ views и сказали - рекомендуем их использовать, да

Analogs of all the old function-based generic views have been provided, along with a completely generic view base class that can be used as the basis for reusable applications that can be easily extended.

P.S.> Новость оформлена сверх коряво. Корректоров уже всех порасстреливали?

В том и дело. Получать единый список этих путей придется анализом декораторов %(

> Получать единый список этих путей придется анализом декораторов %(

это что, сложно? Так или иначе, для этого придётся проверять всего два декоратора.

Не понимаю смысла вести web разработку на питонах и прочих php.

В наши дни создан .Net инструментарий и сысокопроизводительные фреймворки для разработки любых сайтов.

Сообщество тратит много времени на разработку откровенных велосипедов. Почему не использовать документированный и протестированный временем C# не понятно, видимо, не только мне.

неудобно, сцешарп слишком низкоуровневый.

Не сложно, конечно.

Кстати, я еще не уверен, что руление urls из единого места --- такая уж неправильная идея.

> вида /controllers/contX/<func name>/arg1/arg2…

Какието нечеловеческие урлы получаются.

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