Как Вы управляете своими приложениями Django?
Проблема в том, что вы устанавливаете скрытие анимации ключевых кадров, в котором вы устанавливаете from : 0% и to: -100%. Это означает, что анимация начинается с боковой панели в 0.
Таким образом, она идет от -100% (которую вы устанавливаете по умолчанию на #sidebar), переходит в позицию from в 0% и затем переходит положение to. Вот почему боковая панель появляется при загрузке.
Затем анимация показа снова скрывает боковую панель, потому что вы не установили animation-fill-mode, которое должно быть forwards. Если нет, то в конце любой анимации элемент возвращается в положение по умолчанию, которое вы установили на -100% на #sidebar. Так что опять прячется.
(в данном случае) Вы можете вообще пропустить анимацию и просто использовать переходы
#sidebar {
background-color: #e0e0e0;
border: 1px solid red;
height: 100%;
overflow-x: hidden;
overflow-y: auto;
position: fixed;
top: 0;
left: -100%;
right: 0;
bottom: 0;
width: 100%;
transition: 1s;
}
#sidebar.hide {
left: -100%;
}
#sidebar.show {
left: 0;
}5 ответов
Нет твердых правил, но я сказал бы, что лучше допустить ошибку на стороне большего количества специализированных приложений. Идеально приложение должно обработать всего одно функциональное беспокойство: т.е. "метки" или "комментарий" или "автор/автор" или "сообщения". Этот тип дизайна также поможет Вам повторное использование доступные приложения с открытым исходным кодом вместо того, чтобы изобрести велосипед (т.е. Django идет с автором и комментирует приложения, django-метки или django-taggable могут почти наверняка сделать то, в чем Вы нуждаетесь, и т.д.).
Универсальные внешние ключи могут помочь Вам отделить приложения, такие как метки или комментируя, что это могло бы быть применено к моделям из нескольких других приложений.
Необходимо попытаться разделить проект в как можно больше приложениях. Для большинства проектов приложение не будет содержать больше чем 5 моделей. Например, проект как ТАК имел бы отдельные приложения для UsersProfiles, Вопросов, Тегов (существует готовый в django для этого), и т.д. Если бы была система со статическими страницами, то это было бы отдельным приложением также (существуют готовые с этой целью). Необходимо также попытаться подать заявки, максимально универсальные, таким образом, можно снова использовать их в других проектах. На допускающих повторное использование приложениях существует хорошая презентация.
Точно так же, как любой набор зависимостей... пытаются найти самые полезные автономные аспекты проекта и сделать те автономные приложения. Другой Django Apps будет иметь высокоуровневую функциональность и снова использует части самых низких приложений уровня, которые Вы настроили.
В моем проекте у меня есть календарное приложение с его собственным Объектом-событием в его моделях. Мне также настраивали базу данных автобазы, и в течение времени отправления и продолжительности, я использую Объект-событие календаря прямо в моих таблицах RideShare. База данных совместного пользования автомобилем осведомлена о календаре, и получает весь хороший экспорт .ics и календарные представления из календарного приложения для 'свободного'.
Существуют некоторые приемы к получению допускающих повторное использование Приложений, как именование шаблонного каталога: project/app2/templates/app2/index.html. Это позволяет Вам обратиться к app2/index.html из любого другого приложения и получить правильный шаблон. Я выбрал тот, смотрящий на встроенные допускающие повторное использование приложения в Django сам. Pinax является немного мудрым размером монстром, но он также демонстрирует хорошую допускающую повторное использование структуру Приложения.
Если в сомнении, забудьте о допускающих повторное использование приложениях на данный момент. Поместите все свои сообщения и опросы в одном приложении и пройдите через одну версию. Вы обнаружите во время процесса, какие шаги чувствуют себя ненужными, и могли вспыхнуться как что-то автономное в будущем.
Я скажу Вам, как я приближаюсь к такому вопросу: Я обычно сижу с листом бумаги и тяну поля (технические возможности) и стрелки (взаимозависимости между техническими возможностями). Я уверен, что существуют методологии или другие вещи, которые могли помочь Вам, но мой подход обычно работает на меня (YMMV, конечно).
Знание, что сайт, как предполагается, является основным, все же.;)
Хороший вопрос спросить себя при решении, записать ли приложение, "я мог бы использовать это в другом проекте?". Если бы Вы думаете, что могли, затем рассмотреть то, что это взяло бы для подавания заявки, максимально независимой; Как можно уменьшить зависимости так, чтобы приложение не полагалось ни на что характерное для конкретного проекта.
Некоторые способы, которыми можно сделать это:
- Предоставление каждого приложения его собственного urls.py
- Разрешение типов модели быть переданным в как параметры вместо того, чтобы явно объявить, какие модели используются в представлениях. Универсальные представления используют этот принцип.
- Сделайте свои шаблоны легко переопределенными путем передачи своего рода template_name параметра в urls.py
- Удостоверьтесь, что можно сделать обратные поиски URL с объектами и представления. Это означает называть Ваши представления в urls.py и создавать get_absolute_url методы на Ваших моделях.
- В некоторых случаях как Метки, GenericForeignKeys может использоваться для соединения модели в приложении к любой другой модели, независимо от того, имеет ли он ForeignKeys, "оглядывающийся назад" на него.