Ищу помощников в разработке CMF на PHP/C++

[Kostia]

Уже как ~2.5 года веду разработку этой самой CMF(когда-то CMS), проект переписывал с нуля как минимум 3 раза, и бесчисленное количество раз отдельные его элементы.

Сначала мне хотелось реализовать просто CMS, где можно было за пару кликов собрать простенький сайт с новостями/статьями и пр., конечная реализация получилась довольно интересной и на ней сейчас живут десятки сайтов, но система была построена так, что ее развитие слишком затруднено из-за ужасной архитектуры и отсутствие ключевых возможностей. Перед ее созданием было исследовано несколько бесплатных CMS и из каждой позаимствованы свои прелести.

Следующая реализация, это тоже CMS, правда до написания админки дело так и не дошло. Я по прежнему также руководствовался удобствами для создания сайтов, но и простором для ее расширения, а точнее удобством для программисты. Главным преимуществом над предыдущей поделкой было то, что система самостоятельно следит за структурой БД. Но по прежнему нужно было много городить однотипного кода для реализации модулей и когда потребовалось реализовать внятную подсистему управления правами пользователей, я попал в тупик.

Текущая реализация радикально отличается от предыдущих. Теперь я больше не стремлюсь к CMS, да и к CMF тоже(то как реализовано большинство известных мне). Теперь задачей стало возможность легкого расширения и переписывание отдельных частей CMF, вплоть до полного изменения логики поведения как отдельных элементов так системы в целом. CMF состоит из 2-х частей, ядра и модулей входящих в состав ядра, и пользовательских модулей/файлов/библиотек и т.д.
Задачи которые лежат на ядре системы:
1. Управление структурой БД и целостностью данных.
2. Управление пользователями и их правами на уровне действий и данных.
3. Доступ к БД.
4. Управление сессиями
5. Ведение статистики по функционированию системы.
6. Валидация данных и генерация форм (только описание, а не представление)
7. Общение между модулями

По поводу последнего пункта, модули не могут напрямую работать друг с другом, т.к. в таком случае не получится "правильной" подсистемы разграничения прав по действиям. Может возникнуть ситуация, что действие пользователю доступно, но это действие внутри в зависимости от параметров вызывает другие и какие либо из этих других могут быть недоступны пользователю.
По этой же причине запрещен непосредственный вызов SQL запросов, обращение осуществляется посредством конструктора запросов.

Цели которые преследуются:
1. Создание стабильной и безопасной CMF на основе которой можно было бы построить несколько CMS под разные задачи.
2. Быстрая заработка модулей прямо в админке.
3. Скорость работы CMF

Тут стоит сказать, что CMS в конечном счете будет являться простой админкой, которая в свою очередь является пользовательским модулем.

CMF не должна ограничивать конечного пользователя какими либо правилами, выбор шаблонизатора, правил формирования страниц сайта, или выбор БД и т.д.

Например сейчас, когда я был в поиске шаблонизатора который мог работать как на стороне клиента, так и на сервере, опробовал 3 разных варианта, и в данный момент разные страница админки формируются на разных шаблонизаторах, а ajax конструктор форм на четвертом . Теперь предстоит нудная работа по приведению этого хаоса к единому знаменателю.

На данный момент многие вопросы не решены. Я пытаюсь вылизывать каждый элемент на столько на сколько мне позволяет мой опыт. Документацию я не пишу, т.к. все очень динамично меняется, пробую использовать кучу разных технологий и подходов.
Помощь начала требоваться когда я вышел за пределы ядра системы, количество направлений, в которых нужно писать код увеличивается очень быстро, да и уровень вопросов которые требуется решать увеличивается.

В общем интересные задачки найдутся и для совсем новичков и для профессионалов.

[mv28jam]

Если ваш проект заточен под создание простых сайтов, без какой либо своеобразной специализации то сомневаюсь, что ваша разработка будет сильно востребована ибо такие есть, и у них есть сообщества.

В общем интересные задачки найдутся и для совсем новичков и для профессионалов.

Я так понимаю безвозмездно?

[Kostia]

Если ваш проект заточен под создание простых сайтов, без какой либо своеобразной специализации то сомневаюсь, что ваша разработка будет сильно востребована ибо такие есть, и у них есть сообщества.

Нет, это не CMS, и заточки под сайты как таковой нет. Функционал ближе к какому либо framework'у, но к сожалению из-за некоторой специфики использовать готовый файмформ нет возможности(за исключением некоторых элементов, которые на удивление реализованы просто отвратительно в некоторых фреймворках), точно также как и назвать мою разработку фреймворком тоже нельзя. Поэтому я ее называю CMF.

Я так понимаю безвозмездно?

Если вы о деньгах, то да. Хотя тут не все так однозначно.
Тут еще стоит упомянуть, что это не просто задания от меня лично, типа делай то, то, то. Это прежде всего обсуждение/решение проблем с последующей реализацией. Можно в принципе не писать код, а только предлагать/обсуждать решения, а уж исполнить я сам смогу )

Приведу немного примеров кода.

Простейший модуль:

PHP код:

Class PHPInfo extends Module {

    protected function __construct()
    {
        $this->regAction("phpinfo", 'phpinfo');
    }

    protected function phpinfo($argv)
    {
        phpinfo();
    }

} 


Если выполнить www.domain.zone/phpinfo и у вас достаточно прав, то вы увидите то самое )

Так выглядит на данный момент описание таблицы:

PHP код:

$this->tables['columns'] = new Table('columns', [
            new Text("name", "255"),
            new Text("type", "16"),
            new Text("length", "16"),
            new Text("default", "255"),
            new Text("collate", "32", Config::base_collation),
            new Text("index", "16", ''),
            new Checkbox("autoincrement"),
            new Checkbox("null")], Table::DATING | Table::ACTIVATABLE, [], ['table' => 'tables']); 


А вот так работа с таблицами:

PHP код:

return $this->tables['tables']->findFirst(['`name`=:table'], [':table' => $argv['table']]);
$this->tables['tables']->delete(['`name`=:table'], [':table' => $argv['table']]);
foreach ($this->tables['tables']->get() as $table){}
... 


Или через конструктор запросов:

PHP код:

Core::db()->cmd()->select(['uid' => 'id', 'user', 'full_name', 'gid' => 'group', 'avatar'])->
                            from($this->tables['users']->name())->
                            where(['`user`=:user', '`password`=:passwd'], [':user' => $argv['user'], ':passwd' => $hash])
                            ->limit(1)->query(); 


Есть модуль который описывает у себя таблица, в которых можно описать таблицы, которые будет создавать движок ). Сейчас занят выносом процесса описания таблиц в админку посредством форм. В общем создаю в некотором смысле админку для разработчиков и стремлюсь к опыту MODx. Эта админка предназначена для создания других админок , точно также как интерпретатор питона пишется на питоне, также будет делаться одна админка с помощью другой )), планируется добавить редактор кода, управление конфигами и т.д.
Хотя на dev админке и можно собрать сайт/приложение и этот процесс будет отчасти схож с MODx, и это плохо для конечного пользователя.
Некоторым достаточно(больше и не нужно) чтобы на каждой странице был только редактор типа tinyMCE и всё )

[mv28jam]

Нет, это не CMS, и заточки под сайты как таковой нет.

Цель? Искусство ради искусства?

Функционал ближе к какому либо framework'у, но к сожалению из-за некоторой специфики использовать готовый файмформ нет возможности(за исключением некоторых элементов, которые на удивление реализованы просто отвратительно в некоторых фреймворках), точно также как и назвать мою разработку фреймворком тоже нельзя. Поэтому я ее называю CMF.

Опять же фреймворк ценен не столько кодом, сколько "коммунити" и обилием готовых решений под него. Если не узкая специализация, то "коммунити"/юниты/бесплатность.

Если вы о деньгах, то да. Хотя тут не все так однозначно.

Деньги либо есть, либо нет.

Тут еще стоит упомянуть, что это не просто задания от меня лично, типа делай то, то, то. Это прежде всего обсуждение/решение проблем с последующей реализацией. Можно в принципе не писать код, а только предлагать/обсуждать решения, а уж исполнить я сам смогу )

Ну и это кстати тоже часто оплачивается. Вон на HighLoad как цены задрали, впрочем не зря.

Простейший модуль:
Если выполнить www.domain.zone/phpinfo и у вас достаточно прав, то вы увидите то самое )

Как реализована работа со ссылками? Они я так понимаю задаются $this->regAction("phpinfo", 'phpinfo'); ?

new Text("default", "255"),

Это какой тип данных char, varchar?

Или через конструктор запросов:

Есть поддержка разных СУБД на уровне ядра?

[waleri]

У меня вопрос несколько не в тему - в чем преимущество использование эдакого конструктора запросов перед написанием простой строки "SELECT ... FROM ... WHERE ..."?

[mv28jam]

У меня вопрос несколько не в тему - в чем преимущество использование эдакого конструктора запросов перед написанием простой строки "SELECT ... FROM ... WHERE ..."?

С точки зрения опытного разработчика такой подход позволяет на уровне ядра переписывать запросы с учётом синтаксиса текущей СУБД, не меняя кода условного юнита, а так же позволяет управлять кешированием запросов.
С точки зрения code nazi девелоперы-быдлокодеры, а так они их привлекут к порядку и вообще так круто тк сложно и непонятно.

[Kostia]

Есть поддержка разных СУБД на уровне ядра?

Пока конструктор есть только для mysql. Реализую посредством PDO. К сожалению воспользоваться yii нет возможности. Хотя возможно мне подскажите.
Цель, если пользователь запрашивает данные, например страницу или список новостей, то он должен увидеть только те, которые соответствуют его правам.

Я долго искал информацию по организации прав, но в веб движках используются очень специализированные подходы. Пытался разобрать систему прав в linux, разобрал, адаптировал и получил что-то типа:
Есть 2 сущности: Пользователь и Группа.
Каждый пользователь привязан к некоторой группе по умолчанию, а также он может входить в несколько групп одновременно.
Группы образуют собой древовидную систему подчиненности, связи могут быть только в направлении вниз, либо замкнуты на самой группе и не могу идти в другую ветку. Таким образом пользователь сможет просматривать все данные которые находятся в группах подчиненных тем, в которых находится сам пользователь.

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

Это какой тип данных char, varchar?

varchar. Вообще эти типы были созданы для текущего удобства, сайчас стал задумываться об их удалении и оставить только класс Type. Было время когда я удалил половину кода из проекта после перестройки логики некоторых моментов и получив решение с меньшим кодом и большей гибкостью )

Как реализована работа со ссылками? Они я так понимаю задаются $this->regAction("phpinfo", 'phpinfo'); ?

В первых версия последнего варианта движка была консоль, похожая на эмулятор терминала в linux ), спустя время он стал не нужен и я его удалил. Сейчас роль этой строки выполняет строка браузера, после того как отпала необходимость выполнения многих команд последовательно. Это не синтаксис ссылок, но сейчас можно вызывать любую функцию движка следующи образом:

/login --user='root' --password='123'
/cms -v
/addtable --name='mytable' --flags='0'
/addcolumn --table='mytable' --name='qwerty' --type='int' ...

При этом если будут переданы недопустимые данные, то валидатор заругается. Также можно попросить вывести список доступных комбинаций параметров для функции, который формируется из данных переданных валидатору.

Если говорить про ссылки, то тут разработчик сам волен выбирать и реализовывать способ обработки ссылок. Я собираюсь реализовать как миниму 2 стратегии. При этом мне очень приглянулась идея использовать pattern matching как в функциональных языках. В этих вопрос я еще сам не до конца разобрался и не совсем полно вижу конечную картину, т.к. совсем недавно вышел за пределы ядра.

Деньги либо есть, либо нет.

Есть заказы, и ооочень много и самые разнообразные. Но даже имея огромное количество инструментов каждый раз приходится решать разные рутинные вещи, которые хочется автоматизировать. Пытался найти быстрые решения в том же yii, codeigniter ... но их там не было )

Цель? Искусство ради искусства?

Надо же чем-то в магистратуре заниматься )

[mv28jam]

Реализую посредством PDO.

PDO в этом не помощник.

Хотя возможно мне подскажите.

Не понял что именно подсказать.
В целом же сложно давать советы если нет цели. Как говорили в великом фильме - http://www.youtube.com/watch?v=2FgWNKgSvqY . Нужно ли это разделение прав, как оно будет работать, зачем оно... одни вопросы. Ввели мы как-то разделение прав, чтобы не воровали данные и для порядку, а как нагрузка попёрла, оказалось что одни проблем от этого, теперь не знаем как от этого разделения легко избавиться...

varchar

Не надо ограничивать разработчика в выборе, от varchar'а часто одни проблемы.

Я собираюсь реализовать как миниму 2 стратегии. При этом мне очень приглянулась идея использовать pattern matching как в функциональных языках. В этих вопрос я еще сам не до конца разобрался и не совсем полно вижу конечную картину, т.к. совсем недавно вышел за пределы ядра.

Это правильно и внимание этому надо больше. Сейчас именно вариативность урлов и ЧПУ являются очень важными элементами для для любой веб системы. Плясок с этим море.

Но даже имея огромное количество инструментов каждый раз приходится решать разные рутинные вещи, которые хочется автоматизировать. Пытался найти быстрые решения в том же yii, codeigniter ... но их там не было )

И не будет, если будут то программисты станут не нужны.

Надо же чем-то в магистратуре заниматься

Опять же возвращаясь - нужна цель. Создать универсальный комбайн можно, но только он не нужен, как опять же говорили в великом фильме - http://www.youtube.com/watch?v=b1yoUtNj9y0 . Я может программирование и люблю, хотя и не хочу себе в этом признаваться, но уже без цели не могу.
Впрочем вы меня заинтересовали, читайте РМ.

[Kostia]

Не надо гораничивать разработчика в выборе, от varchar'а часто одни проблемы.

Это просто все наследники общего типа Type:

PHP код:

class Text extends Type
{
    function __construct($name, $length = "255", $default = "", $index = "")
    {
        parent::__construct($name, "VARCHAR", $length, $default, Config::base_collation, $index, false, $default ? true : false);
    }
} 


Раньше хотел связать экземпляры этих классов с отображением в формах и логикой обработки данных пришедших от формы, собственно так я это и сделал в первой версии движка, но получил жесткие ограничения.
Часто бывает так, что то, что на первый взгляд кажется хорошим решением в конечном счете на практике оказывается весьма ущербным.

Создать универсальный комбайн можно, но только он не нужен

Каррирование в масштабах движка )

[waleri]

Сообщение от mv28jam

С точки зрения опытного разработчика такой подход позволяет на уровне ядра переписывать запросы с учётом синтаксиса текущей СУБД, не меняя кода условного юнита, а так же позволяет управлять кешированием запросов.

А зачем это нужно - разве для этой не существуют стандарты SQL?
Про кеширование вообще не понял, как это влияет.