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

[mv28jam]

А зачем это нужно - разве для этой не существуют стандарты SQL?

Осталось только всех разработчиков СУБД заставить полностью соблюдать стандарты хотя бы SQL92, а разработчиков приложений отказаться от множества удобных функций используемых ими СУБД.
Например как нам велит SQL92 выбирать первые 10 строк из ответа?

Про кеширование вообще не понял, как это влияет.

Бывает...

[Kostia]

А зачем это нужно - разве для этой не существуют стандарты SQL?

Не все так просто =)

[Kostia]

Если никто не против буду спрашивать некоторые моменты в этой теме.

На данный момент я пришел к выводу, что давать доступ к членам классов модулей не нужно:
1. Отсутствие возможности организовать разделение прав по действиям.
2. Концентрирование вызова действий связанных с конкретными методами модулей в одном месте, тут же можно организовать и валидацию передаваемых аргументов.

Например так сейчас выглядит описание действий по созданию таблиц:

PHP код:

        $this->regAction('addTable', 'table', [['name'],[0]]);
        $this->regAction('getTable', 'table', [['table']]);
        $this->regAction('addColumn', 'table', [['table', 'name', 'type', 'length', 'default', 'index', 'collate', 'autoincrement', 'null']]);
        $this->regAction('delTable', 'table', [['table']]);
        $this->regAction('delColumn', 'table', [['table', 'Column']]);
        $this->regAction('setColumn', 'table', [['table', 'Column']]); 


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

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

/addTable "123\"ololo\""
/addTable ""
/addTable --name="#@%^*&"

Все эти вызовы пройдут успешно. Поэтому было решено первым делом ввести валидатор, который проверял бы соответствие входных данных определенным правилам и если все прошло хорошо, то действие вызывается, иначе возвращается список правил, по которым данные не прошли.
Набрасал небольшой прототип класса:

PHP код:

class Validator
{

    protected $rules = [];

    public function __construct()
    {
        $this->rules['required'] = function($data)
        {
            return empty($data) ? false : true;
        };
        $this->rules['numeric'] = function($data)
        {
            return is_numeric($data) ? true : false;
        };
        
        $this->rules['string'] = function($data){
            return is_string($data);
        };
    }

    public function validate($data, $fields)
    {
        $result = [];
        foreach ($fields as $key => $rules)
        {
            foreach ($rules as $rule)
            {
                if (isset($this->rules[$rule]))
                {
                    if(!isset($data[$key]))
                    {
                        $data[$key] = '';
                    }
                    if (!$this->rules[$rule]($data[$key]))
                    {
                        $result[$key][] = $rule;
                    }
                }
                else
                {
                    trigger_error($rule . ': rule is not found!', E_USER_WARNING);
                }
            }
        }
        return $result;
    }

} 


Работает так:

PHP код:

$validator = new Validator();
if (count($res = $validator->validate(
    [
        'name' => [1], 
        'surname' => '', 
        'age' => '45.5',
        'growth' => ''],
    [
        'name' => ['required', 'string'], 
        'surname' => ['required', 'string'],
        'age' => ['required', 'numeric'],
        'growth' => ['required', 'numeric']
        ])) !== 0)
{
    print_r($res);
} 


Вывод:

Array
(
    [name] => Array
        (
            [0] => string
        )
    [surname] => Array
        (
            [0] => required
        )
    [growth] => Array
        (
            [0] => required
            [1] => numeric
        )
)

Эти данные соответственно возвращаются либо в форму в виде json, по путно к ним цепляется локаль, и уже javascript помечает поля в которых пользователь допустил ошибки.
Смысл в этом классе примерно такой же как в filter_var_array.

__Продолжение ниже__

[Kostia]

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

Следующая из 3-х первостепенных на данный момент задач, стоит класс описания форм. В идеале форма должна построиться исходя из действия с которым она связывается. Например форма изменения информации о пользователе, есть объединение 2 действия, которые привязаны к 2-м разным таблицам. prefix_users и prefix_profiles. Выглядеть это должно примерно так: makeForm(['editUser','editUserProfile']); или в строке браузера:

/callList --editUser="--login='lol' --password='что'" --editUserProfile="--surname='Пустота' --age=10"

Исходя из правил валидации данных, а также дополнительных правил будет построен класс формы. Далее этот класс будет направлен во View, что как раз является третьей задачей.
Сейчас описании формы выглядит ужасно в плане гибкости:

PHP код:

$form->title('Add Table')->
            action('addTable')->
            text('name', 'name', 32, $name)->
            checkbox('sortable', 'sortable', $sortable)->
            checkbox('dating', 'dating', $dating)->
            checkbox('activatable', 'activatable', $activatable)
            ->unique(true); 


И вот такой вот ужасный шаблон =)

<div style="display: table;">
	<% for ( index in elements ) { %>
	<div style="display: table-row;">
		<% elem = elements[index]; %>
		<% if (elem.type === 'hidden') { %>
		<input type="hidden" name='<%=elem.name%>' value="<%=elem.value%>"/>
		<% } else if (elem.type === 'text') { %>
		<div align="right" style="display: table-cell;"><%=elem.lable%></div>
		<div style="display: table-cell;"><input value="<%=elem.value%>" type="text" name="<%=elem.name%>" size="16" maxlength="<%=elem.maxlength%>"/></div>
		<% } else if (elem.type === 'checkbox') { %>
		<div align="right" style="display: table-cell;"><%=elem.lable%></div>
		<div style="display: table-cell;"><input <%=elem.checked?'checked=""':''%> type="checkbox" name="<%=elem.name%>"/></div>
		<% } else if (elem.type === 'submit') { %>
		<div align="right" style="display: table-cell;"></div>
		<div align="right" style="display: table-cell;"><input type="submit" name="<%=elem.name%>" value="<%=elem.lable%>"/></div>
		<% } else { %>
		undefined
		<% } %>
	</div>
	<% } %>
</div>

View тоже очень интересная вещь. На данный момент у меня есть опыт использования нескольких шаблонизаторов и написания для них расширений.
1. Smarty (v2) --всеми силами стремиться выправить руки тем, кто пишет javascript в шаблонах
2. Twig
3. Handlebars
4. Simple JavaScript Templating --xD
5. Histone
6. XSLT

В этом направлении хочется сделать следующую штуку. Исходя из того, что ограничивать в выборе шаблонизатора нельзя, а также из соображений оптимизации, т.е. вынос рендеринга некоторых шаблонов за пределы сервера следует, что нужно писать общий интерфейс для модулей View. Например если шаблонизатор не поддерживает исполнение на стороне клиента, то он рендерится на сервере и возвращается готовый html, если запрашиваемый шаблон сверстан отдельно для клиента возвращаются только данные и если JS не кэшаровал шаблон, то и он. Т.е. 3 ситуации:
1. Один шаблон и для клиента и для сервера
2. 2 варианта шаблона, для сервера и для клиента -- этот вариант был опробован очень давно, не хотелось бы повторения
3. только для сервера

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

В качестве шаблонизатора который будет работать как на стороне сервера, так и на стороне клиента был выбран Histone. Его возможности сильно ограничены, например нет наследования шаблонов, но его реализация очень проста и прозрачна. Понравилось что перегоняет шаблон в abstract syntax tree(AST), которую позже удобно использовать в качестве кэша.

[Kostia]

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

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

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

Задача все та же, валидация, описание форм и их представление. Одна из самых сложных форм, которую мне когда либо приходилось делать выглядит так:
http://neepic.net/image/direct?imgSr...79f8825c42.png
Есть мнение, что мне получится реализовать способ описания, которым не умоляя общности можно было просто описать простые формы, а также описывать и такие формы, как на картинке.

Начну с малого, а расти вроде есть куда. Есть некоторое действие, которое добавляет в базу описание таблицы, упрощенно:

$this->regAction('addTable', 'table', [['name','falgs']]);

Если ввести на их тип и длину ограничения, получим:

[
'name'=>[type=>'char(255)'],
'falgs'=>[type=>'int(3)']
]

под int(3) будем понимать целое длиной в 3 бита, т.е. (0 <= x <= 7) или (-3 <= x <= 3). При этом, это не конечный тип., значение которого попадет в базу, над ним будет выполнено еще одно преобразование, где и будет проведена валидация на длину.
Задав типы и их длины, можно ввести отображения этих типов, в разные элементы формы, опишем функцию отображающую строковые типы в тип text(n)(s):

text : char(n)(s) -> text(n,s)
text : varchar(n)(s) -> text(n,s)

Также введем отображение для флагов:

flag : int(n)(value) -> [bool(bit(n,value)), bool(bit(n-1,value)), bool(bit(n-2,value)) ..., bool(bit(1,value))]

Для конкретно нашей задачи будут порождены 2 отображения:

text : char(255)(s) -> text(255,s)
flag : int(3)(value) -> [bool(bit(3,value)), bool(bit(2,value)), bool(bit(1,value))]

Для пустых значений получим не инициализированные типы, т.е. форма будет пустой. Если данные будут правиться, то форма будет заполнена в соответствии с ними.
Далее во View определим отображения для списка и текста. Это в общем то просто шаблоны и в результате должны получить вот такую форму:
http://neepic.net/image/direct?imgSr...d109423142.png

Теперь самое главное. Отображение должно быть биективным, а также должно существовать обратное отображение.

Пример простых отображений:

required : T(val) -> T(val) | Nothing
is_string : char(n)(val) -> char(n)(val) | Nothing
is_string : varchar(n)(val) -> varchar(n)(val) | Nothing

Примеры прямых и обратных отображений:

email : char(n)(s) -> text(n)(s)
email^-1 : text(n)(s) -> char(n)(s) | Nothing

flag : int(n)(value) -> [bool(bit(n,value)), bool(bit(n-1,value)), bool(bit(n-2,value)) ..., bool(bit(1,value))]
flag^-1 : [bool(a), bool(b), bool(c), ...] -> int(n)(val)

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

Что получаем в конечном итоге:

[
'name'=>[type=>'char(255)', 'forward'=>[new text(255)], 'back'=>[new required()]],
'falgs'=>[type=>'int(3)', 'forward'=>[new flag(3)]]
]

Конечно все это только мысли, на практику я еще не переходил. Я не указываю back преобразование для text и flag, из-за введенных выше ограничений, всегда должно существовать обратное отображение. Например required не меняет тип значения, при этом оно будет автоматически вычислено из forward, т.е. мы получим:

required -> text(255,s) -> text(255,s) | Nothing
text^-1 : text(255,s) -> char(255)(s)
flag^-1 : [bool(a), bool(b), bool(c)] -> int(3)(falgs)

Nothing для required возникает в ситуации если empty(s), вычисления прекращаются, валидатор получает информацию о том, какое отображение не прошло, и дальше по накатанной ). При этом очень интересно, например если required засунуть в forward, то получится юзер не увидит форму пока что-то там не добавит. Например невозможно добавить пост, если нет темы и т.д.

Далее возможно усложнение структуры описания, например объединение нескольких типов в один метатип(контейнер), для группировок при отображении. Введение различных штук для описания динамических форм, содержание которых будет менять по мере введения новых данных и т.д.

[Kostia]

Мне все также требуется помощь!

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

Пример:

PHP код:

$fn = function ($args){return $args['u'] + $args['v'];};

$act = new Action('sum', 'main', $fn);
$act->param(new IntType('u'), [new is_numeric(), new required()])
    ->param(new IntType('v'), [new is_numeric(), new required()]); 


Я решил избавиться от указания from и to преобразований в описании, в виду того, что можно легко записать преобразование с помощью лишь одной цепочки )
is_numeric и required выполняют проверку только в одном направлении (from), в случае с to, вход отображается сам в себя всегда.
Типы у преобразований я также не указываю, они вычисляются сами, но можно их задать вручную:

PHP код:

[new is_numeric(new IntType()), new required(new IntType())] 


is_numeric здесь является излишним, т.к. если создание типа с входным значением пройдет не успешно, т.е.

PHP код:

                $type = end($param['transform'])->outType();
                if (isset($args[$name]))
                {
                    $type->setValue($args[$name]);
                } 


То если $args[$name] не подойдет, то $type->setValue($args[$name]); вернет false, а также $type->error(), вернет не пустой массив. Получится ошибка типа, еще до начала преобразований.
Типы делятся 2 подтипа, те что умеют "отображаться", и те что нет. На самом деле никаких шаблонов или html нет, просто у одних типов можно получить описание для дальнейшего его отображения в форме или таблице(html) с данными, а другие нет.
Например для такого действия:

PHP код:

$act->param(new TextView('field1'), [new required()])
    ->param(new TextView('field2'), [new required()]); 


Получается вот такое описание:

PHP код:

Array
(
    [field1] => Array
        (
            [name] => field1
            [type] => text
            [length] => 255
        )

    [field2] => Array
        (
            [name] => field2
            [type] => text
            [length] => 255
        )
) 


Все это простейшие примеры, которые пока далеки от практики, но думаю все еще впереди.
Также планирую создать что-то типа фабрики параметров (приглянулся prototype pattern) для уменьшения повтора кода, рассматриваю даже способ описания параметров с помощью строки со всякими суффиксами и префиксами, типа "textv_req", "intt_num_req" и т.п.
Любое действие можно вызвать напрямую, без преобразований и проверки типов с помощью $act->direct_call($args), такое возможно только внутри модулей для повышения производительности.
Также будут реализованы классы(интерфейсы) типов, числовые, строковые и т.д.

PHP код:

interface Bool{}
interface Int{}
interface Num{}
interface Text{}
interface BigText{}
interface Container{}
... 


Это будет использовано для введения ограничений некоторых преобразований, например преобразование flags принимает любой тип принадлежащий классу Int а возвращает тип принадлежащий сразу двум классам Container и Bool, а точнее возвращает конкретный тип BoolList. Также это будет использоваться для ограничений выбора возможных преобразований в конструкторе форм.
В идеале хочется довести все до мышкотыканья в процессе описания будущего сайта и всех его сущностей и при этом удобного )

Модель сущностей требует отдельного разговора.

[Kostia]

Сущности.

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

Наследование сущностей, одна из сильных сторон, которую собираюсь реализовать в движке. Например в большом интернет магазине могут быт товары из разных категорий, да и вообще может быть несколько прилавков(магазинов на одном скрипте), товары которых могут пересекаться, а могут и нет.
Например у магазина компьютерных компонентов, могут существовать товары разных категорий: материнские платы, процессоры, видеокарты, жесткие диски и т.д. Все они являются товарами и обязаны иметь цену и например вес, все базовые параметры добавляем в базовую(абстрактную) сущность "товар" и все остальные товары наследуем от нее. Далее можно описать логику покупки товаров, не вдаваясь в подробности о том, что это за товар. Также реализуем общую для всех логику сравнения товаров относящихся к одной и той же категории. А если пойти еще дальше, то можно реализовать и функцию сбора компьютера из имеющихся комплектующих, например пользователь задает ограничения виде цены, процессора, объема памяти, а все остальное система подбирает автоматически.

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

Примерно так это себе представляю. Посмотрю что получится, будет неудобно, придется искать другие идеи и решения )

[Gorychev]

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

В любом случае подобный функционал нужно подключать отдельным модулем. Собственно одно из главных условий для подобных систем это модульность и простота и прозрачность кода.
Мне кажется, вы многое чего перемудрили. Получится сложный код который трудно будет модифицировать и перетягивать из проекта в проект. Хотя многое зависит от самой структуры системы. Можно код на посмотреть?
Я тоже писал свою cms, но я не заморачивался на столь сложную систему, тк. всего все равно не предусмотришь и нужно будет допиливать код. Просто взял за основу зенд, его mvc структуру, написал сайт, админку под нужды конкретного проекта. Потом в следующих проектах выкидывал ненужные модули и дописывал недостающие. Хотя сейчас бы я взял один из микрофреймворков за основу. Зенд тяжеловат. С базой данных совсем не заморачивался, написал простенький класс, который принимает sql запросы и выдает результат. Есть же куча готовых ORM, зачем придумывать велосипед, тратить на это время и силы. Хотя вот как по мне, PDO + нативные sql запросы это самое то. Любая ORM это минус к быстродействию.
Мне кажется, вы какого-то монстра городите.

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

Я бы сделал просто. В таблице коментов добавил индексируемое int поле service_type и поле int service_id. Для новостей допустим service_type это – значение 1, для товаров -2… а service_id – это id новости или товара . У каждого модуля в модели написал метод, например для новостей:

PHP код:

public function getCommentsByNewID($iNewID){
    $CMNT = new CommentsModel();
    return $CMNT-> getCommentsByServiceTypeAndServiceID($iNewID, 1);
} 


В модели комментариев, общей для всех модулей:

PHP код:

public function getCommentsByServiceTypeAndServiceID($iServiceID, $iServiceType){
    $sSql = "SELECT * FROM `comments` WHERE `service_type` =  $iServiceType AND `service_id` = ".(int) iServiceID;
    return возврат результата запроса;
} 


Соответственно дописать добавление коментов с учетом service_type.

[Kostia]

Хотя вот как по мне, PDO + нативные sql запросы это самое то

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

Я бы сделал просто. В таблице коментов добавил индексируемое int поле service_type и поле int service_id. Для новостей допустим service_type это – значение 1, для товаров -2… а service_id – это id новости или товара . У каждого модуля в модели написал метод, например для новостей:

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

В любом случае подобный функционал нужно подключать отдельным модулем.

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

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

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

PHP код:

array(
                    "name" => "site_video_categories",
                    "parent" => array(),
                    "type" => "material",
                    "options" => array(
                        "timemodify" => true,
                        "plural" => true,
                        "publishing" => true,
                    ),
                    "title" => "Управление категорями",
                    "description" => "Добавление,удаление,редактирование категорий видео.",
                    "edit" => "Редактирование категории",
                    "fields" => array(
                        array(
                            "output" => true,
                            "obligation" => true,
                            "search" => true,
                            "name" => "title",
                            "title" => "Заголовок категории",
                            "type" => "text",
                            "default" => "Без названия",
                            "uparams" => array("lenght" => "255")
                        ),
                    ),
                    "depend" => array(),
        ) 


А дальше описание для site_video, которое зависит от site_video_categories. И получаем модуль видео на сайте, которое можно засунуть в разные категории, потом простецки описываем компонент, например при добавлении компонента на страницу, автоматом создается категория для видео и можно кидать туда свои видеозаписи, например компонент видеокарусель так делает, а к компоненту привязан шаблон где и происходит отображение. Тогда мне это казалось хорошим решением, но было это ~3 года назад. Вот примеры того, что можно собрать из базовых элементов: "100domenov.com/Готовые сайты".

Мне кажется, вы какого-то монстра городите.

Так и есть. Иначе я скачал бы MODx например, и городил на нем чанки со сниппетами ^__^

Я много заимствуют от Линукса при построении системы. Например разделение по правам, это адаптация того что есть в линуксе). Также собираюсь реализовать систему пакетов, подобную dpkg, ведь не все состоит из модулей, есть и просто всякие штуки, типа js библиотек, php библиотек, и т.д. Например одним шаблонизатором могут управлять разные модули ) А под модулем понимается не новости или комментарии, а штуки очень специализированные. Например модуль управления сессиями, управление пользователями и правами, доступ к базе данных и т.д. Хотя можно и новости со статьями городить в виде модулей.

[Kostia]

Вот примеры того, что можно собрать из базовых элементов: "100domenov.com/Готовые сайты".

При этом никакой верстки, просто тычим по компонентам и тащим туда куда нужно, настраиваем и получаем )