Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
> Конечно же в такого способа есть и свои недостатки: из за постояной постройки очередей понижается быстродействие
По моему это ключевая фраза.
Самописные движки чем выгодно отличаются от уже готовых решений — их скорость работы выше (в случае если мы имеем дело с программистом у которого прямые руки).
А в Вашем варианте мы получаем:
1. Да, движок легко расширяем, но расширения под него надо писать
2. Новые люди которые приходят на фирму должны разбираться в неизвестном коде.
3. Что самое главное — нету прироста в скорости.
Может я конечно не прав, но смысла я не вижу.
По моему это ключевая фраза.
Самописные движки чем выгодно отличаются от уже готовых решений — их скорость работы выше (в случае если мы имеем дело с программистом у которого прямые руки).
А в Вашем варианте мы получаем:
1. Да, движок легко расширяем, но расширения под него надо писать
2. Новые люди которые приходят на фирму должны разбираться в неизвестном коде.
3. Что самое главное — нету прироста в скорости.
Может я конечно не прав, но смысла я не вижу.
1) То, что вы говорите в контексте CMS, стало понятно только когда увидел теги в конце статьи.
2) Рассматривали ли вы готовые реализации такого в механизма в существующих CMS?
2) Рассматривали ли вы готовые реализации такого в механизма в существующих CMS?
Я не особо пытался найти существующее решение, так как хотелось написать свое.
В таком случае статью стоит рассматривать только с точки зрения академического интереса, о чем следовало бы указать.
Собственно, ничего нового в подходе нет, autoload классов в php используют давно (см Zend, Yii etc), поэтому интереснее было бы посмотреть, чем ваш подход лучше других (скорость, простота, гибкость) и т.п.
К слову, в Magnolia CMS механизм подключения/отключения модулей работает из коробки. Более того, там реализован механизм версионности модулей (модуль может делать докат/откат версии с соответствующими изменениями в инфраструктуре данных и своих настройках). Можете посмотреть в эту сторону.
Собственно, ничего нового в подходе нет, autoload классов в php используют давно (см Zend, Yii etc), поэтому интереснее было бы посмотреть, чем ваш подход лучше других (скорость, простота, гибкость) и т.п.
К слову, в Magnolia CMS механизм подключения/отключения модулей работает из коробки. Более того, там реализован механизм версионности модулей (модуль может делать докат/откат версии с соответствующими изменениями в инфраструктуре данных и своих настройках). Можете посмотреть в эту сторону.
Имхо, гораздо проще использовать autoload (спасибо добрым хабрачеловекам, подсказавшим мне это в свое время :-) ).
Если не нужно ориентироваться на создание CMS с базой плагинов и их загрузкой/обновлением в онлайн (как в Wordpress или Modx Revo), то имя автора, описание и др. можно запихать прямо в класс, статическими переменными. Учет зависимостей можно вести также внутри класса, запрашивая у движка объекты нужных классов и выдавая ошибку, если они не найдены.
Если же будет онлайн база модулей, то действительно лучше использовать какие-то манифесты. Правда, просто как дополнительное описание, а не функциональный элемент, ведь парсить их каждый раз — дело долгое.
Возможно, выше я написал бред (потому что не писал в этом плане ничего особого, кроме простого фреймворка), но сейчас слегка дельно попридираюсь. У вас код написан слегка… велосипедисто, что ли. Например, функция isInArray в core/lib/array.php выполняет, как мне кажется, те же функции, что и array_search, addChar в core/lib/string.php — str_pad, а про calc там же я вообще промолчу. В самом начале файла core/engine.php встречается такое:
Ну и еще много чего, к чему можно придраться :-)
Если не нужно ориентироваться на создание CMS с базой плагинов и их загрузкой/обновлением в онлайн (как в Wordpress или Modx Revo), то имя автора, описание и др. можно запихать прямо в класс, статическими переменными. Учет зависимостей можно вести также внутри класса, запрашивая у движка объекты нужных классов и выдавая ошибку, если они не найдены.
Если же будет онлайн база модулей, то действительно лучше использовать какие-то манифесты. Правда, просто как дополнительное описание, а не функциональный элемент, ведь парсить их каждый раз — дело долгое.
Возможно, выше я написал бред (потому что не писал в этом плане ничего особого, кроме простого фреймворка), но сейчас слегка дельно попридираюсь. У вас код написан слегка… велосипедисто, что ли. Например, функция isInArray в core/lib/array.php выполняет, как мне кажется, те же функции, что и array_search, addChar в core/lib/string.php — str_pad, а про calc там же я вообще промолчу. В самом начале файла core/engine.php встречается такое:
$ext = explode(".", $file);
$ext = $ext[count($ext)-1];
if ($ext == "php") {
include_once $filePath;
}$path = pathinfo($file);
if ($path['extension'] == 'php' {
include_once $filePath;
}$min = 9999999999;
...
if (count($v) <= $min){$min = false;
...
if ($min === false || count($v) <= $min){Ну и еще много чего, к чему можно придраться :-)
Ваша правда, там очень к многому можно придраться.
На счет isInArray скажу — в php как-то очень много функций, и мне кажется, что человеку их вообще запомнить не очень реально. Да, сейчас я знаю о in_array (теперь узнал о array_search), calc не доработан совсем, да и вообще там достаточное количество мусора, не задействованных функций и участков кода, которые выкинуть жалко, а дорабатывать нет смысла.
Когда я все это писал — я совсем не думал (точнее не ориентировался) на широкое использование, скорее это был интерес написать что-то более утонченное, чем просто «плоский» скрипт.
Сейчас я бы мог написать лучше, но перешел на великолепный Python и Django.
На счет isInArray скажу — в php как-то очень много функций, и мне кажется, что человеку их вообще запомнить не очень реально. Да, сейчас я знаю о in_array (теперь узнал о array_search), calc не доработан совсем, да и вообще там достаточное количество мусора, не задействованных функций и участков кода, которые выкинуть жалко, а дорабатывать нет смысла.
Когда я все это писал — я совсем не думал (точнее не ориентировался) на широкое использование, скорее это был интерес написать что-то более утонченное, чем просто «плоский» скрипт.
Сейчас я бы мог написать лучше, но перешел на великолепный Python и Django.
Запомнить может и не реально (про in_array, например, я сейчас и сам забыл), зато можно пользоваться документацией, в которой есть краткие описания функций и деление по разделам.
В скриптовых языках есть простое правило: если есть стандартная функция, то лучше использовать ее, а не собственную реализацию, иначе проиграете в скорости.
Это тоже велосипедисто.
Вот так короче:
$path = pathinfo($file);
if ($path['extension'] == 'php') {Вот так короче:
if (strrchr($file,'.') === '.php') {
Почему бы не использовать фреймворки? Результат аналогичен вашему, но при этом вы экономите уйму времени.
Если говорить о движке, написанном «для себя», то, на мой взгляд — самое важное это удобство его поддержки и расширения. Вторым важным моментом является скорость разворота движка на новом сайте.
ВРЕМЯ РАЗВОРОТА
Начну со второго пункта: сколько времени занимает разворот вашего движка на новом сайте?
В моем понимании время разворота движка на новом сайте включает в себя три стадии:
1) разворот базовой версии — создание файлов, папок, создание структуры БД, возможно — выбор начальной конфигурации модулей, идеально — делать это автоматизированно.
2) Натягивание дизайна для заказчика — видимо, за это отвечает модуль template, однако вопрос к вам: шаблон (я имею ввиду сам html-код) с формой, например для логина пользователя — это часть модуля template или auth?
3) докрутка стандартных модулей под желания заказчика — часто чисто внешнего вида, но иногда по желанию заказчика к модулю добавляется новая интересная возможность
Отдельно идет написание новых модулей по заказу или просто в порыве вдохновения. Во время разворота это не включается.
ПОДДЕРЖКА ДВИЖКА
Теперь более интересный вопрос.
Если говорить о CMS, тогда нужно говорить об организации исходного кода и ведении общего репозитория (git или svn — не важно) для разных проектов.
Допустим, у вас есть движок в начальном состоянии его развития. Появляется первый клиент, вы делаете для него сайт, попутно добавляя новые фичи в движок. Проект сдали, выпили шампанского (или пива) и подняли вопрос — а вот мы в модуле [MODULE_NAME] добавили такую прикольную фичу, давайте включим это в базовую версию движка? Но при этом тот же модуль содержит ряд кастомизаций, специфичных для клиента, которые нет смысла вносить в общее решение.
Как вы разрешаете (или планируете разрешать) подобные вопросы?
Собственно, для себя я пока вижу только одно интересное решение — организация исходного кода так, чтобы можно было выделить в чистом виде код модуля и хранить все их в одном репозитории, на который ссылаться из каждого отдельного проекта (не знаю, есть ли понятие ссылок в git, но в svn есть и довольно удобно), а все кастомизации вносить в переопределенный класс, который хранится в репозитории заказчка (условно).
Вы не думали о таком структурировании?
ВРЕМЯ РАЗВОРОТА
Начну со второго пункта: сколько времени занимает разворот вашего движка на новом сайте?
В моем понимании время разворота движка на новом сайте включает в себя три стадии:
1) разворот базовой версии — создание файлов, папок, создание структуры БД, возможно — выбор начальной конфигурации модулей, идеально — делать это автоматизированно.
2) Натягивание дизайна для заказчика — видимо, за это отвечает модуль template, однако вопрос к вам: шаблон (я имею ввиду сам html-код) с формой, например для логина пользователя — это часть модуля template или auth?
3) докрутка стандартных модулей под желания заказчика — часто чисто внешнего вида, но иногда по желанию заказчика к модулю добавляется новая интересная возможность
Отдельно идет написание новых модулей по заказу или просто в порыве вдохновения. Во время разворота это не включается.
ПОДДЕРЖКА ДВИЖКА
Теперь более интересный вопрос.
Если говорить о CMS, тогда нужно говорить об организации исходного кода и ведении общего репозитория (git или svn — не важно) для разных проектов.
Допустим, у вас есть движок в начальном состоянии его развития. Появляется первый клиент, вы делаете для него сайт, попутно добавляя новые фичи в движок. Проект сдали, выпили шампанского (или пива) и подняли вопрос — а вот мы в модуле [MODULE_NAME] добавили такую прикольную фичу, давайте включим это в базовую версию движка? Но при этом тот же модуль содержит ряд кастомизаций, специфичных для клиента, которые нет смысла вносить в общее решение.
Как вы разрешаете (или планируете разрешать) подобные вопросы?
Собственно, для себя я пока вижу только одно интересное решение — организация исходного кода так, чтобы можно было выделить в чистом виде код модуля и хранить все их в одном репозитории, на который ссылаться из каждого отдельного проекта (не знаю, есть ли понятие ссылок в git, но в svn есть и довольно удобно), а все кастомизации вносить в переопределенный класс, который хранится в репозитории заказчка (условно).
Вы не думали о таком структурировании?
0. Описано сумбурно, понять тяжело, но возможно
1. Как заметили выше — «велосипедисто», что в вашем случае («интерес написать что-то более утонченное» (с)) абсолютно поощряемо ;)
3. Рассмотрите возможность оформления манифеста в *.php, т.к. ini не совсем безопасен в докруте
4. Архитектура подразумевает некоторую связность модулей, их жесткую зависимость друг от друга (тот же require в манифесте). Не задумывались над уменьшением связности?
1. Как заметили выше — «велосипедисто», что в вашем случае («интерес написать что-то более утонченное» (с)) абсолютно поощряемо ;)
3. Рассмотрите возможность оформления манифеста в *.php, т.к. ini не совсем безопасен в докруте
4. Архитектура подразумевает некоторую связность модулей, их жесткую зависимость друг от друга (тот же require в манифесте). Не задумывались над уменьшением связности?
Если модуль новостей хранит их в mysql — то как он будет работать без? И главное — зачем?
А если использование какого-то модуля опционально — можно просто проверить его наличие в системе внутри самого модуля.
А если использование какого-то модуля опционально — можно просто проверить его наличие в системе внутри самого модуля.
*.txt, кстати, тоже небезопасен — shadowprince.ru/permissions.txt
Ребята, парню 16 лет. Для него это высота. Некоторые и в 30 хуже проектируют и пишут.
function isInArray($array, $el){
if (!count($array)) return false;
foreach ($array as $val){
if ($val == $el) return true;
}
}
function getValPos($array, $el){
if (!count($array)) return false;
foreach ($array as $key => $val){
if ($val == $el) return $key;
}
}
Дальше читать не стал.
— вместо !count($array) было бы логичнее использовать is_array($array), потому что, например, строка (не массив, но по-сути массив) или число вполне пройдут сквозь;
— для функции isInArray уже есть реализация в самом PHP: in_array — параметры теже, только в другом порядке;
— для функции getValPos тоже есть готовая реализация: array_search — параметры как и в in_array;
— оформление: странно, что используются два стиля: для короткого if'a фигурные не используются (тоже так пишу — удобно), а вот для foreach'a — нет.
ShadowPrince, перед тем, как начать реализовывать очередную примитивную функцию, проверьте, есть ли уже готовая, и более быстрая, ее реализация в интерпретаторе. php.net — в помощь.
— для функции isInArray уже есть реализация в самом PHP: in_array — параметры теже, только в другом порядке;
— для функции getValPos тоже есть готовая реализация: array_search — параметры как и в in_array;
— оформление: странно, что используются два стиля: для короткого if'a фигурные не используются (тоже так пишу — удобно), а вот для foreach'a — нет.
ShadowPrince, перед тем, как начать реализовывать очередную примитивную функцию, проверьте, есть ли уже готовая, и более быстрая, ее реализация в интерпретаторе. php.net — в помощь.
— вместо !count($array) было бы логичнее использовать is_array($array), потому что, например, строка (не массив, но по-сути массив) или число вполне пройдут сквозь;
Лучше вообще на входе в функцию указывать очевидный тип данных для передаваемого параметра.
— оформление: странно, что используются два стиля: для короткого if'a фигурные не используются (тоже так пишу — удобно), а вот для foreach'a — нет.
Поддерживаю! Я вообще считаю, что любую конструкцию предусматривающую использование фигурных скобок, нужно использовать с фигурными скобками. На эту тему уже было много дискуссий.
> Лучше вообще на входе в функцию указывать очевидный тип данных для передаваемого параметра.
В PHP нестрогая типизация. Т.е. нельзя сказать «function foo(int $bar) {}». Но можно спиливать некорректные вызовы при помощи проверок параметров в теле самой функции: «function foo($bar) { if(!is_int($bar)) return false; }»
В PHP нестрогая типизация. Т.е. нельзя сказать «function foo(int $bar) {}». Но можно спиливать некорректные вызовы при помощи проверок параметров в теле самой функции: «function foo($bar) { if(!is_int($bar)) return false; }»
Я вас обрадую, в случае с массивами и объектами это работает.
<?php
function test(array $array)
{
var_dump($array);
}
test('test');
?>
if(!is_int($bar)) throw new BadTypeArgumentException;:)
Как меня задолбало анализировать эти false конструкциями типа
if (($res = foo($bar)) !== FALSE) {
// Делаем что-то полезное с $res
} else die("Всё плохо");Настолько, что иногда думаешь, что лучше бы на C++ продолжал писать под веб.
В свое время, читал похожее на xpoint
Мама-мия! Какой ужас-то! 2012 год подходит, тут конец света, а вы пишете такое, что не расширяется и не дописывается.
Возьмите на выходных и откройте для себя MVC (HMVC), про паттерны для расширения посмотрите EventListener, Behavior и т.п.
А этот велосипед выкиньте, он ужасен.
Возьмите на выходных и откройте для себя MVC (HMVC), про паттерны для расширения посмотрите EventListener, Behavior и т.п.
А этот велосипед выкиньте, он ужасен.
Вообще, конечно, подход и код кишит делетантизмом, однако стоит учесть, что человеку действительно 16 лет. И умные книжки про идеальный код и паттерны, для него, ещё впереди.
А за стремление, в любом случае, плюс.
А за стремление, в любом случае, плюс.
С одной стороны в коде детский сад. Не хочется поощрять говнокод — поэтому поставлю минус. С другой стороны, если прочитает несколько умных книг, посмотрит на фреймворки разные ShadowPrince, то я уверен — у него всё получится. Хочется поддержать ShadowPrince — поэтому поставлю плюс.
Так и сделал.
Так и сделал.
Ну вы гуру даете. Накинулись на человека.
Тут важно понимать:
1) Пилить что-то совое интересно и самое главное позновательно;
2) Человеку 16 лет. Что вы писали в 16 лет? Модульные движки на php?
3) Он сам придумал архитектуру, не смотря на аналоги (из каментов), это достойно уважения.
4) Код в опенсорусе.
Посту плюсанул, карму плюсанул, я за любую движуху, кроме голодухи. Минисующие посту — стыдитесь.
Тут важно понимать:
1) Пилить что-то совое интересно и самое главное позновательно;
2) Человеку 16 лет. Что вы писали в 16 лет? Модульные движки на php?
3) Он сам придумал архитектуру, не смотря на аналоги (из каментов), это достойно уважения.
4) Код в опенсорусе.
Посту плюсанул, карму плюсанул, я за любую движуху, кроме голодухи. Минисующие посту — стыдитесь.
> 1) Пилить что-то совое интересно и самое главное позновательно;
Полностью согласен.
> 2) Человеку 16 лет. Что вы писали в 16 лет? Модульные движки на php?
Я писал, и именно модульные движки. Придерживался жесткого разделения дизайна и логики, все запросы htaccess'ом заворачиваются на одну входную точку, блоки движка разложены в виде дерева, и прочее-прочее; вообщем все по фен-шую. Надо бы мне написать статью в песочницу…
> 3) Он сам придумал архитектуру, не смотря на аналоги (из каментов), это достойно уважения.
Честно говоря, на аналоги смотреть надо было. Если трудно читать про парадигмы (мне лично, было), то нужно посмотреть как сделаны популярные CMS (DLE, Joomla, и пр.).
> 4) Код в опенсорусе.
Код практической пользы не имеет, т.к. архитектура явно не продумана. Автор, видимо, вообще не заморачивался с оптимизацией — одно «Читаем все папки /mod/» чего стоит. Но вообщем, выкладывание кода имеет немалую пользу для общества; если бы все выкладывали свой код — было бы неплохо. За это жирный плюс.
Полностью согласен.
> 2) Человеку 16 лет. Что вы писали в 16 лет? Модульные движки на php?
Я писал, и именно модульные движки. Придерживался жесткого разделения дизайна и логики, все запросы htaccess'ом заворачиваются на одну входную точку, блоки движка разложены в виде дерева, и прочее-прочее; вообщем все по фен-шую. Надо бы мне написать статью в песочницу…
> 3) Он сам придумал архитектуру, не смотря на аналоги (из каментов), это достойно уважения.
Честно говоря, на аналоги смотреть надо было. Если трудно читать про парадигмы (мне лично, было), то нужно посмотреть как сделаны популярные CMS (DLE, Joomla, и пр.).
> 4) Код в опенсорусе.
Код практической пользы не имеет, т.к. архитектура явно не продумана. Автор, видимо, вообще не заморачивался с оптимизацией — одно «Читаем все папки /mod/» чего стоит. Но вообщем, выкладывание кода имеет немалую пользу для общества; если бы все выкладывали свой код — было бы неплохо. За это жирный плюс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка модульного движка на PHP