#39710 esclkm:
Этим летом я встретился с Trusmaster’ом в НН. Это была очень интересная продуктивная встреча в плане мыслей и познания. Собственных идей и т.д. Давайте дружно признаем, что cotonti – это его проект. Но жизнь делает свои повороты. И у него есть семья, есть свои проблемы, которые надо решать. Cotonti стал для многих проектом, приносящим деньги. Для кого-то – это проект вдохновения. Мы все растем и нас начинают привлекать разные идеи из разных движков.
Мне вдохновила недавно идея GRUB (пользовался ей в Yii 1.2)/ Я начал сразу же писать свой редактор GRUB на c# для Cotonti (даже пришлось написать свой шаблонизатор). Но еще больше мне понравилась идея моделей. Подобными вещами занимались Trustmaster и Alex300 несколько лет назад.
Я не предлагаю это вводить в ядро.
Я задумался давно на тему интерфейсов. И понял, какое это зло.
Давайте подумаем, что мы можем сделать для котонти? Те, кто еще в нем. Но не только это важно. Важно понять для кого мы работаем?
- Для сверхконечного пользователя. Ему интересна, только генерируемая информация.
- Для владельца сайта. Мы никогда ему не угодим. Время бесплатных CMS уже ушло. Люди сейчас платят большие деньги за готовые решения именно для них. Но никак не универсальную посудомойку-пылесос. А подобных инструментов, в котонти уж простите и в помине не водилось.
- Для юного вебдзайнера, верстальщика. Мне кажется это именно та категория! Он может сделать сайт на котонти любой сложности ля любого клиента.
- Для серьезных веб-разработчиков. Они наоборот предпочитают современные фреймворки. Да и любят они греметь словами MVC и другими. Хотя солнце можно нарисовать ручкой, песком, карандашом, красками и т.д.
Теперь про ЧАНКИ. Я с ними категорически не согласен.
Любая переменная в шаблонах используется как {A} или {A.B.C}. А Dr2005alex предлагает использовать имена файлов одинаково с переменными. Это ИМХО - просто дурной тон - создать множество интерфейсов. А это плохо. Мы легко понимаем, как пользоваться дрелью, так как в ней всего 1 кнопка. Не надо делать 5 кнопок для одного действия – это вызывает отторжение. Купите дрель с пятью кнопками сверлить и тремя розетками. НО и не надо одной кнопке назначать 5 действий.
В котонти многие интерфейсы нуждаются в жестком упрощении. Но не усложнении.
ИМХО.
Мне не хватает сегодня:
- написанной одним дизайнером разумной админки и стартового шаблона на Bootstrap. Не просто впихивания бутстапа в базовый шаблон, а создание уникального проработанного шаблона.
- не хватает моделей. Если честно – хочется модуль страниц переделать. Никому не нужны функции импорта, сохранения, создания страницы. От них было бы больше току – если бы они работали внутри вменяемой модели страниц, в которой были бы расписаны все поля и все исключения.
- не хватает проверки форм при помощи JS.
- не хватает удобного редактирования нескольких страниц.
- не хватает колбэков в шаблонизаторе для нескольких параметров, например [cot_url | {A} | {B}]
- не хватает обработчика ошибок в шаблонизаторе! Я просто плачу, когда мой шаблон с ошибкой. Я вижу неясный текст. А хочу видеть конкретную ошибку.
-не хватает возможности генерировать шаблон из текста, а не из файла.
-не хватает документации. Любого качества.
- не хватает удобной админки с вменяемой логикой. Я не хочу попадать к одной ссылке 10ью путями! Это усложняет общение с клиентами.
-не хватает генерируемой под клиента админки.
- не хватает синхронизации с соц сетями.
- адекватной работы с файлами.
Я вижу много путаницы в интерфейсах.
- Стандартные модули и плагины имеют названия то во множественном, то в единственном числе: forums и page.
- файлы их пути и использование имеют различные названия. Например: cot_langfile или cot_incfile. Папки называются: plugins , modules, system – но внутри этих функций мы используем plug, module, core
- имена установщиков, апдейтеров, унисталяторов – еще 1 путаница.
-обращение к конфигам и auth модулей и плагинов крайне различно.
И таких путаниц уйма. И во многих из них виновен я. Но уже это есть.
Я многие свои приложения размещаю на github и там много решений поставленных вопросов. Просто реально – вопрос стоит так: а что мы хотим и для кого мы это делаем. Спасибо, что не поленились прочесть.
Добавлено 1 минуты спустя:
P.S. Слоты меню - это то, что нуждается в ликвадации. ИМХО. Дело не в их удобстве. А в том, что вы сами через месяц забудите, что для какого слота писалось. Его имя ничего не отражает.
Добавлено 46 минуты спустя:
Мысли по описанному —
тоже виделся с ТМ, в феврале правда. Но это так, к слову.
Проблему вижу всю ту же (это касается не только, и не столько Ecslkm, а почти всех условно «активных» разработчиков в том, числе и меня) — хотелок и идей много, текста меньше, предложений как реализовать ту или иную идею еще меньше, результата почти ноль. [Я не беру в расчет варианты, когда разработчик сделал для себя хотелку, а потом её представил как готовый костыль. Как правило такие подерлки все равно популярностью не пользуются, т.к. узко заточены.]
Причины вижу следующие:
- ни у кого нет времени (объективно главная, но мало решаемая проблема)
- нет взаимопонимания, у каждого свое видение — на одну идею в лучшем случае 1-2 со своими предложениями и еще 2-3 в корне несогласных
- отсюда нет скоординированности действий, и как результат нет хотя бы общего плана развития, а отсюда и фронта «общественных» работ, и самое главное ответственных за них
Развития нет, потому что механизма реализации нет. Пока кто-то (в частности Владимир) имеет ресурсы и тянет все на себе — есть некоторое движение, а нет — получается полный раздрай.
Мои предложения — переходить от разглагольствований на форуме в практическую плоскость:
- Еще раз пересчетать по головам (поименно) тех, кто готов хоть каплю (денег/кода/просто своего сремени) вкладывать в проект (обозначить их четкие контакты).
- Назначить регулярные общие встречи (раз в неделю/две/месяц) в skype с четким временным лимитом. Желающие «поболтать» на более широкие/узкие темы могут назначить доп. встречи.
- На каждую встречу иметь четкую повестку, что обсуждаем, каков должен быть результат.
- По ходу обсуждения выделяем фронт работ для желающих и имеющих возможность помочь, пусть малый, но четко обозначенный объем работ. Кто не может/ не хочет писать код — пусть помогает на уровне идей и консультаций.
- Назначаем ответственных, планируем план на следующий сбор.
- Далее на новый цикл с п.3 — сбор, проверка результатов работ по пред. этапу, корректировка, новые задачи и т.д.
- [опционально] постить в отдельную ветку результаты сбора (в виде основных тезисов и задач). Сразу будет видно, что и на какой стадии, куда и с какой скоростью движемся.
Могу быть в скайпе (macik.spb) с 10-21 по будням (в среду после 16-00). В выходные в зависимости от предварительного согласования. Для оперативной связи писать на: macik . spb гавгав gmail . com (без пробелов). Кому надо могу дать моб. телефон.
