О, как вы быстро! Хорошее заклинание призыва :)
Спасибо за ответ, и, если можно, опишите в двух словах как это было реализовано: это полностью кастомное решение или использовались какие-то готовые решения, как для сервера, так и для клиента? Сильна ли завязка на Django или это можно перенести на другие python-фреймфорки?
В ближайшем будущем планируется сделать open source-версию? Или пока заморозили до лучших времён?
Да, Panelizer крутая штука, но только как концепт. Отдавать пользователям её нельзя. Мы отказались от использования panelizer в качестве контент редактора по следующим причинам:
— Нет нормального билдера сетки. В 8-ке пилят человечный grid builder, но он сырой. Для 7-ки — вообще никакой. Использовать свою сетку можно, но теряется половина преимуществ подобного редактирования контента.
— Глючно. Нельзя просто взять и установить модуль. Для стабильной работы надо ставить кучу патчей или всю сборку панополи.
— Проблемы при использовании панелей в панелях. По сути — так делать нельзя — у системы сносит башню, но тогда надо отключить такую возможность в принципе, а не надеяться, что пользователь этого делать не будет.
— Меееееееедленно. Ну просто ужасно медленно. Подобные штуки должны работать на стороне клиента и быть мгновенными (смотрите для примера Sir Trevor, Smart Builder или Семантический редактор для сайта belonika.ru), а друпал всё это прогоняет через сервер, с выплёвыванием готовых html-форм, что не прибавляет живости.
— Муторное добавление своих виджетов. Как бы ничего сложного, но ни нормальной документации, ни красивых примеров кода нет.
Ребята из FutureColors делали подобный редактор для сайта Вероники Белоцерковской — futurecolors.ru/belonika/ (смотрите видео). Если не ошибаюсь это Django. Но в open source этого нет — закрытая разработка.
Надеюсь ребята из FC здесь отпишутся (призываю piumosso и Prophet).
Просто сравните сколько средств оптимизации, фреймворков, CMS существует для PHP и Python.
Этот аргумент можно использовать и против PHP — «посмотрите сколько велосипедов есть для PHP, а для Python (Ruby, etc...) они не нужны и поэтому их нет». Как пример — opcode кэширование для PHP: APC, eAccelerator, Xcache, что там ещё… — для питона этого нет. Во-первых, это встроено в ядро (*.pyc), во-вторых, код для python web-приложения загружается один раз, в отличие от PHP, «поднимающегося» для каждого запроса.
if (a | b | c)
if (d | e)
for(цикл)
if (условие)
{
}
Да, я тоже так писал одно время на С++. Долгое время — лет так несколько. Потом начал получать логические ошибки — ставил else, думая, что оно относится к одному if, а оно, на самом деле, «прилеплялось» к другому.
Причина почему сначала «всё было хорошо» — низкая скорость разработки и мало чужого кода. Когда скорость разработки повышается, мозг начинает ориентироваться на визуальные якори, а не разбирать семантику, ибо ему так легче. Результат — ошибки.
Вобчем, я сейчас пишу только со скобками, даже если 100% уверен, что больше одного оператора в этих скобках не будет.
Думаю всё дело в сложности. Для блогов, портфолио и новостных порталов гораздо проще делать адаптивный дизайн — акцент сосредоточен на одном компоненте, как правило — тексте статьи, всё остальное можно скрыть/сдвинуть/свернуть/сжать. В магазине же много элементов, которые надо как-то впихнуть в прокрустово ложе маленьких экранов. Но деваться-то некуда — зоопарк устройств настолько огромен, что определить на чём просматривают сайт становиться всё сложнее — android может быть на телефоне, планшете, телевизоре (как вам мобильная версия сайта на 50-ти дюймовом экране телевизора?), поэтому надо «привязываться» к разрешению экрана и адаптировать именно под него, а не устройство.
Вы описываете не адаптивную вёрстку, а мобильную версию, т.к.:
— адаптивная вёрстка не меняет кардинально интерфейс, только подстраивает под разрешение устройства — изменяется главное меню, масштабируются изображения, меняется количество блоков в строках.
— отсутствует «полная версия» сайта — она всегда одна.
— удорожание невелико — увеличивается стоимость вёрстки и немного — дизайна.
Тонну примеров адаптивных сайтов можно посмотреть здесь: mediaqueri.es/
Странно, у меня MAX_CONTENT_LENGTH работал нормально. Только это было на версии 0.8
Плюс я подкручивал nginx, но по другой части — увеличивал предел загружаемого файла.
Я поясню этот коммент, дабы было понятно для новичков.
Про модуль Flag и .info файл уже сказали ниже, разберём другие моменты.
1. Шаблоны предназначены для формирования конечного HTML. Логики в них быть не должно. В вашем случае необходимо написать handler для views, который бы формировал (на основе прав доступа) нужные голоса и ссылки.
2. Проверка на зарегенного пользователя: if ($user->uid != 0) это негибко, используйте hook_permission и проверяйте права через user_access, это позволит управлять функционалом на уровне прав пользователя, что гораздо удобнее.
3. Изучите Ajax framework, который позволит не городит велосипедов из JavaScript. В вашем случае можно было обойтись вообще без JS с таким же объёмом php-кода.
Посмотрите модуль examples — там собрано множество примеров, которые могут пригодится в жизни )
Спасибо за ответ, и, если можно, опишите в двух словах как это было реализовано: это полностью кастомное решение или использовались какие-то готовые решения, как для сервера, так и для клиента? Сильна ли завязка на Django или это можно перенести на другие python-фреймфорки?
В ближайшем будущем планируется сделать open source-версию? Или пока заморозили до лучших времён?
— Нет нормального билдера сетки. В 8-ке пилят человечный grid builder, но он сырой. Для 7-ки — вообще никакой. Использовать свою сетку можно, но теряется половина преимуществ подобного редактирования контента.
— Глючно. Нельзя просто взять и установить модуль. Для стабильной работы надо ставить кучу патчей или всю сборку панополи.
— Проблемы при использовании панелей в панелях. По сути — так делать нельзя — у системы сносит башню, но тогда надо отключить такую возможность в принципе, а не надеяться, что пользователь этого делать не будет.
— Меееееееедленно. Ну просто ужасно медленно. Подобные штуки должны работать на стороне клиента и быть мгновенными (смотрите для примера Sir Trevor, Smart Builder или Семантический редактор для сайта belonika.ru), а друпал всё это прогоняет через сервер, с выплёвыванием готовых html-форм, что не прибавляет живости.
— Муторное добавление своих виджетов. Как бы ничего сложного, но ни нормальной документации, ни красивых примеров кода нет.
Надеюсь ребята из FC здесь отпишутся (призываю piumosso и Prophet).
Этот аргумент можно использовать и против PHP — «посмотрите сколько велосипедов есть для PHP, а для Python (Ruby, etc...) они не нужны и поэтому их нет». Как пример — opcode кэширование для PHP: APC, eAccelerator, Xcache, что там ещё… — для питона этого нет. Во-первых, это встроено в ядро (*.pyc), во-вторых, код для python web-приложения загружается один раз, в отличие от PHP, «поднимающегося» для каждого запроса.
Да, я тоже так писал одно время на С++. Долгое время — лет так несколько. Потом начал получать логические ошибки — ставил else, думая, что оно относится к одному if, а оно, на самом деле, «прилеплялось» к другому.
Причина почему сначала «всё было хорошо» — низкая скорость разработки и мало чужого кода. Когда скорость разработки повышается, мозг начинает ориентироваться на визуальные якори, а не разбирать семантику, ибо ему так легче. Результат — ошибки.
Вобчем, я сейчас пишу только со скобками, даже если 100% уверен, что больше одного оператора в этих скобках не будет.
На главной странице сайта Sublime тоже неплохо показана работа с курсором.
{
«tab_size»: 4,
«translate_tabs_to_spaces»: true
}
2. { «keys»: [«ctrl+shift+d»], «command»: «duplicate_line» }
А объединённый курсор надо распробовать — сначала кажется ненужной стрёмной штукой, но потом…
Вы описываете не адаптивную вёрстку, а мобильную версию, т.к.:
— адаптивная вёрстка не меняет кардинально интерфейс, только подстраивает под разрешение устройства — изменяется главное меню, масштабируются изображения, меняется количество блоков в строках.
— отсутствует «полная версия» сайта — она всегда одна.
— удорожание невелико — увеличивается стоимость вёрстки и немного — дизайна.
Тонну примеров адаптивных сайтов можно посмотреть здесь: mediaqueri.es/
Плюс я подкручивал nginx, но по другой части — увеличивал предел загружаемого файла.
Про модуль Flag и .info файл уже сказали ниже, разберём другие моменты.
1. Шаблоны предназначены для формирования конечного HTML. Логики в них быть не должно. В вашем случае необходимо написать handler для views, который бы формировал (на основе прав доступа) нужные голоса и ссылки.
2. Проверка на зарегенного пользователя: if ($user->uid != 0) это негибко, используйте hook_permission и проверяйте права через user_access, это позволит управлять функционалом на уровне прав пользователя, что гораздо удобнее.
3. Изучите Ajax framework, который позволит не городит велосипедов из JavaScript. В вашем случае можно было обойтись вообще без JS с таким же объёмом php-кода.
Посмотрите модуль examples — там собрано множество примеров, которые могут пригодится в жизни )