Здравствуйте, neFormal, Вы писали:
N>>Из плохого — в основном все проблемы с админкой. Она недостаточно гибкая в плане модификации и интернационализации. Нельзя прикрутить полностью другой бэкэнд для аутентификации и авторизации пользователей.
F>а почему свою не написать?. какие неоспоримые преимущества есть у дефолтной админки?.
Замучишься свою писать. Просто укажу на некоторые подводные камни:
— автогенерация форм (т.е. нужно делать интроспекцию классов и для полей генерировать соответствующие контролы), особенно много заморочек с ManyToManyField;
— валидация данных (это не сложно, но тоже нужно потратить время);
— аудит работы с данными, история изменений (опять интроспекция и какое-то время на реализацию);
— аутентификация и авторизация пользователей (нехилый пласт работ);
— сортировки, поиски и фильтрации (здесь и во встроенной админке не все хорошо, но какой-то базовый минимум все-таки предоставляется).
Т.е. чтобы повторить админку Джанго, придется сильно постараться и потратить немало времени. Конечно, если админка минимальная, и модели простые, то задача сильно упрощается. Если же нет цели вообще использовать админку, тогда и говорить не о чем — в некоторых случаях (например, при разработке вики-подобных сайтов) админка вообще не нужна.
F>а всё ли хорошо с i18n?. легко ли оно делается?.
Достаточно легко в линуксе и юникс-подобных средах. Просто для интернационализации используется стандартная unix-функция gettext(), и под виндами надо ставить какие-то библиотеки, чтобы работали команды makemessages и compilemessages. Возможно, после релиза Django 1.0 все стало попроще, но я не знаю — виндой у нас никто не пользуется.
Если не касаться админки, то интернационализация делается легким движением руки — просто где надо расставляешь теги в шаблонах и вызовы функций в коде. В документации все сказано, и приведены примеры.
Здравствуйте, Cyberax, Вы писали:
C>Просто когда будет написаный сайт — переписывать его уже хотеться не будет Вот и хочется заранее узнать где подстелить соломку.
Ну на своей практике я еще не разу не встречался, чтобы пришлось переписывать сайт на Django с нуля (единственный случай, когда пришлось реально переписать очень много кода, и то в основном связанный с админкой — при переходе на версию 1.0). Принципы DRY, которым следует Django, и очень мощная поддержка юнит-тестирования очень серьезно облегчают рефакторинг, и заставляют сразу писать качественный код.
Однако, если спустится с небес на землю, то отпишу какие примерно проблемы могут возникнуть в процессе работы над сайтом, которые могут реально заставить переписать его с нуля:
Производительность. На самом деле Django очень high-scaled фреймворк — то, что на нем крутится New Your Times и блог Медведева с реально ощутимым количеством хитов, о чем-нибудь да говорит. Но если все-таки писать что-то типа Twitter-а или Google-а, то надо тщательно проработь архитектуру. Python может стать очень узким местом, и придется либо жертвовать памятью и делать кэширование всего и вся, плюс внедрять load-balancing сервера, либо переписывать с нуля на C++ c FastCGI. Возможно, Java-based фреймворки тоже могут с этим помочь, но здесь я немного отстал от жизни — в свое время (java1.4) все было еще совершенно не блеск.
AJAX-based сайты. Аякс прикручивается к чему угодно, спору нет. Однако стоимость этого прикручивания может взлететь очень высоко, если сайт будет чисто AJAX-based (как GMail). Ну эту тему мы уже вроде полностью раскрыли в ветке.
Интеграция с различными сервисами. Для примера возьму Kerberos-аутентификацию. В Python и Django встроенной поддержки кербероса нет, надо либо прикручивать через ctypes, либо искать внешние модули. В админке Django вообще все плохо с аутентификацией. В то же время в той же Java есть JAAS. Так что если предполагается тесная интеграция с внешними сервисами, надо этот вопрос сразу рассматривать.
Может есть что-то еще, сразу не скажу. Вообще, конечно, инструмент, а тем более фреймворк надо выбирать в соответствии с задачей. Однако в случае Python-а и Django нет ничего такого уж совсем запущенного, что на них нельзя было бы сделать. Но в принципе, это касается и всех других фреймворках. Правда у некоторых есть реально мозоли, которые надо знать заранее — например, огромное время холодного старта ASP.NET приложений. В Django ничего такого особо замечено не было. Так что глаза боятся, а руки делают — попробуйте, может вам и понравится
Здравствуйте, jarlaxle, Вы писали:
>>Вообще, я планирую написать в ближайшее время сравнительный обзор всех современных "Agile" фреймворков: Django, RoR, Grails, Perl Catalyst, но пока не могу изыскать времени. Там бы я рассмотрел все плюсы и минусы.
J>Написали? Можно ссылку?
К сожалению, еще нет. Здесь все не так просто — мне сначала надо определить метрики для сравнения, потом написать полноценные приложения на всем этом, а потом уже сравнивать по ранее введенным метрикам. Субъективные анализы мне совершенно не нужны, т.к. зачастую вопрос выбора фреймворка — это деньги. Чем быстрее и эффективнее позволяет фреймворк разрабатывать сайты, тем больше денег принесет его использование. А то, что Rails реально крутой язык, на котором можно сворганить свой DSL и предоставить заказчику разрабатывать программы на высоком уровне, меня совершенно не волнует, т.к. такого рода задачи возникают ну реально редко
Здравствуйте, neFormal, Вы писали:
C>>Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно? F>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку..
Если тебе придётся писать в несколько баз одновременно => привет распределённым транзакциям!
C>>Это как раз удобная фича — в случае чего можно при необходимости хак вставить. F>*поперхнулся*
Зато про войну.
Здравствуйте, Cyberax, Вы писали:
C>Кто-нибудь активно использовал сабж? Какие отзывы?
C>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого
C>PS: если кому-то в Киеве интересно поработать на проекте с Python+Django — обращайтесь ко мне.
Используем. Имеем несколько сервисов на нем. Готовыи к выходу следующий. Минус по сути один — как и при использовании любого фреймворка присутсвует ощущение что тобой упраляет нивидимая рука. Иногда это мещает.
Здравствуйте, Cyberax, Вы писали:
C>Кто-нибудь активно использовал сабж? Какие отзывы?
вроде, Roman Odaisky пользует..
я тоже буду активно использовать через пару недель, когда передам работу над текущим проектом в другие заботливые руки..
C>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого
первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
кроме того:
— питон 3к не поддерживается
— не очень изящно выглядят куски кода в шаблонах страниц (хотя мне всё равно, я в танке)
— еще не всё переведено на http://cargo.caml.ru/djangobook/
Здравствуйте, neFormal, Вы писали:
F>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
А поделись типичной задачкой где надо несколько баз сразу иметь?
Здравствуйте, neFormal, Вы писали:
C>>Кто-нибудь активно использовал сабж? Какие отзывы? F>вроде, Roman Odaisky пользует..
Спасибо, попинаю его
C>>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого F>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно?
F>кроме того: F>- питон 3к не поддерживается
Это я смотрел, там просто по мелочам много чего. Фигня.
F>- не очень изящно выглядят куски кода в шаблонах страниц (хотя мне всё равно, я в танке)
Это как раз удобная фича — в случае чего можно при необходимости хак вставить.
F>- еще не всё переведено на http://cargo.caml.ru/djangobook/
Пофиг, все в команде на английском читают.
Здравствуйте, Курилка, Вы писали:
F>>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался.. К>А поделись типичной задачкой где надо несколько баз сразу иметь?
1. я хочу, чтобы аппликухи из джанги писались в разные базы (не физические машины, а database в СУБД), т.к. не хочу хлама из таблиц в одной базе..
2. я подозреваю, что будет слишком много обращений к базе, поэтому предполагаю разносить данные по нескольким машинкам.. ну, кроме того, я не углублялся пока в эту тему, возможно можно будет и проще поступить..
3. ну и репликация БД, которая мне вроде бы не нужна
хотя с другой стороны.. у меня будут накапливаться неактивные объекты, которые надо будет складывать в "холодильник".. вполне возможно, что "холодильник" будет находиться на отдельной неторопливой машинке..
Здравствуйте, Cyberax, Вы писали:
C>>>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого F>>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался.. C>Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно?
нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку..
C>Это как раз удобная фича — в случае чего можно при необходимости хак вставить.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Cyberax, Вы писали:
C>>>>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого F>>>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался.. C>>Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно?
F>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку..
Репликация? Так есть приложения для MySQL с репликами. Уверен, можно и под другие бекэнды адаптировать.
Здравствуйте, Daevaorn, Вы писали:
F>>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку.. D>Репликация? Так есть приложения для MySQL с репликами. Уверен, можно и под другие бекэнды адаптировать.
я пока не буду строить из себя профи ( ), но из того, что я начитал в интернетах: репликация — это не то, чего я хочу..
я хочу, чтобы часть клиентов обрабатывалось с одной БД (физической железки), часть с другой, а остальные с третьей.. нагрузка, видимо будет зависеть от того, насколько косячно я спроектирую БД..
PS: а под джангу есть несколько "патчей" для прикручивания репликации и просто для поддержки нескольких баз.. у них на сайте есть линки(местами нерабочие)..
PPS: кстати, можно в некоторых случаях разные группы данных хранить в разных СУБД.. например, в mysql и oracle одновременно.. mysql под сайт/форум/етк, а oracle для каких нибудь промышленных данных, которые пишутся, например, со станков.. и ко всему этому есть web-доступ
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Daevaorn, Вы писали:
F>>>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку.. D>>Репликация? Так есть приложения для MySQL с репликами. Уверен, можно и под другие бекэнды адаптировать.
F>я пока не буду строить из себя профи ( ), но из того, что я начитал в интернетах: репликация — это не то, чего я хочу.. F>я хочу, чтобы часть клиентов обрабатывалось с одной БД (физической железки), часть с другой, а остальные с третьей.. нагрузка, видимо будет зависеть от того, насколько косячно я спроектирую БД..
Да. Это называет шардинг. Репликация по простому — это когда дынные дублируются на разных нодах, а шардинг когда разделяются.
F>PS: а под джангу есть несколько "патчей" для прикручивания репликации и просто для поддержки нескольких баз.. у них на сайте есть линки(местами нерабочие).. F>PPS: кстати, можно в некоторых случаях разные группы данных хранить в разных СУБД.. например, в mysql и oracle одновременно.. mysql под сайт/форум/етк, а oracle для каких нибудь промышленных данных, которые пишутся, например, со станков.. и ко всему этому есть web-доступ
Для репликаций есть production ready приложение — mysql_replicated.
Здравствуйте, Daevaorn, Вы писали:
D>Здравствуйте, neFormal, Вы писали:
F>>я пока не буду строить из себя профи ( ), но из того, что я начитал в интернетах: репликация — это не то, чего я хочу.. F>>я хочу, чтобы часть клиентов обрабатывалось с одной БД (физической железки), часть с другой, а остальные с третьей.. нагрузка, видимо будет зависеть от того, насколько косячно я спроектирую БД..
D>Да. Это называет шардинг. Репликация по простому — это когда дынные дублируются на разных нодах, а шардинг когда разделяются.
Точнее именно та схема которую вы опислаи больше подходит как раз под репликации. Когда просто есть несколько баз, но них консистентный массив данных всей системы.
Здравствуйте, neFormal, Вы писали:
F>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
Единственный правильный вариант прикручивать несколько баз к одному приложению — это все-таки работать с репликами. Рассмотрим один из вариантов работы с БД некоего универсального веб-приложения: Клиент читает данные. Если они разнесены по нескольким базам, то необходимо передать нужные запросы в базы, дождаться пока они все выполнятся, и потом собрать и показать клиенту.
Overhead на ожидание зачастую сводит на ноль все преимущества разнесения данных на разные базы. Я не говорю уж о том, что не будет выполняться никакой оптимизации.
Клиент модифицирует данные. Стандартная практика в любых серьезных веб-приложениях (в Django-админке это встроено) — это вести аудит операций с данными. Если все разнесено по разным базам, то необходимо вести аудит либо в каждой базе, либо делать единый аудит, и тогда тоже придется как-то делать очередь запросов, чтобы аудит был корректен. Обычно данные все-таки имеют взаимосвязи, поэтому последний вариант предпочтительнее в большинстве случаев. Что опять-таки не добавляет плюсов в копилку разнесения данных по разным БД.
Однако, конечно, репликации не всегда применимы. Тогда я вижу только два варианта: Для каждой базы использовать свое приложение, а разруливать фронт-енд веб-сервером.
Использовать Data Grid. Но это уже совершенно другой отдельный вопрос, и здесь всякие питоны с джангами уже совершенно не удел. Welcome to Enterprise World!
Могу еще порекомендовать ссылку на Django book: Chapter 20: Deploying Django. Там есть раздел "Scale", изучите его, может найдете для себя что-то интересное.
F>кроме того: F>- питон 3к не поддерживается
Как минимум в py3k поменяли все строки полностью на юникодные. Это затрагивает очень много кода в Django, т.к. мощная работа со строками — неотъемлимая часть любого RESTful фреймворка. Также были некоторые изменения в модели метапрограммирования, и это тоже накладывает свой отпечаток.
Так что как обычно, сначала будет переход на 2.6 (возможно к началу следующего года уже все будет готово), и только потом на 3k (это скорей всего 2010 и позже). Хотя в последние годы работа над Django очень убыстрилась, так что возможно все будет готово быстрее.
F>- не очень изящно выглядят куски кода в шаблонах страниц (хотя мне всё равно, я в танке)
Код в шаблоны вообще нельзя встраивать, а то что есть — это вынужденный минимум, чтобы обеспечить хоть какую-то манипуляцию над данными в шаблонах.
Никто, конечно, не мешает писать свои фильтры и теги. Ну или на крайний случай, прикрутить другой template-движок.
Хотя лично я целиком поддерживаю разработчиков Django, что они сделали такой убогий template-engine — если бы он был побогаче (как, например, Genshi), то у разработчиков был бы большой соблазн нарушить MVT паттерн, и в итоге шаблоны превратились бы в PHP-лапшу с синтаксисом питона.
F>- еще не всё переведено на http://cargo.caml.ru/djangobook/
Сейчас встроенная документация в Django очень и очень крутая — в принципе, ничего шикарнее я в своей жизни не видел. Django book уже нужен только начинающим.
Здравствуйте, Cyberax, Вы писали:
C>Кто-нибудь активно использовал сабж? Какие отзывы?
Активно работаем с Django уже года два.
Из хорошего — все круто Если не лезть в админку, то код пишется на ура. ORM, интернационализация, шаблоны, юнит-тестирование — все красиво и приятно.
Из плохого — в основном все проблемы с админкой. Она недостаточно гибкая в плане модификации и интернационализации. Нельзя прикрутить полностью другой бэкэнд для аутентификации и авторизации пользователей.
Есть конечно что-то еще, но прям сейчас в голову не приходит. Может при ответах на наводящие вопросы скажу больше.
Вообще, я планирую написать в ближайшее время сравнительный обзор всех современных "Agile" фреймворков: Django, RoR, Grails, Perl Catalyst, но пока не могу изыскать времени. Там бы я рассмотрел все плюсы и минусы.
Здравствуйте, Nuald, Вы писали:
N>Из плохого — в основном все проблемы с админкой. Она недостаточно гибкая в плане модификации и интернационализации. Нельзя прикрутить полностью другой бэкэнд для аутентификации и авторизации пользователей.
а почему свою не написать?. какие неоспоримые преимущества есть у дефолтной админки?.
N>Есть конечно что-то еще, но прям сейчас в голову не приходит. Может при ответах на наводящие вопросы скажу больше.
Здравствуйте, Nuald, Вы писали:
N>Т.е. чтобы повторить админку Джанго, придется сильно постараться и потратить немало времени. Конечно, если админка минимальная, и модели простые, то задача сильно упрощается. Если же нет цели вообще использовать админку, тогда и говорить не о чем — в некоторых случаях (например, при разработке вики-подобных сайтов) админка вообще не нужна.
А можно ли сделать так, чтобы можно было делать для групп дополнительные уровни?
Т.е. у нас будет 10 клиентов, и у каждого клиента свой набор групп. Т.е. пользователь из группы "admin" у клиента "А" не должен быть админом у клиента "Б".
Я так посмотрел — надо расширять класс Group. Можно ли это сделать?
N>Если не касаться админки, то интернационализация делается легким движением руки — просто где надо расставляешь теги в шаблонах и вызовы функций в коде. В документации все сказано, и приведены примеры.
Ага, в админке интернационализация глючная. Например, поддерживается всего одна форма множественного числа (в русском их три).
Здравствуйте, Cyberax, Вы писали:
C>А можно ли сделать так, чтобы можно было делать для групп дополнительные уровни? C>Т.е. у нас будет 10 клиентов, и у каждого клиента свой набор групп. Т.е. пользователь из группы "admin" у клиента "А" не должен быть админом у клиента "Б". C>Я так посмотрел — надо расширять класс Group. Можно ли это сделать?
Расширить можно любой класс, но будет ли это работать — другой вопрос. Мы решали такого рода задачи другим способом: Отнаследовали от встроенного класса admin собственные классы, каждый из которых реализовывал собственную логику админского сайта.
URLConf переписали таким образом, чтобы в зависимости от группы пользователя или его наименования шел редирект на собственную админку.
Зарегистрировали модели в нужных админках.
В вашем случае, если вы будете переписывать группы, также придется наследоваться от встроенного класса admin, и переписывать URLConf-ы, т.к. зарегистрировать другой класс для групп во встроенной админке вряд ли получится.
Еще как вариант, можно добавить профили для пользователей, и там ввести собственную систему групп. Но опять-таки придется делать собственные классы для админских сайтов.
Я немного эту тему осветил у себя в блоге — Adding security features to Django projects, однако не упоминал там модификацию админки. Если есть желание узнать подробности о вышеприведенном механизме, могу накидать статью.
Здравствуйте, Nuald, Вы писали:
N>В вашем случае, если вы будете переписывать группы, также придется наследоваться от встроенного класса admin, и переписывать URLConf-ы, т.к. зарегистрировать другой класс для групп во встроенной админке вряд ли получится.
Ну есть ещё рабоче-крестьянский метод — импортировать админку в проект и там напрямую поменять. Только вот некрасиво.
N>Еще как вариант, можно добавить профили для пользователей, и там ввести собственную систему групп. Но опять-таки придется делать собственные классы для админских сайтов.
Хочется по минимуму обойтись текущей админкой — она только для администраторов сайта нужна будет, для пользователей всё равно свой интерфейс рисовать будем.
N>Я немного эту тему осветил у себя в блоге — Adding security features to Django projects, однако не упоминал там модификацию админки. Если есть желание узнать подробности о вышеприведенном механизме, могу накидать статью.
Как пользоваться security более-менее понятно...
Кстати, а есть в Django аналог Spring WebFlow? Т.е. диалог из нескольких страниц, наподобии wizard'а, чтоб ещё нормально кнопку back поддерживал?
Кстати, а что с Ajax'ом? Есть ли прозрачный form submit и обновление страницы (т.е. чтоб оно прозрачно присылало изменённые части DOM-дерева)?
Здравствуйте, Cyberax, Вы писали:
C>Кстати, а есть в Django аналог Spring WebFlow? Т.е. диалог из нескольких страниц, наподобии wizard'а, чтоб ещё нормально кнопку back поддерживал?
Есть Form wizard. Сам не пользовался, так что ничего сказать не могу.
C>Кстати, а что с Ajax'ом? Есть ли прозрачный form submit и обновление страницы (т.е. чтоб оно прозрачно присылало изменённые части DOM-дерева)?
Встроенной поддержки аякса практически нет (есть только необходимый минимум — например для ManyToManyField). Мы юзаем jQuery. В той же статье я отписывал как его юзать.
Здравствуйте, Nuald, Вы писали:
C>>Кстати, а есть в Django аналог Spring WebFlow? Т.е. диалог из нескольких страниц, наподобии wizard'а, чтоб ещё нормально кнопку back поддерживал? N>Есть Form wizard. Сам не пользовался, так что ничего сказать не могу.
Угу. В принципе, пойдёт для сельской местности...
C>>Кстати, а что с Ajax'ом? Есть ли прозрачный form submit и обновление страницы (т.е. чтоб оно прозрачно присылало изменённые части DOM-дерева)? N>Встроенной поддержки аякса практически нет (есть только необходимый минимум — например для ManyToManyField). Мы юзаем jQuery. В той же статье я отписывал как его юзать.
Вот я и спрашиваю. Как-то слишком много ручного труда получается Ну ладно, Ajax пока у нас не приоритетный.
Здравствуйте, Cyberax, Вы писали:
N>>Встроенной поддержки аякса практически нет (есть только необходимый минимум — например для ManyToManyField). Мы юзаем jQuery. В той же статье я отписывал как его юзать. C>Вот я и спрашиваю. Как-то слишком много ручного труда получается Ну ладно, Ajax пока у нас не приоритетный.
В принципе, грамотно написанные AJAX-компоненты не особо трудно прикручиваются. У нас не было проблем ни с MarkItUp!, ни с TinyMCE, ни с компонентами от YUI. Конечно, какой-то бэкенд писать надо, но на питоне с мощными возможностями джанго это не особо трудно.
C>PS: а Pylons, случайно, не использовали?
Слышал, но не использовал. В моих глазах он не достаточно Agile В частности нет автоматически генерируемой админки или даже просто форм, что заставляет писать лишний код. Условно я бы наверное его приравнял к Spring-у.
Здравствуйте, Nuald, Вы писали:
C>>Вот я и спрашиваю. Как-то слишком много ручного труда получается Ну ладно, Ajax пока у нас не приоритетный. N>В принципе, грамотно написанные AJAX-компоненты не особо трудно прикручиваются. У нас не было проблем ни с MarkItUp!, ни с TinyMCE, ни с компонентами от YUI. Конечно, какой-то бэкенд писать надо, но на питоне с мощными возможностями джанго это не особо трудно.
Это не AJAX, это просто контролы.
Скажем, в Wicket'е я можно сделать AJAXовый submit формы буквально двумя строчками кода. То есть, после нажатия "submit" не будет делаться переход между страницами, а просто придут изменившиеся части DOM-дерева.
Как такое сделать в Django мне пока даже не понятно.
C>>PS: а Pylons, случайно, не использовали? N>Слышал, но не использовал. В моих глазах он не достаточно Agile В частности нет автоматически генерируемой админки или даже просто форм, что заставляет писать лишний код. Условно я бы наверное его приравнял к Spring-у.
Spring мне как раз нравится — там можно что угодно к чему угодно подключать. Но да, согласен, Pylons уж очень минималистичный. Правда SQLAlchemy+Genshi весьма привлекательно выглядят. В Django уж очень разметка какая-то невнятная.
Здравствуйте, Cyberax, Вы писали:
C>Скажем, в Wicket'е я можно сделать AJAXовый submit формы буквально двумя строчками кода. То есть, после нажатия "submit" не будет делаться переход между страницами, а просто придут изменившиеся части DOM-дерева. C>Как такое сделать в Django мне пока даже не понятно.
Можно использовать стандартный функционал форм в Django: В коде создать форму (вручную или автоматически сгенерировать из модели, как это делается в админке).
На форму прикрутить html-шаблон (включающую ту часть DOM-дерева которую вы хотите обновлять).
В шаблоне уже приделать нужную логику.
В принципе, через jQuery просто вешается обработчик на click кнопки, который делает сабмит, а бэкэндом уже возвращается новый html (или что-то еще) для обновляемой части шаблона. Можно уложиться и в две строчки, если использовать всю мощь метапрограммирования питона и jquery
Вообще на схожую тему у меня были переговоры с разработчиками Django, и они объяснили мне свою позицию — если редко используемая фича прикручивается к веб-приложению на Django без модификации самого ядра Django, то внедрять эту фичу в ядро они не будут. Надо постараться, чтобы уломать их что-то включить в фреймворк.
N>>Слышал, но не использовал. В моих глазах он не достаточно Agile В частности нет автоматически генерируемой админки или даже просто форм, что заставляет писать лишний код. Условно я бы наверное его приравнял к Spring-у. C>Spring мне как раз нравится — там можно что угодно к чему угодно подключать. Но да, согласен, Pylons уж очень минималистичный. Правда SQLAlchemy+Genshi весьма привлекательно выглядят. В Django уж очень разметка какая-то невнятная.
Genshi как раз к Django и прикручивается — intergrate mako and genshi with django
А вот со всем остальным могут быть проблемы. С другой стороны, как раз к ORM Django почти претензий и нет.
Здравствуйте, Nuald, Вы писали:
N>В принципе, через jQuery просто вешается обработчик на click кнопки, который делает сабмит, а бэкэндом уже возвращается новый html (или что-то еще) для обновляемой части шаблона. Можно уложиться и в две строчки, если использовать всю мощь метапрограммирования питона и jquery
Там далеко не всё так просто, как ты думаешь Я когда-то писал это всё руками (ещё до изобретения слова AJAX) — куча всяких интересных вещей вылезает.
Просто тут без реальной компонентной ориентации сложно что-то нормальное сделать. А компонентным Django не сделать.
N>Вообще на схожую тему у меня были переговоры с разработчиками Django, и они объяснили мне свою позицию — если редко используемая фича прикручивается к веб-приложению на Django без модификации самого ядра Django, то внедрять эту фичу в ядро они не будут. Надо постараться, чтобы уломать их что-то включить в фреймворк.
Если бы оно было, то использовалось бы не так уж и редко. По крайней мере, валидация формы "на лету" с помощью AJAX — это сейчас must have.
C>>Spring мне как раз нравится — там можно что угодно к чему угодно подключать. Но да, согласен, Pylons уж очень минималистичный. Правда SQLAlchemy+Genshi весьма привлекательно выглядят. В Django уж очень разметка какая-то невнятная. N>Genshi как раз к Django и прикручивается — intergrate mako and genshi with django
Только вот кроме этого сниппета я ничего другого не нашёл
N>А вот со всем остальным могут быть проблемы. С другой стороны, как раз к ORM Django почти претензий и нет.
Я привык к возможностям Hibernate, до них Django ORM весьма далеко. А вот SQLAlchemy весьма близка.
Здравствуйте, Cyberax, Вы писали:
N>>В принципе, через jQuery просто вешается обработчик на click кнопки, который делает сабмит, а бэкэндом уже возвращается новый html (или что-то еще) для обновляемой части шаблона. Можно уложиться и в две строчки, если использовать всю мощь метапрограммирования питона и jquery C>Там далеко не всё так просто, как ты думаешь Я когда-то писал это всё руками (ещё до изобретения слова AJAX) — куча всяких интересных вещей вылезает.
Гм, а можно поподробнее? То, что я отписал (валидацию через аякс в джанго), я делал и никаких особо проблем не нашел. jQuery спасает от многих низкоуровневых вещей, типа ручной поддержки кучи браузеров. А вроде других проблем я не вижу.
C>Просто тут без реальной компонентной ориентации сложно что-то нормальное сделать. А компонентным Django не сделать.
Э-э-э, что-то я не особо понял Джанго очень даже из себя компонентный, и как раз работа с компонентами у него идет на ура. Но есть, конечно, кое-где неприятная сильная связанность — типа той аутентификации, или неменяемого ORM.
N>>Вообще на схожую тему у меня были переговоры с разработчиками Django, и они объяснили мне свою позицию — если редко используемая фича прикручивается к веб-приложению на Django без модификации самого ядра Django, то внедрять эту фичу в ядро они не будут. Надо постараться, чтобы уломать их что-то включить в фреймворк. C>Если бы оно было, то использовалось бы не так уж и редко. По крайней мере, валидация формы "на лету" с помощью AJAX — это сейчас must have.
Во-первых, для этого не нужно менять ядро. Есть решения, которые легко внедряются — Django generic AJAX form validation.
Во-вторых, насчет must-have я бы особо не торопился. Возможно, в вашем сегменте это и актуально, а для западного рынка скорость клиентской и серверной валидации практически идентичны. А зачастую AJAX-валидация и не нужна, т.к. используются хитроумные яваскрипт-компоненты (типа поле ввода, которое поддерживает только числа)
N>>А вот со всем остальным могут быть проблемы. С другой стороны, как раз к ORM Django почти претензий и нет. C>Я привык к возможностям Hibernate, до них Django ORM весьма далеко. А вот SQLAlchemy весьма близка.
Django не серебряная пуля, спора нет. Иногда я его искренне ненавижу. Но особо выбора пока и нет — у других фреймворков есть другие недостататки, которые в моих глазах перевешивают достоинства. Хочу посмотреть в сторону Grails, но пока особо не было времени.
Здравствуйте, Nuald, Вы писали:
C>>Там далеко не всё так просто, как ты думаешь Я когда-то писал это всё руками (ещё до изобретения слова AJAX) — куча всяких интересных вещей вылезает. N>Гм, а можно поподробнее? То, что я отписал (валидацию через аякс в джанго), я делал и никаких особо проблем не нашел. jQuery спасает от многих низкоуровневых вещей, типа ручной поддержки кучи браузеров. А вроде других проблем я не вижу.
Для примера смотри сюда: http://www.wicketstuff.org/wicket13/ajax/ (к примеру, вот сюда: http://www.wicketstuff.org/wicket13/ajax/todo-list ). Причём AJAX там обычно добавляется без единой строчки JavaScript'а, просто к компонентам подключается AjaxBehaviour и усё.
C>>Просто тут без реальной компонентной ориентации сложно что-то нормальное сделать. А компонентным Django не сделать. N>Э-э-э, что-то я не особо понял Джанго очень даже из себя компонентный, и как раз работа с компонентами у него идет на ура. Но есть, конечно, кое-где неприятная сильная связанность — типа той аутентификации, или неменяемого ORM.
Я про другую компонентость, когда страница представляет из себя набор компонентов, для которых фреймворк обеспечивает события, lifecycle и т.п.
Кое-что можно эмулировать, но целиком аналог Wicket или ASP.NET сделать не получится.
C>>Если бы оно было, то использовалось бы не так уж и редко. По крайней мере, валидация формы "на лету" с помощью AJAX — это сейчас must have. N>Во-первых, для этого не нужно менять ядро. Есть решения, которые легко внедряются — Django generic AJAX form validation.
Это всё полурешения...
N>Во-вторых, насчет must-have я бы особо не торопился. Возможно, в вашем сегменте это и актуально, а для западного рынка скорость клиентской и серверной валидации практически идентичны. А зачастую AJAX-валидация и не нужна, т.к. используются хитроумные яваскрипт-компоненты (типа поле ввода, которое поддерживает только числа)
Фичи типа красивых переходов между страницами, всяких там AJAX-овых login box'ов — очень популярны. И работают реально намного быстрее полной перерисовки, если правильно делать.
C>>Я привык к возможностям Hibernate, до них Django ORM весьма далеко. А вот SQLAlchemy весьма близка. N>Django не серебряная пуля, спора нет. Иногда я его искренне ненавижу. Но особо выбора пока и нет — у других фреймворков есть другие недостататки, которые в моих глазах перевешивают достоинства. Хочу посмотреть в сторону Grails, но пока особо не было времени.
Я смотрел Grails. Как-то не вставило совсем — активные записи реализованы поверх Hibernate и смотрятся совершенно искусственно и т.п.
Я хотел бы немного разъяснить свою позицию, и направить общение в более конструктивное русло, а то получается уже какой-то флейм: Django — не серебряная пуля, в нем есть свои недостатки и достоинства. Защищать, а тем более восхвалять его не вижу смысла.
Особо упирать на аякс я также не вижу смысла. Если делать сайт для конкретного заказчика под конкретные задачи, скажем, в корпоративном секторе, то да — там можно поставить свои условия, вплоть до того, что все пользователи сайта должны пользоваться исключительно FF 3 с включенным яваскриптом. Однако там, где я работаю, мы ориентируемся на максимальный охват пользователей, включая тех, кто выключает яваскрипт. Аякс конечно мы используем, но лишь как приятное дополнение, и критичной функциональности на него не вешаем.
Я могу ответить на вопросы, как сделать то или иное в Django, или что это сделать нельзя, но сравнение с другими фреймворками — это уже совершенно другая тема. На нее тоже можно поговорить, но лучше в другой ветке.
И несколько слов про мое видение работы с Django.
У Django есть одно несомненное преимущество — сайты на нем пишутся очень быстро. Например, простейшую вики с тегами, поиском, автолинками, минимальной поддержкой форматирования, плюс полностью покрытую юнит-тестами может написать разработчик средней квалификации за один рабочий день. Я не говорю про высококвалифицированных разработчиков — им не важно на чем писать, они напишут на чем угодно очень быстро. Порог вхождения в Python и Django достаточно низкий, и научиться на них работать не займет много времени. Плюс к тому же Django провоцирует на написание более или менее качественного кода (в этом плане использование Genshi только все испортит, т.к. шаблоны на ней позволяют слишком много, вплоть до встраивания методов в шаблоны).
Но, конечно, у Django есть свои недостатки, которые более или менее раскрыты в этой ветке. И в этом плане, разработка на Django очень подходит для прототипирования — быстренько пишется сайт, согласуется с клиентом, кое-что правится и все — альфа версия готова. Теперь уже разработчик решает — использовать ли Django дальше, или переходить на другую, более качественную систему — ту же связку Spring + Hibernate + Velocity + Wicket. Конечно, есть задачи, для которых Django вообще никак не подходит, даже для прототипирования — те же самые Ajax-based приложения. Здесь уже надо смотреть на другие фреймворки, тот же GWT или что-то другое.
Спасибо за ответы!
N>Но, конечно, у Django есть свои недостатки, которые более или менее раскрыты в этой ветке. И в этом плане, разработка на Django очень подходит для прототипирования — быстренько пишется сайт, согласуется с клиентом, кое-что правится и все — альфа версия готова. Теперь уже разработчик решает — использовать ли Django дальше, или переходить на другую, более качественную систему — ту же связку Spring + Hibernate + Velocity + Wicket. Конечно, есть задачи, для которых Django вообще никак не подходит, даже для прототипирования — те же самые Ajax-based приложения. Здесь уже надо смотреть на другие фреймворки, тот же GWT или что-то другое.
Просто когда будет написаный сайт — переписывать его уже хотеться не будет Вот и хочется заранее узнать где подстелить соломку.
Здравствуйте, Cyberax, Вы писали:
C>Просто когда будет написаный сайт — переписывать его уже хотеться не будет Вот и хочется заранее узнать где подстелить соломку.
Здравствуйте, Nuald, Вы писали:
N>Производительность. На самом деле Django очень high-scaled фреймворк — то, что на нем крутится New Your Times и блог Медведева с реально ощутимым количеством хитов, о чем-нибудь да говорит. Но если все-таки писать что-то типа Twitter-а или Google-а, то надо тщательно проработь архитектуру. Python может стать очень узким местом, и придется либо жертвовать памятью и делать кэширование всего и вся, плюс внедрять load-balancing сервера, либо переписывать с нуля на C++ c FastCGI. Возможно, Java-based фреймворки тоже могут с этим помочь, но здесь я немного отстал от жизни — в свое время (java1.4) все было еще совершенно не блеск.
У меня максимум на миллион хитов в день рассчитывается. Так что Питон особо не будет напрягаться.
N>Интеграция с различными сервисами. Для примера возьму Kerberos-аутентификацию. В Python и Django встроенной поддержки кербероса нет, надо либо прикручивать через ctypes, либо искать внешние модули. В админке Django вообще все плохо с аутентификацией. В то же время в той же Java есть JAAS. Так что если предполагается тесная интеграция с внешними сервисами, надо этот вопрос сразу рассматривать.
Kerberos и авторизацию по сертефикатам я как раз собираюсь прикрутить Ничего там сложного быть не должно.
Здравствуйте, Cyberax, Вы писали:
C>Kerberos и авторизацию по сертефикатам я как раз собираюсь прикрутить Ничего там сложного быть не должно.
О-о-о, если прикрутишь, дай мне знать плиз (если конечно это не будет под NDA) Я у себя в блоге как раз про Kerberos писал, но вот поиски в области разработки приложений с его использованием много нарыть не удалось: Organizing Kerberos-based infrastructure
Здравствуйте, Nuald, Вы писали:
C>>Kerberos и авторизацию по сертефикатам я как раз собираюсь прикрутить Ничего там сложного быть не должно. N>О-о-о, если прикрутишь, дай мне знать плиз (если конечно это не будет под NDA)
В OpenSource выложу.
N>Я у себя в блоге как раз про Kerberos писал, но вот поиски в области разработки приложений с его использованием много нарыть не удалось: Organizing Kerberos-based infrastructure
Kerberos хоть сейчас можно с помощью Апача прикрутить, было бы желание (я даже находил в сети об этом упоминания).
PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене.
Здравствуйте, Cyberax, Вы писали:
C>Kerberos хоть сейчас можно с помощью Апача прикрутить, было бы желание (я даже находил в сети об этом упоминания).
Про апач я в курсе, я говорю про собственно веб-приложение. На уровне апача ты разруливаешь доступ, а скажем, что делать если у тебя логика приложения завязана на учетку? Т.е. например, в веб-приложении встроена авторизация, которая в зависимости от пользователя назначает ему нужную роль. Апач обеспечивает только аутентификацию. А веб-приложение должно взять kerberos-ticket, и из него вытащить всю нужную инфу.
C>PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене.
Т.е. ты хочешь сказать, если что у меня скажем поднят OpenLDAP+Samba+Kerberos, расшарены ресуры под самбой, и пользователь с винды находится в домене Kerberos-а, то сможет нормально зайти на расшаренный ресурс? Такое настроить можно, но насколько я помню, для этого домен должен быть поднят на самбе, а она уже сама коннектится к KAS. Если я не прав, то направь меня плиз в нужном направлении, а то ничего особо не смог найти. Конечно, еще остаются открытые вопросы по GPO и т.п., но мне это особо неинтересно — всегда можно в профиль пользователя добавить командный файл, который при логине будет отрабатываться и делать все необходимые манипуляции с реестром и файловой системой (насколько я знаю, GPO примерно так и работает).
Здравствуйте, Nuald, Вы писали:
C>>Kerberos хоть сейчас можно с помощью Апача прикрутить, было бы желание (я даже находил в сети об этом упоминания). N>Про апач я в курсе, я говорю про собственно веб-приложение. На уровне апача ты разруливаешь доступ, а скажем, что делать если у тебя логика приложения завязана на учетку? Т.е. например, в веб-приложении встроена авторизация, которая в зависимости от пользователя назначает ему нужную роль. Апач обеспечивает только аутентификацию. А веб-приложение должно взять kerberos-ticket, и из него вытащить всю нужную инфу.
Из krb-тикета ты особо ничего кроме принципала пользователя не возьмёшь, а его Apache тебе и так даст. А дальше уже используешь средства самого приложения для авторизации.
Единственная проблема, мне нужно будет поддерживать дальнейшее делегирование с помощью этого тикета, так что для меня прозрачная авторизация в Апаче не подойдёт.
C>>PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене. N>Т.е. ты хочешь сказать, если что у меня скажем поднят OpenLDAP+Samba+Kerberos, расшарены ресуры под самбой, и пользователь с винды находится в домене Kerberos-а, то сможет нормально зайти на расшаренный ресурс?
Да.
N>Такое настроить можно, но насколько я помню, для этого домен должен быть поднят на самбе, а она уже сама коннектится к KAS. Если я не прав, то направь меня плиз в нужном направлении, а то ничего особо не смог найти. Конечно, еще остаются открытые вопросы по GPO и т.п., но мне это особо неинтересно — всегда можно в профиль пользователя добавить командный файл, который при логине будет отрабатываться и делать все необходимые манипуляции с реестром и файловой системой (насколько я знаю, GPO примерно так и работает).
Ставишь Microsoft Resource Kit, там есть нужные утиллиты. Пользовался этим вот howto: http://www.upenn.edu/computing/pennkey/sysadmin/e_install_win/win-config.html
В ближайшем будущем можно на сервере поднять Samba4 — туда как раз на этой неделе добавляют полную поддержку LDAP-схемы ActiveDomain'а. Там вообще будет всё круто.
Здравствуйте, Cyberax, Вы писали:
C>Из krb-тикета ты особо ничего кроме принципала пользователя не возьмёшь, а его Apache тебе и так даст. А дальше уже используешь средства самого приложения для авторизации. C>Единственная проблема, мне нужно будет поддерживать дальнейшее делегирование с помощью этого тикета, так что для меня прозрачная авторизация в Апаче не подойдёт.
Гм, я читанул маны, и обнаружил, что в принципе все не так сложно, как кажется — у mod_auth_kerb есть опция KrbSaveCredentials, которая сохраняет тикет в кэш, а имя файла в переменную окружения KRB5CCNAME. Осталось только написать обертку на питоне, и все.
C>>>PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене. C>Ставишь Microsoft Resource Kit, там есть нужные утиллиты. Пользовался этим вот howto: http://www.upenn.edu/computing/pennkey/sysadmin/e_install_win/win-config.html
Не, я говорю про чисто Linux-based solution. Т.е. например, у нас есть такая проблема — виндами мы вообще не пользуемся, и только поднято некоторое количество виртуальных машин с клиентскими инсталляциями Windows. Они нам нужны исключительно для проверки работоспособности софта. Покупать Windows-сервер вообще смысла нет, т.к. на нем ничего крутить особо и ну будет. А домен хочется, т.к. хочется обеспечить SSO даже для немногочисленных инсталляций Windows.
C>В ближайшем будущем можно на сервере поднять Samba4 — туда как раз на этой неделе добавляют полную поддержку LDAP-схемы ActiveDomain'а. Там вообще будет всё круто.
Да, в курсе, все с нетерпением ждем
C>Но это уже лучше в другой форум идти.
Пусть модераторы выделят в отдельную ветку Ау, вы где?
Меня просто этот вопрос сильно интересует, но катастрофически не хватает времени, чтобы все настроить и поэкспериментировать. Вот тот же самый NuFW фаервол — вещь исключительно интересная, скачал LiveCD, в очередной раз возненавидел французов за их исключительно патриотическое отношение к своему языку, поигрался и забыл, т.к. больше времени не было. Поэтому хотелось бы пообщаться с тем, что имеет больше опыта в этом деле.
Здравствуйте, Nuald, Вы писали:
C>>Единственная проблема, мне нужно будет поддерживать дальнейшее делегирование с помощью этого тикета, так что для меня прозрачная авторизация в Апаче не подойдёт. N>Гм, я читанул маны, и обнаружил, что в принципе все не так сложно, как кажется — у mod_auth_kerb есть опция KrbSaveCredentials, которая сохраняет тикет в кэш, а имя файла в переменную окружения KRB5CCNAME. Осталось только написать обертку на питоне, и все.
Некрасиво. Кроме того, я всё под lighty хочу запускать. Не люблю Апач.
C>>Ставишь Microsoft Resource Kit, там есть нужные утиллиты. Пользовался этим вот howto: http://www.upenn.edu/computing/pennkey/sysadmin/e_install_win/win-config.html N>Не, я говорю про чисто Linux-based solution. Т.е. например, у нас есть такая проблема — виндами мы вообще не пользуемся, и только поднято некоторое количество виртуальных машин с клиентскими инсталляциями Windows. Они нам нужны исключительно для проверки работоспособности софта. Покупать Windows-сервер вообще смысла нет, т.к. на нем ничего крутить особо и ну будет.
Я про это и говорю. Ставишь Kerberos+LDAP, настраиваешь всё что тебе нужно на Линуксах. На клиентских Windows-машинах ставишь Resource Kit, там есть утиллита ksetup — с помощью неё уже настраиваешь вхождение в область Kerberos.
N>А домен хочется, т.к. хочется обеспечить SSO даже для немногочисленных инсталляций Windows.
Аналогично.
N>Пусть модераторы выделят в отдельную ветку Ау, вы где?
Не проснулись ещё. Не все же в Хабаровске
N>Меня просто этот вопрос сильно интересует, но катастрофически не хватает времени, чтобы все настроить и поэкспериментировать. Вот тот же самый NuFW фаервол — вещь исключительно интересная, скачал LiveCD, в очередной раз возненавидел французов за их исключительно патриотическое отношение к своему языку, поигрался и забыл, т.к. больше времени не было. Поэтому хотелось бы пообщаться с тем, что имеет больше опыта в этом деле.
Я занимаюсь всякими настройками, когда делать что-то нужное совсем лень.
Здравствуйте, Cyberax, Вы писали:
C>Некрасиво. Кроме того, я всё под lighty хочу запускать. Не люблю Апач.
Ты говоришь про lighttpd? А он разве поддерживает Kerberos?
C>Я про это и говорю. Ставишь Kerberos+LDAP, настраиваешь всё что тебе нужно на Линуксах. На клиентских Windows-машинах ставишь Resource Kit, там есть утиллита ksetup — с помощью неё уже настраиваешь вхождение в область Kerberos.
Здравствуйте, Nuald, Вы писали:
C>>Некрасиво. Кроме того, я всё под lighty хочу запускать. Не люблю Апач. N>Ты говоришь про lighttpd? А он разве поддерживает Kerberos?
Нет (точнее, пока нет — есть патч). Но от сервера для поддержки Kerberos нужно только чтоб он заголовки пропускал, а остальное уже в прикладном коде делается.
Здравствуйте, Cyberax, Вы писали:
N>>Ты говоришь про lighttpd? А он разве поддерживает Kerberos? C>Нет (точнее, пока нет — есть патч). Но от сервера для поддержки Kerberos нужно только чтоб он заголовки пропускал, а остальное уже в прикладном коде делается.
Ну круто. Значит решение под mod_kern_auth ты называешь некрасивым, а при этом собираешься писать свой велосипед? Это ж как апач надо не любить?
Что он тебе такого плохого сделал, кроме тормозов?
Здравствуйте, Nuald, Вы писали:
C>>Нет (точнее, пока нет — есть патч). Но от сервера для поддержки Kerberos нужно только чтоб он заголовки пропускал, а остальное уже в прикладном коде делается. N>Ну круто. Значит решение под mod_kern_auth ты называешь некрасивым, а при этом собираешься писать свой велосипед? Это ж как апач надо не любить?
PyKerberos уже есть, так что большая часть велосипеда написана.
N>Что он тебе такого плохого сделал, кроме тормозов?
Съел мою кошку
А если серьёзно, то тормоза и идиотские проблемы с конфигурацией просто давно достали.
Здравствуйте, Nuald, Вы писали:
>Вообще, я планирую написать в ближайшее время сравнительный обзор всех современных "Agile" фреймворков: Django, RoR, Grails, Perl Catalyst, но пока не могу изыскать времени. Там бы я рассмотрел все плюсы и минусы.
Здравствуйте, Nuald, Вы писали:
N> А то, что Rails реально крутой язык, на котором можно сворганить свой DSL и предоставить заказчику разрабатывать программы на высоком уровне, меня совершенно не волнует, т.к. такого рода задачи возникают ну реально редко
Здравствуйте, Курилка, Вы писали:
N>> А то, что Rails реально крутой язык, на котором можно сворганить свой DSL и предоставить заказчику разрабатывать программы на высоком уровне, меня совершенно не волнует, т.к. такого рода задачи возникают ну реально редко
К>Долго думал по поводу выделенного
Вот и хочется заранее узнать где подстелить соломку.
Если не лезть в админку, то код пишется на ура. ORM, интернационализация, шаблоны, юнит-тестирование — все красиво и приятно.
Ну ладно, Ajax пока у нас не приоритетный.
