Что плохого в Django?

Class based view из Django (как впрочем и вся сама она) как-то не особо хорошо выглядят на фоне Zope и Pyramid traversal. :-)

Наверное поэтому разработчики django не стали внедрять такую фичу, чего проще ее было реализовать в django

Радоваться тому, что django.db.models ущербна на фоне SQLAlchemy/Doctrine... Ну, я как-то даже не знаю. :D

Ага, тогда, наверное, должно подойти. Посмотрю попозже.

Если бы только доллары, а еще и вары, я так поняла дань php4 ,поля формы , которые почему то нужно оформлять как массив, да не просто массив, а с учетом имеющихся атрибутов у полей еще и двух этажный массив...

Я там ошибся чуть, вот этот чувак верно написал: Что плохого в Django? (комментарий)

В Pyramid умеет

Ок, но с ним буду разбираться в любом случае даже позже, чем с Grails :) Но тоже посмотрю, интересно сравнить всё подходящее под эту задачу.

а еще и вары

var — это alias для public начиная с PHP 5.0.

Можно писать public/protected/private вместо var если так не нравится.

Django ... 4,5 кб. исходников. 121 строка

То, на чём я привык работать делает тот же тест в полном объёме за 900 байт и в 28 строк

Ну мы уже спорили на эту тему. Я тоже могу написать враппер над джангой/фласком/етс и его вызывать. В результате будет одна строка кода и 20 байт. Это можно будет назвать «Мой фреймворк ХХХ наименее многословен»?

С таким подходом все фреймворки заведомо проиграли ЦМСкам на типичных задачах авторов ЦМСок.

надо же как я отстала, оказывается в убогом пхп есть инкапсуляция, только спрашивается зачем)))

поля формы , которые почему то нужно оформлять как массив

Только лишь конвеншн, принятый в фреймворке KRoN73. Не более.

Посмотрите Symfony2. Там хорошим тоном считаются POPO-модели (plain old PHP object; по аналогии с POJO).

а можно не писать ничего тогда член будет public(по умолчанию), если я не ошибаюсь)))поправьте меня , если ошибаюсь

Ничем не плох в своей нише. Просто некоторым болит ниже спины, когда мейнстримовый проект называют хорошим.

Ну а если уеб-программизду не нужна админка, орм и темплейты, но он все равно лепит джангу в проект, то он классическоий ССЗБ.

Ну а если уеб-программизду не нужна админка, орм и темплейты, но он все равно лепит джангу в проект, то он классическоий ССЗБ.

Тогда если всего этого не нужно он не берет django , а использует библиотеки или микрофреймворки

Webob, Werkzeug, pesto, bottle, flask... etc

только спрашивается зачем)))

А в других языках зачем?

Для такого узко специализированного языка как пэхэпэ ООП не нужно

Для такого узко специализированного языка как пэхэпэ ООП не нужно

Да оно ни для какого языка не нужно, если не хочется писать в 5 раз компактнее и в 5 раз быстрее и неизвестно во сколько раз надёжнее :)

а можно не писать ничего … поправьте меня , если ошибаюсь

Ошибаешься, если ничего не писать, то будет ошибка :)
unexpected T_VARIABLE, expecting T_FUNCTION

Только лишь конвеншн, принятый в фреймворке KRoN73. Не более.

При чём даже тут я привёл просто как native-php вариант. Есть отдельный YAML, есть YAML в комментариях в PHPDoc стиле (просто последнюю фишку только начинаю понемногу вводить, так что формально нельзя сказать, что она готова).

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

Не соображу по документации, как мне обратиться к объекту, который не по pk ищется, а по одному из полей? Т.е. нужно что-то типа:

url(r'^(?P<page_url>.*)$', DetailView.as_view(model=PageDB.objects.get(url='/'+page_url), template_name='page.html')),

но по сравнению с зопой

По сравнению с Зопой что угодно будет хорошо выглядеть :D Имел я честь поработать с Завалишиным лет 10 с копейками назад :D

как мне обратиться к объекту, который не по pk ищется

Вроде вместо <pk> просто прописать <%fieldname%>.

Вроде вместо <pk> просто прописать <%fieldname%>.

Э... Куда?

Очевидно, сюда:

url(r'^(?P<pk>[d/]+)$', 

Мне не ID по полю с не «id» именем нужно. Мне нужно искать по полю, содержащему URL. При чём не просто URL, а добавить ведущий слеш, так как в urlpatterns он отрезается.

Зачем хранить ведущий слэш?

Потому что это решение не столько частной конкретной задачи, сколько общей задачи преобразования параметров ссылки в ID.

Мне же тест интересен с практической точки зрения.

Не каждую ссылку можно однозначно преобразовать в значение какого-то поля объекта. Например, ссылка может быть абсолютной, вместе с хостом в случае нескольких хостов у одного проекта. Т.е. в запросе нужно подставлять текущий хост.

...

Про legacy я вообще молчу :) Тут я итак знаю, что с моим движком ничто не сравнится, он все 10 лет затачивался под интеграцию с уже имеющимися разнокалиберными проектами. Так что я рассматриваю только варианты проектов «с нуля».

Тогда в чём смысл пытаться записывать это одной сторокой?

Пытаюсь написать как можно более компактный код. Напомню, что цепочка пошла, начиная с Что плохого в Django? (комментарий)

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

Тогда если всего этого не нужно он не берет django , а использует библиотеки или микрофреймворки

если бы...

google://Replacing+Django+ORM

About 1,440,000 results

занимаюсь созданием этого теста в очень фоновом режиме

Может стоит выложить на Github? Я добавлю тесты пары фреймворков.

Прочитал тред по диаганали, насколько я понял, то что вы спросили называется `Dynamic Filtering` (по ссылке пример использования - https://docs.djangoproject.com/en/dev/topics/class-based-views/#dynamic-filte... ) - смотреть на self.args и self.kwargs.

Но Class Based Views это вовсе не о том, как сократить код. На каком то этапе, наоборот, кода с CBV будет больше и он будет длиннее, появятся всякие экзотические вещи вроде SomeFooBarListView(ListView)...

С другой стороны, теперь вьюхи можно писать в классах -> можно наследоваться и переопределить контекст. Это дает большой плюс, когда надо сделать вьюху очень похожую, на то что уже написано, но что-то чуть-чуть изменить. Наследуемся, переопределяем контекст, вуаля - все готово. Для крупных проектов, где к примеру, будет RESTfull часть, полноценный сайт, мобильная версия, еще JSON-ом что-то отдавать - CBV будет не лишней.

s/диаганали/диагонали
facepalm.py

Может стоит выложить на Github?

Положил на https://bitbucket.org/Balancer/frameworksbench

Но это пока ещё совсем не для практики какой-то, так, проба концепта. Даже задание чётко не сформировано, планирую два, как минимум — «страница сайта» и «топик форума», при чём отдача контента — для бенчмарка, но кроме неё, для оценки лёгкости работы с формами и модификацией контента, ещё добавление комментариев на страницу и сообщений на форум. Думаю, для простоты, анонимных.

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

Так что выложил, вот, первые скелеты :)

Вполне возможно, что и с целью будущей миграции на них.

Борщ не держит?

Вполне возможно, что и с целью будущей миграции на них.

Борщ не держит?

По скорости полный вариант под ним без всякиз оптимизаций и кеширований уступает в 1,5-3 раза урезанному варианту на Django (17..20 rps vs 40..50 у Django на 10 потоках), что в наше время не принципиально, плюс всегда можно для готового решения включить несколько уровней кеширования, вплоть до чисто статического. А начиная от всевозможных memcached и автоматической сборки россыпи сотни мелких файлов в один монолитный. Ну и оптимизацией по скорости я уже года два не занимался, можно как-нибудь попрофилировать будет. Так что с нагрузками вопросов нет :) (Да и приводил раньше цифры нагрузок некоторых реальных проектов).

Но кто знает, что будет на рынке хостингов с PHP, скажем, через 10 лет? :)

И, вдруг, просто что-то есть удобнее, с чем я просто ещё не знаком?

слепой ненавистник PHP? :)

По сравнению с @ deb'ом это просто поклонник PHP :)
Он же его не поносит в каждом сообщении,...

Вообще-то это она :-).

Неужели разница так фатальна?

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

Ишшо один фанатик. Да откуда ж вы такие берётесь?

…

Проходите, гражданин, тут еды нет.

Причем тут фанатизм? Давай сравнивать объективно.

Причем тут фанатизм?

Фанатизм — в форме твоего комментария.

Давай сравнивать объективно.

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

Кстати, Django в моделях поддерживает join'ы или придётся городить огород с составным объектами? Например, когда большая таблица разбивается на собственно таблицу с уникальными данными и таблицу с кешируемыми вычисляемыми данными для того же объекта?

Это будет частью теста, но, понятно, что для фреймворков, не поддерживающих составные таблицы в бэкендах придётся делать отдельную сущность — кеширующий объект и методы для заворачивания на него запросов…

Фанатизм — в форме твоего комментария.

Я тоже самое могу сказать про твой комментарий.

Кстати, Django в моделях поддерживает join'ы или придётся городить огород с составным объектами? Например, когда большая таблица разбивается на собственно таблицу с уникальными данными и таблицу с кешируемыми вычисляемыми данными для того же объекта?

Конечно поддерживает, но в несколько непривычном виде. Конкретно для твоей задачи, имхо, самым гармоничным решением будет переопределение model manager`а.

Я тоже самое могу сказать про твой комментарий.

Интересно, про какой? «Неужели разница так фатальна?» Ты контекст его смотрел? «С учетом синтаксиса php , на нем противопоказано вообще писать ORM»

Что там с чьим фанатизмом?

Конечно поддерживает, но в несколько непривычном виде. Конкретно для твоей задачи, имхо, самым гармоничным решением будет переопределение model manager`а.

Пример можно? Скажем, для варианта:

table: posts
fields: int pid, text bbcode

table: posts_cached
fields: int pid, text html

post.html = bbcode_parse(post.bbcode)

?

https://docs.djangoproject.com/en/1.3/topics/db/managers/

SQL-запросы в модели?? o_O

Или я не там смотрю?

SQL-запросы в модели?? o_O

Ну это просто пример model manager`а, дает представление о том, что это вообще такое.

Зачем здесь вторая таблица? Может есть какойто более IRL пример?

Может есть какойто более IRL пример?

IRL у меня на форуме даже три таблицы :)

Одна — уникальные данные, требующие регулярного бэкапа. Собственно, сорцы сообщений, авторы, даты, настройки и т.п.

Вторая — вычисляемые данные, которые можно не бэкапить, которые можно вычислить по другим таблицам, но которые в полном объёме нужны для работы. Скажем, деревья ответов, оценки и рейтинги и т.п.

Третья — просто кешируемые данные, которые можно грохнуть в любой момент, например, перед модификациями для введения новых полей.

Всё в одну нельзя — и бэкап ежедневный будет не 5..10 минут длиться, а все 15..30, и модификация таблицы будет приводить к 40..60 минутам шатдауна сервера.

Можно джойнить если это будет отдельная модель с FKey на Post.
Вокруг этого можно сделать произвольных сахар если ты напишешь как ты это хочешь использовать в коде, но не думаю что тебе понравится код самого сахара :)

Искаропки моделей над несколькими таблицами нет.