-
Добрый день.
Существует общая рекомендация делать приложения pluggable и reusable. Всегда ли стоит пытаться следовать этим критериям в разработке приложений?
Я делаю сайт, представляющий каталог локаций (мест). Проект вмещает только одно базовое приложение. Это логично: приложение хранит много данных, но они цельны и тесно связаны друг с другом.
Проблема возникла неожиданно — в интерфейсе административного приложения неудобно управлять таким объемом данных.
И тогда я подумал разделить одно приложение на несколько: locations, addresses, contact_details, meta_info и прочее в таком духе.
Вроде и нет такой необходимости: эти маленькие приложения не стоит делать ни pluggable, ни reusable — слишком много условий и деталей. С другой стороны, для удобного управления данными в интерфейсе административного приложения, было бы очень кстати разделить одно приложение на несколько.
Что посоветуете? Как вы обычно поступаете в таких случаях? -
admin16.03.2010
0
0
Интефрейсы это самостоятельная тема. Когда ни кто специально не занимается проектированием взаимодействия между пользователем и сайтом, то интефрейсы получаются неудобными вполне ожиданно, т.е. практически всегда. Джанго-админка очень плохой проектировщик… Поищите книжку Алана Купера "Психбольница в руках пациентов". ))
Что касается технической части, то кроме "pluggable и reusable", для программного кода есть более важный фактор — тестируемость, то бишь предсказуемость и управляемость. Для больших и запутанных кусков кода невозможно написать легкий и понятный тест. Поэтому дробить функциональность на отдельные модули нужно. Заморочка в том, что дефолтные средства, предоставляемые django, не дают разработчику ни единого намека на то, как тестировать django-приложение в отрыве от (основного) django-проекта. Для этой цели я использую http://pypi.python.org/pypi/djangorecipe и, соответственно, zc.buildout . Рецепт умеет автоматически создавать микро-django-проекты для запуска тестов приложения. Это позволяет смотреть на ситуацию со стороны отдельно взятого приложения, как самостоятельной сущности. При таком подходе фактор plugable получается by desing. :) -
Спасибо. В итоге, я тоже пришел к тому, что из приложения нужно убирать все, что не имеет прямого отношения к описываемой им сущности. (Встретил где-то рекомендацию, что задача приложения должна быть описана одним-двумя предложениями. В противном случае, что-то не так.)
Кроме этого, теперь, когда я выспался, мне совершенно очевидно, что строить приложения проекта так, чтобы они аккуратно выглядели в административном интерфейсе — это путь от обратного. Нужно делать административный интерфейс таким, чтобы в нем было удобно работать с объектами приложений.
Спасибо. -
Меня беспокоит только одно: при таком подходе получится столько мелких приложений, что их список перестанет умещаться в экран.
Существует ли практика группировки приложений в э-э-э-э..., скажем, пакеты? -
Меня беспокоит только одно: при таком подходе получится столько мелких приложений, что их список перестанет умещаться в экран.Я наткнулся на слайды презентации Django in the Real World (http://jacobian.org/speaking/oscon-2009/oscon/). Вот что, среди прочего, в ней сказано по этому вопросу:
• Many great Django apps are very small
• Even a lot of “simple” Django sites commonly have a dozen or more applications in INSTALLED_APPS
• If you’ve got a complex site and a short application list, something’s probably wrong
Получается, что это нормально. -
Вообще, идея стремиться к какому-то числу неверна сама по себе. Отдельные приложения являются отдельными по признаку модульности их функциональности. Сколько их при том получается — вторично.
Кстати, SoftwareManiacs.Org состоит из 20 приложений.
-
Отщеплен новый топик "Последствия добавления приложения в INSTALLED_APPS".
Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.