Alto CMS v.1.0 RС-4 - долгий путь к финальному релизу

Я тоже считаю, что личные переписки можно было бы сделать более удобнее, и понятнее. Пример, обычные диалоги FB и VK. Просто и красиво.

и имеет отдельную от остального сайта гарнитуру, как и положено логотипу.

Гарнитура Roboto, та же что и на остальной части страницы.

Лучшая для вас, не для меня. Я отвечал на вопрос о нужном мне функционале.

Т.е достаточно просто выключить древовидную структуру сообщений?

Гарнитура Roboto, та же что и на остальной части страницы.

Действительно, не заметил. Тогда аргумент про гарнитуру снимается.

Т.е достаточно просто выключить древовидную структуру сообщений?

Не все так просто. Нужно, чтобы это делалось на уровне плагина, а не шаблона, иначе каждое обновление движка будет пыткой.

Здесь так: есть событие — публикация топика. И мы либо реагируем на него (шлем уведомления, показываем в ленте и т.д.), либо нет. А получит ли юзер уведомление на мыло, либо на сайте увидит — это уже дело десятое. Вот единого такого механизма «реагирования» на отложенные события в движке пока нет

Тогда проще всего, наверное, доработать крон до асинхронного запуска...

Идея «центрального крона» (т.е. некоего единого компонента, который должен дергаться каким-то образом и разруливать все отложенные события) высказывалась давно, еще в обсуждениях ЛС до рождения Альто. Но пока просто руки не дошли до него. И этот функционал, конечно же, должен быть в ядре, тут плагином не обойтись.

… а другие прибиты даже не гвоздями, а шурупами: те же типы полей...

Про кастомные поля — абсолютно верное замечание, переделывать нужно однозначно.

А какие еще вещи «шурупами прикручены»? Свежий незамыленный взгляд и конструктивная критика — это всегда полезно

А какие еще вещи «шурупами прикручены»? Свежий незамыленный взгляд и конструктивная критика — это всегда полезно

Да я пока не разбирался особо — так, на что взгляд упал, о том и пишу. Я как-нибудь постараюсь изложить свои мысли обо всем этом в отдельном топике, раз уж вы не против. Система достаточно запутанная, скорее всего конструктив появится только в процессе изучения и реализации того, о чем говорил выше. Отложенная публикация мне нужна по-любому.

Кстати, мне льстит, что вы выслушали. Тот же ort, походу, забронзовел и развернул у себя банно-прачечный комбинат :)

Я как-нибудь постараюсь изложить свои мысли обо всем этом в отдельном топике, раз уж вы не против

Не то что бы не против — я категорически ЗА!

Иногда критика высказывается в не очень приятной форме (типа, что за мудаки разработчики, слепившие такую-то хрень — это почти цитата). Но даже в таких случаях я стараюсь отделить зерна от плевел и выцепить суть, чтобы учесть в дальнейшей разработке (хотя и не поддерживаю такого стиля общения).

Я понимаю, что движок еще очень далек от идеала, и какие-то недостатки сам вижу, а где-то, наверняка, глаз замыливается. Поэтому не устану повторять: приветствуется любая конструктивная критика, пожелания и предложения.

Иногда критика высказывается в не очень приятной форме

Сам такой критики не получал, но да, было бы неприятно. Исключение делаю для одинэсников и битриксойдов — у них спеси и глупости такие вагоны, что грех их не попинать :)

Потихоньку осваиваюсь с движком (и правлю баги — по-моему, далек он ещё от релиза), но очень не хватает информации.

Есть ли где-нибудь заметки по архитектуре движка и, главное, причинах принятых при её разработке решений?

От некоторых просто корежит:

Способ вызова методов хелперов через подчеркивание безнадежно ломает подсветку синтаксиса во всех ide.

Структура папок… таинственная. Без проводника в ней можно заблудиться и погибнуть.

Повсеместно используется DbSimple, хотя на всех хостингах уже давно поддерживается PDO (терпеть не могу Котерова, а сама библиотека у меня занимается откровенным вредительством, без мелкого патча на windows она тормозит движок почти на секунду).

Какие-то решения, скажем так, исторически сложились. Например, тот же вызов методов через подчеркивание. Да, в перспективе хотелось бы уйти от этого, и даже есть некоторые наработки:
altocms.ru/blog/339.html
altocms.ru/blog/extensions/374.html

Но на текущем этапе, считаю, есть более насущные задачи.

Структура папок…

Структура папок движка в целом: altocms.ru/blog/dev/418.html
Структура папок нового шаблона: altocms.ru/blog/skins/551.html

Повсеместно используется DbSimple, хотя на всех хостингах уже давно поддерживается PDO

Юзать PDO в чистом виде все равно не удобно, нужна обертка по любому (обработка ошибок, логгирование, разные DB, плейсхолдеры, выборки разных видов и т.д.). И DbSimple выполняет роль этой обертки. Причем, это давно уже не оригинальная котеровская библиотека, а, как бы, форк форка оригинала. Я думал о том, чтоб сменить библиотеку, но не смог подобрать что-то близкое по интерфейсу, а ломать совместимость напрочь не хотел.

По умолчанию подключение идет через mysqli, но можно и через PDO подключаться. Сейчас есть люди, которые работают с PostgresSQL, и уже немало замечаний было выдано относительно работы с этой базой. Если возьметесь оттестировать работу через PDO, будет здорово.

без мелкого патча на windows она тормозит движок почти на секунду

А что за патч? Только под Виндой он нужен?

Да, в перспективе хотелось бы уйти от этого, и даже есть некоторые наработки

О, здорово. Рад, что не я один так думаю. Я бы сделал немного не так, как у них, добавив в базовые классы что-то типа такого (псевдокод, сильно упрощенный):

function __get($name) {
    $this->$name = $name::getInstance();
    return $this->$name;
}

Тогда первый вызов модуля станет просто дешевым (не будет кучи обработок строк), а остальные будут бесплатны (т.к. ссылка на модуль пропишется в переменную и __get повторно вызываться не будет). Насколько я понимаю, такое упрощение сэкономит тысячи вызовов функций на каждую страницу (в цифрах это прирост производительности где-то на 1/4). А для подсказок в ide там же прописать имена классов всех стандартных модулей через @var.

Кстати, переход на такую схему совсем не сложен, достаточно написать парсер, который перепишет все вызовы на новый синтаксис. Совместимость со старым можно оставить, тогда писатели модулей не пострадают.

Но, как вы правильно заметили, сейчас другие приоритеты — отловить все баги и поскорее выпустить релиз. Я просто хочу сказать, что такое изменение — не такая уж титаническая работа, как кажется.

Структура папок…

Почитаю, спасибо. Вообще, такие вещи стоит вынести в какой-нибудь faq. Ну или сделать что-то типа вики или вопросов-и-ответов.

Юзать PDO в чистом виде все равно не удобно, нужна обертка по любому

Вообще, неудобства вы преувеличиваете — напрямую база используется относительно мало (если искать строку «oDb->», найдется файлов на 300кб) и в абсолютном большинстве случаев это просто запросы с подстановкой. Кроме того, библиотека слабовата, и ей все равно нужна дополнительная обертка. Например, вот от таких «паттернов» явно надо избавляться:

isset($aFilter['id']) ? $aFilter['id'] : DBSIMPLE_SKIP,
isset($aFilter['email']) ? $aFilter['email'] : DBSIMPLE_SKIP,
isset($aFilter['password']) ? $aFilter['password'] : DBSIMPLE_SKIP,
isset($aFilter['ip_register']) ? $aFilter['ip_register'][0] : DBSIMPLE_SKIP,
isset($aFilter['ip_register']) ? $aFilter['ip_register'][1] : DBSIMPLE_SKIP,

Ну и, чисто теоретически, кэширование, профилирование и логирование запросов все-таки ближе к приложению, чем к сторонней библиотеке.

Думаю, вместо dbsimple нужно взять что-то типа zend_db, где простые select-ы реализованы методами. Подобные простыни кода тогда сократятся вдвое-втрое.

И еще, по-моему mapper-ы можно сделать удобнее и производительнее, если снабдить их описаниями таблиц: методы для CRUD тогда не нужно будет прописывать вручную, плагинами можно будет расширять таблицы, не боясь, что ядро потеряет какие-то поля, а если сделать двойную буферизацию полей, то в запросы на сохранение будут передаваться только измененные данные (сумбурно, постараюсь потом более развернуто объяснить идею).

А что за патч? Только под Виндой он нужен?

Да даже не патч, а хак. У Винды есть трудноуловимый баг, когда она лезет резолвить 'localhost' в интернет, причем делает это медленнее, чем обычно (у меня получалось полсекунды-секунда). Сейчас воспроизвести не могу, но с первой публичной версией движка я на него наткнулся — почему-то смена в конфиге 'localhost' на '127.0.0.1' не помогала — и я тупо прошил этот адрес в библиотеке, сразу после парсинга DSN. На Линуксе с этим не сталкивался ни разу.

Да я пока не разбирался особо — так, на что взгляд упал, о том и пишу. Я как-нибудь постараюсь изложить свои мысли обо всем этом в отдельном топике,

Было бы действительно интересно. Все, что конструктивно и обоснованно — принимается к сведению, и к обсуждению.