Новая структура и новые конфиги
В движке наметились кое какие архитектурные изменения. А именно:
Новая система конфигов позволит гибко управлять ими из любой точки движка. Также появилась возможность легкого пользовательского переопределения конфига.
Все эти нововведения призваны расширить и в тоже время упростить работу с движком.
- изменение структуры каталогов, вынос ядра в отдельный каталог
- новая система конфигов через массивы
Новая система конфигов позволит гибко управлять ими из любой точки движка. Также появилась возможность легкого пользовательского переопределения конфига.
Все эти нововведения призваны расширить и в тоже время упростить работу с движком.
89 комментариев
Не получится, там находится tiny_mce, которые должны лежать внутри DOCUMENT_ROOT. Остальное — да, можно и нужно.
Радует направление движения проекта в сторону создания универсального движка для практически любого функционала, спасибо!
в конфиге для этого появилась настройка — web путь до /engine/lib/. Это может быть как текущий сервер так и другой сервер, где доступ по http имеет только каталог /lib/. Есть разные варианты, по дефолту /engine/ будет лежать в корне проекта
вчера вечером только думал — как бы убрать за корень папку с блогом.
Если смотреть на CI, то лучше — KohanaPHP (это самостоятельная ветка CI), но тут обратная проблема — слишком быстрое развитие — дока сильно отличается от реального состояния вещей.
Неужели это плохо?! Это наоборот показывает что есть стабильность и уверенность в своих релизах. И девелоперы довольны.
НА ЦИ написано много крупнейших проектов с миллионной аудиторией. И все шустрит и без дыр.
Поэтому ЦИ — как по мне лучший выбор для разработчика кто не гоняется за «аля модными движками», а кто берет за основу качество, гибкость и легкость.
ядро, реализующее модель MVC, промежуточный уровень, содержащий базовые модули (блоги, топики и т.д.), и собственно уровень приложения.
А, вообще, при желании можно кучу уровней придумать :)
Мне же кажется правильным из базового функционала ЛС выделить ядро — некий фреймворк, который сам по себе не является какой-то готовой системой, но которую реальные программеры могли бы использовать для создания любых своих проектов, в т.ч. и никак не связанных с блогами и проч.
Я, например, сейчас ковыряю ЛС именно с этой точки зрения — думаю, не сделать ли на его базе некий простой фреймворк. Иногда для какого-нить не шибко навороченного сайта всякие там Zend и CodeIgniter слишком навороченные и тяжелые. Чего из пушки по воробьям палить?
«выпив прявитель, надо выпить и закрепитель — любой процесс должен быть завершен» (с)… :)
Я все же надеюсь, что позиционирование сохранится… В специализации сила.
И возникает вопрос что будет с платными модулями, который куплены и поставлены на 0.3.1. их сильно придется переделывать, чтобы заработали на будущей версии 0.4 финал?
А вообще, я думаю, что изменения повлияют сильно. Насколько сильно — это будет ясно, когда будет релиз. Я по своим модулям могу сказать — вряд ли они будут работать в новой версии вообще без изменений.
Но что как-то от ваших слов не шибко спокойно.
Щас собирать сайт на 0.3.1, дописывать функционал, ставить платные модули, допиливать функционал этих модулей и самое главное вкладывать денежку.
Спустя какое-то время все сначала.
Вот блин… ))) как быть?
Вот до единицы дойдет — тогда, думаю, не будет так круто меняться. А пока это неизбежно и даже благостно.
Ребенок, когда растет, одежду тоже новую часто покупать приходится. :)
Я пока сайт на 0,31 сделал и «обвеску» самую минимальную провел. Честное слово, большинству сайтов шибко много и не надо, если разобраться. Так что у меня переезд пройдет легко.
ort и kachayev, т.е. движемся в два раза быстрей. ;)
или это временно?1) Добавить расширенные правила роутинга. Сейчас задается жесткая связка — site.com/route/ => ActionSomething.class.php. В идеале было б классно, если б route можно было бы задавать регэкспом. Или (если это покажется расточительным), хотя бы в виде site.com/route*/ => ...
2) Предложение спорное, но все же озвучу: изменить терминологию. По сути, то, что сейчас называется Action — это Controller. Роутер — он и есть роутер, который определяет, какому контроллеру передать на обработку урл. Во всяком случае в больших фреймворках подход как раз такой. Я понимаю, что это вызовет дополнительные проблемы с совместимостью версий 0.3 и 0.4, но раз все равно их не избежать, может, стоит пойти на такой шаг?
По роутингу: евенты сейчас и так можно определять регэкспом. А нужно ли регексп для определения Action`а — тут спорный вопрос. В таком случае роутер вообще нужно расширять — по аналогу зендовского — переносить на него задачу распределения не только Action (читай Controller), но и Event (читай Action). Естественно, это даст больший просто для действий, но со своими проблемами.
На заметку: работа роутера на svn поменялась — подстроена под новые конфиги. Теперь в роутер введено понятие внутреннего Rewrite, и из шаблона убраны все константы, адреса определяются через smarty-плагин (я описывал в одной из своих заметок, с небольшими изменениями). Теперь можно без проблем менять адресацию во всем проекте одной строчкой кода. Т.е. работы в этом направлении ведутся.
А по поводу роутера — переносить на него распределение Event (по-нонешнему) не стоит. Тут у ЛС как раз бОльшая гибкость, что мне лично импонирует. А вот насчет регекспа Action — конечно, вам решать. Но мне бы хотелось. :)
Где module — это типа «application внутри application». Во многом отсюда в MVC терминологию перешло понятие Module, которое представляет из себя некую инкапсулированную mvc-связку. В LS мы под модулем понимаем совсем другое :)
Т.е. по вопросам имен и терминов можно долго разбираться — смотря как глубоко копать в эту тему.
1) Если роутинг остается «прямым» (т.е. без всяких регекспов и прочих заморочек), то для чего нужны определения типа $config['router']['page']['error'] = 'ActionError';? Уж тогда надо сделать автоопределение, чтоб страница /error/ автоматом отдавалась классу ActionError. Т.е. если нет явного объявления, то распределение идет автоматом. И для кастомных модулей не надо будет писать лишний файл config.route.php с одной строкой, а системе не надо будет инклудить лишний файл.
2) Меня и в текущей версии жестоко обламывает относительная папка /uploads. В новой версии, судя по конфигу, она также будет относительной? Что мешает ее сделать абсолютной?
Т.е. пользователь написал свой Action для отображения блога и поставил —
А потом еще и захотел, чтобы доступ к нему был не через /blog/, а через /superblog/ — добавил
Помимо удобства здесь есть еще одно преимущество — конфиг роутера теперь можно «перекрыть» из конфига модуля. Т.е. можно писать модули, которые будут «подменять» стандартные action`ы в автоматическом режиме, без необходимости вносить правки в основную конфигурацию.
Экономия на спичках. Все равно каждый раз при загрузке конфигураций модулей нужно проверить существует такой файл или нет.
2. Масштабируемость. Сколько контента вы уместите в одном каталоге?
Пока в этом направление ничего не реализовано, но плацдарм готов — /uploads не имеет жесткой привязки, может быть сменена через Config::Set()… Пишите мини-файловый-сервер, распределяющий и тянущий контент с разных серверов, если на одном места не хватает.
LS по своей специализации должна быть максимально просто масштабируемой, иначе ваше «блого-социальное сообщество» быстро разрастаясь наткнется на серьезные технические трудности.
2. Ты не понял — в версии 0.3 константа DIR_UPLOADS содержит относительный путь, и в некоторых базовых модулях при обработке путей к нему явным образом лепится DIR_WEB_ROOT (типа $path=DIR_WEB_ROOT.DIR_UPLOADS). Поэтому, переопределив его в конфиге и задав абсолютный путь, мне надо еще лезть в базовые модули, чтоб это убрать. Но по ответу я понял, что в новой версии таких проблем быть не должно, и я могу задавать для upload любые пути, в т.ч. и абсолютные.
Тогда при первом обращении к папке, например, /actions или /modules (пусть это даже просто наличие проверки файла) мы считываем ее содержимое и засовываем в мемкеш (если он включен, ясень пень кешировать в файлов кеше смысла нет). Также сохраняем массив с содержимым папки в свойстве oEngine. Тогда при последующих обращениях к этой папке в рамках обработки одного урла мы вообще больше файловую систему трогать не будем. А так — будем дергать данные из кеша. Т.е. по сути, двухуровневый кеш получается.
Единственная проблема, которую вижу сходу — это добавление модулей, изменение конфига (его тоже через этот алгоритм гнать надо) и т.д. Но решается она довольно просто — предусматриваем экшн /restart/, который необходимо вызывать под админом после каких-то изменений, и который будет сбрасывать все кеши.
ЗЫ. Ребят, ничего, что я вам тут все советую? Не очень достал? ;)
Элементарный пример — я разработал модуль работы с новым типом топиков (или блогов). Для этого расширил перечисление типов, добавив тип «avadim». Кто-то другой пишет свой модуль с другим типом топиков, добавив тип «drugoi». Если юзер захочет поставить оба модуля, он должен будет руками залезть в базу и создать свой перечисляемый тип, который будет содержать оба типа топиков — «avadim» и «drugoi»! А потом разработчики ЛС добавят новый базовый тип, и при очередном апгрейде движка все, что добавил в базу юзер, будет почикано.
Оно вам надо такой гемор?
Другой разработчик тоже создает свой тип блога 'drugoi'. И что он делает?
И если юзер надумает поставить сначала мой модуль, а потом другой, то мой, естественно, работать перестанет. Что нужно будет сделать юзеру, если он захочет использовать оба модуля? Руками править таблицу, чтобы там оба эти типа жили.
А потом вы решите добавить новый тип блога, например, 'hidden'. И вы вряд ли станете анализировать, менял ли юзер одну из базовых сущностей в таблице или нет. Вы просто сделаете патч, где будет следующий код:
Юзер накатит ваш апгрейд и убъет два своих модуля, пока опять не полезет в базу руками.
И, кстати, получение списка типов через SELECT (если их задавать в отдельной таблице) гораздо проще, чем получать список полей через DESCRIBE, а потом еще и парсить строку типа «ENUM('aaa', 'bbb', ...)».
Нет, если установка жесткая — «в ЛС возможны только те типы блогов и топиков, которые предусмотрели разработчики», то все ок. Если же декларируется, что разработка своих типов возможна без хаков и ковыряния в базе, то стоит подумать над этим.
потом сам ответил
как делать парсинг строки могу показать :)
я к тому, что есть задача — добавить тип, есть стандартное и существующее решение, которое никого не ограничивает и позволяет манипулировать с типами. Зачем придумывать дополнительное решение, которое добавляет новые таблицы и дополнительные запросы(джойны) при выборке?
Но дело даже не в проблемах, а в принципиальном подходе, и основополагающий мой аргумент выше — «если я при разработке модуля меняю базовые вещи — это совсем не есть гуд».
Мое мнение: если установка модуля сопровождается созданием новых таблиц — это нормально. Если при этом требуется добавлять поля в базовую таблицу — это уже не очень хорошо. Если при этом меняется какое-то базовое поле — это уже совсем нехорошо. Вот просто по определению. И неважно, чего меняется и как. Просто надо стараться всеми силами этого избегать. Если в терминах ООП, то это все равно, если б я:
а) сделал расширение класса — ок
б) добавил свойство или метод в базовый клас — не очень ок
в) изменил свойство или метод в базовом классе — совсем не гут.
«Я ясно излагаю?» (с)…
ЗЫ Прошу понять правильно — я не пытаюсь тебя «переломить через коленку», лишь хочу, чтоб ты понял мои доводы. При этом не обязательно их принимать — степень их убедительности и значимости ты определяешь сам. :)
ЗЗЫ Кстати, если позволить себе некоторую избыточность, то можно не плодить новых джойнов. Не очень правильно с академической точки зрения, но «если нельзя, но очень хочется, то — можно» :)
ну пока многие задачи которые нужны пользователям ls (сюда по топикамкак сделать то-то) решаются только изменением, добавлением полей, про тип топика все ясно, ксати вопрос к ort, может допускать в каталог модулей только те, которые работают хотя бы с базой по стандартам (та же проверка на типы поля)?
Я ещё не успел ознакомиться подробно со всеми нововведениями, но уже сейчас по отзывам других пользователей сделал вывод, что перенос модулей на новую структуру будет очень трудоёмким. В связи с этим нужно единогласно решить, когда выйдет версия с окончательно проработанной структурой ядра, чтобы можно было спокойно провести рефакторинг всех существующих модулей.
В связи с этим также пока на время откладываю разработку ещё одного крупного модуля.
Так же скорее всего придется отложить запуск проекта, буду ждать новый релиз. А пока займусь дизайном.
Я думаю, при всем желании вряд ли кто может «зуб пацана дать», что больше серьезных изменений в архитектуре не будет. И не потому, что легкомысленно к этому относятся, а в силу того, что чрезвычайно сложно заранее все нюансы предусмотреть. Как было сказано в параллельном топике — проект еще слишком молод и слишком динамичен, чтоб можно было говорить об окончательно устоявшихся стандартах.
но я думаю, что мысль в целом ясна. вопрос скорее напрямую к ort`у: какие действия могут быть предожены разработчикам модулей на данный момент? с учетом проведенного рефакторинга и возможных дальнейших модификаций ядра.
В новом варианте конфигурирование модуля выглядит так:
Думаю, лучше сделать так:
Мелочь, конечно, но более структурировано получается
Мне кажется создание новой версии будет намного быстрее!
Тем более вы хорошо знакомы со структуров и «что нужно пользователям»…
И ваще, надо уметь отличать нормальную дискуссию от мордобоя :)
определено в файле /config/modules/search/config.php — т.е. это конфигурация модуля. При отработке /config/loader.php этот массив будет слит в конфиг с префиксом 'module.название_модуля'. В итоге получим на выходе (кусок конфига):
Лично я когда разбирал ls 0.2 на фреймворк и ЦМС имеено так и реализовал, на мой взгляд стало удобнее…
Например, когда мы постим ajaxом топик, возвращается html главной (который подгружаем тем же шаблоном, что и обычно, только без хидера/футера) и json, который мы обрабатываем и задаем классы элементов, который на странице.
и потом в shutdown() отправляем переменные в шаблон, а в экшене персональных блогов и топ считаем все в shutdown(), может все одинаково сделать, дабы не вводить общественность в заблуждение?
Во-вторых, это уже исключительно вкусовщина, которая никоим образом не касается стандартов движка, и которая полностью отдается на откуп разработчика конкретного экшена.
И, повторюсь, это может ввести в заблуждение только ту общественность, которая совешенно не понимает смысла этих строк.
Речь за то что по сути 4 экшена очень схожи между собой они достоют все топики новые, новые коллективные топики, новые персональные топики и топ, переменные о которых мы говорим определяют количество оных, для «рисования +n» в меню. В первых двух экшенах реализовано это УДОБНО я могу использовать переменные в любом методе, т.к. они являеются свойством класса, а других же двух этого не сделано, почему бы не потратить 5 минут и не сделать коммит который это исправит, к томуже пока ls это блогосферная соцсеть — эти экшены неотъемлемые части ls, и воевать за красоту кода в них необходимо.