Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 102
Сайт проекта: boolive.ru Исходники в свободном доступе.Вот. Наконец-то появилось то, что каждый может пощупать. Давно бы так.
а как в метаданных описываются связи? или это будет позже?
интересно было бы пощупать проект с точки зрения производительности…
спрашивается — нафига все это хранить в БД? конструктить структуры надо в конфигах, и выхлопом генерировать оптимизированную схему (в SQL)
чтобы CMS была юзобильной для пользователя в первую очередь, а программистом уже во вторую
как раз-таки пользователям все равно, какая схема у БД.
Вы лучше расскажите, как будете накатывать мигрейшены — да и вообще любые изменения в структуре вашей базы (имена таблиц, колонок, их типы и т.лд.) или в именовании классов ;)
Вы лучше расскажите, как будете накатывать мигрейшены — да и вообще любые изменения в структуре вашей базы (имена таблиц, колонок, их типы и т.лд.) или в именовании классов ;)
Изменять таблицы, то есть изменять уже существующие классы данных не стоит, это как в программе, если изменить класс, то получишь геморроя, вообще лучше сначала подумать прежде чем изменять.
Вместо создания мега системы для поддержки изменяемости классов, лучше просто это запретить делать и это будет даже естественно, так как в реальности класс зависим от объектов, группируя объекты (машины, деревья, животные…) с одинаковыми свойствами мы создаем класс, мы не можем изменить класс и тем самым изменить реальные объекты.
Конечно, возможность изменить имя класса вроде бы нужна, но её можно заменить созданием нового класса без риска на возникновение всяких непредвиденных ситуаций.
Вместо создания мега системы для поддержки изменяемости классов, лучше просто это запретить делать и это будет даже естественно, так как в реальности класс зависим от объектов, группируя объекты (машины, деревья, животные…) с одинаковыми свойствами мы создаем класс, мы не можем изменить класс и тем самым изменить реальные объекты.
Конечно, возможность изменить имя класса вроде бы нужна, но её можно заменить созданием нового класса без риска на возникновение всяких непредвиденных ситуаций.
Мне кажется что за эту гибкость придется платить очень большим оверхедом.
А что такое «оверхед»? Нагрузка серва?
возможно, не спорю)) все ради гибкости и скорее это даже эксперементальный проект… думаю, когда полностью всё расскажу и раставлю по полочкам, эти идеи можно будет примить в других проектах, а возможно в будущем появятся механихмы специально оптимизированные под предложенное)) например те же ОСУБД или что-то другое оригинально. Главное почувствовать гибкость…
Мне кажется что тебе стоило бы опробовать эти идеи сразу на ООПшной СУБД. Я думаю что за ними будущее, и было бы хорошо, если б кто-то готовился к нему.
существующие ОСУБД маразматичны, и для веб-проектов «для всех» их применение означает потерю огромной массы пользователей… Создавать же самому ОСУБД как-то затратно
не задумывались, почему появились всякие ORM вместо использования Объектных баз данных??
Потому что объектные базы ориентированы на большие проекты, например обслуживание телекоммуникационной сети, а для сайта — это чрезвычайно много. С этой работой справляются и реляционные БД.
Оружие нужно выбирать под жертву, а другими словами — из пушки по воробьям палить толку мало будет.
Чем эксперимент окончиться интересно, ибо проблема как хранить классы в реляционной БД достаточно непростая.
Помните, отрицательный результат — тоже результат. Желаю успеха.
Оружие нужно выбирать под жертву, а другими словами — из пушки по воробьям палить толку мало будет.
Чем эксперимент окончиться интересно, ибо проблема как хранить классы в реляционной БД достаточно непростая.
Помните, отрицательный результат — тоже результат. Желаю успеха.
пахнет идеологическим фанатизмом) что всегда чревато сказывается на производительности)
а чего такого сложного то?? все идеально))) просто и гибко и главное работает. А загрузка объектов из БД легко поддается кэшированию… да ещё какой гибкий механизм поиска реализован, ой ой ой)) в третьей части о нем.
На словах все идеально. В реальном мире идеальных вещей нет.
главное работает где?) на чем? на каких нагрузках?)) много чего легко поддается кешированию, а как у вас комментарии представлены? это тоже объекты которые кэшируются? и грузятся из кэша?))) ну ну) ничего простого тут не вижу вы нагородили излишних огородов, для всего что вы описали достаточно было две таблицы завести таблицу NODES и таблицу NODES_RELATIONS которая реализует связи много к много и этого бы вам хватило для создания модели графа и соответсвенно для реализации любых связей ну и еще вспомогательные таблицы тип таблица TYPES (типы — типы связей типы нод и т.д. прочая метаинформация) и таблицы с атрибутами нод все) выже нагородили ненужных сущностей
Зачем создавать отдельные таблицы для описания классов, если объекты каждого класса будут хранится в своих таблицах, и по этому уже будет понятно какого класса это объект и какие у него поля. Или вы хотите хранить объекты как-то по-другому?
все дело в предоставляемой гибкости. У класса, как и обычного объекта могут быть свойства — это подобие статических свойств в программировании. Например, на сайте будет форма для создания новости. Само слово «новость», описание что зачем и куда.., человеко-понятные заголовки для полей — все это свойства класса. В следующей части будет понятней.
также классы могут применяться для обобщения, например установка прав на «новости» — будет связь классом новостей… — это большая тема
к тому же нужно ещё хранить инфо о наследовании классов
CMS с метаданными — это жесть в плане производительности…
интересно. ждем следующую часть. надеюсь в след. части будет больше конкретных примеров
boolive, а в чём рисовалась эта красота? :)
А потом CMS будет тормозить как не понятно что. Тут даже особо кеширование не поможет. Представьте себе, как это все прекрасно ляжет под нагрузками…
Создать идеальную CMS — это утопия.
Создать идеальную CMS — это утопия.
Слушайте, речь не об идиальной CMS. Это больше эксперименты в поисках достижения гибкости cms о которой все мечтают и от чегго каждый первый хотябы думал о создании своей cms
Как CMS не растягивай и как её не согни — это все равно коробка, а коробки нужно использовать по назначению — для упаковки типовых продуктов, под которые они собсно и создавались. Нужен гибкий инструмент — используй фреймворк, благо достойных много — Symfony, Django, Ruby, .Net… А идея загнать классы в таблицы не кажется интересной.
Вы думаете о праграмистах. Я делаю систему, опираясь на желаниях пользователей — иметь гибкие возможности в управлении содержимым сайта — создать новый материал, что-то изменть, добавить фоток, позволить коментировать то-то — это так минимум на словах. Фреймворки мало чем помогут в создании подобных возможностей.
О пользователях я думаю. В первую очеред они хотят быстро управлять содержимым, и чтобы думать поменьше, и чтобы мышка сама в нужном напрвлении двигалась. А вы их заставляете конструировать структуры, описывать объекты, ещё и в идеологию нужно предварительно вникнуть. Это им меньше всего надо, на мой взгляд. Сорее всего они списхнут все на обслугу — коим часто выступает програмист средней руки, думаю в нормальном виде с классами куда приятнее работать, и эффект на порядок выше.
Ну это ещё смотря как реализовать. Предложенная модель не определяет как будет выглядеть gui интерфейс создания этих самых классов. А сделать можно очень просто, программерские понятия класса и объекта заменить на обыденные, например тип материала и сам материал… Посмотрите, даже связи между сущностями упрощены и предложены два варианта «использовать» и «состоять» — как раз понятно и обыденно)) И вообще объектный подход как раз естественен для человека.
Думаю, что у CMS есть 2 типа пользователей:
— Интеграторы (те, кто делает сайты на основе CMS)
— Администраторы сайтов ( кто пользуется плодами интеграторов )
Для первых и предназначена гибкость, а вот вторым нужна простота и производительность…
— Интеграторы (те, кто делает сайты на основе CMS)
— Администраторы сайтов ( кто пользуется плодами интеграторов )
Для первых и предназначена гибкость, а вот вторым нужна простота и производительность…
В UMI-CMS несколько схожий по идеологии конструктор типов данных, в 90% случаев работет с ним только программист устанавливающий проект на систему. Вобще любые манипуляциии со структурой данных в большинстве случаев больно сказываются на работе сайта, т.к. переплетаются с шаблонами и прочим подобным, без представлений о том как построен проект туда лезть не следует, это скорее зона разработчика чем пользователя.
да что вы все к нагрузкам/производительности-то прикапываетесь?
тема жутко академическая. человек рассказывает свою практику. человек рассказывает свои идеи.
эти идеи, возможно, простимулируют читателей на собственные подвиги, на новые реализации старого, итд итп.
он никого не заставляет делать так, как пишет. и он не пишет гугл — под 10b хитов в день этому коду никогда не бывать.
тема жутко академическая. человек рассказывает свою практику. человек рассказывает свои идеи.
эти идеи, возможно, простимулируют читателей на собственные подвиги, на новые реализации старого, итд итп.
он никого не заставляет делать так, как пишет. и он не пишет гугл — под 10b хитов в день этому коду никогда не бывать.
А чего все уперлись в тормоза? Разве нет рынка сайтов, которым далеко до высокой и средней нагрузки? Да таких, IMHO, большинство, и в них подобный подход как раз и можно будет употребить.
Поздравляю, вы виртуозно разложили грабли в тёмном амбаре. Осталось только включить музыку и начать танцевать.
Про мелкие ляпы типа "«использовать» (агрегация, ассоциация)" даже писать не хочется :)
Про мелкие ляпы типа "«использовать» (агрегация, ассоциация)" даже писать не хочется :)
Уверяю вас, когда я расскажу о теории на основе которой все построено, вы меня совсем не поймете и все забракуете, так я многое изменил во всем известной объектной модели от Г.Буча :))) и знаете это все работает
«использовать» — и это все не от балды взято, между прочим идеи и теория на основе которой все строится развивается уже год с лишним, не надейтесть, что я тупой в ооп))
изобретаете велосипед, чем проще, тем лучше
Хоть и не совсем в тему, но все же:
Мож кто бросит линком на статейки описывающие написание модульного движка… т.е. как в распространенных cms и blogs. Чтоб с интеграцией в админку и последующей активацией… нифига найти не могу… так и приходится по старинке писать — жесткую отлаженную структуру.
Еще раз сорри за офф.топ
Мож кто бросит линком на статейки описывающие написание модульного движка… т.е. как в распространенных cms и blogs. Чтоб с интеграцией в админку и последующей активацией… нифига найти не могу… так и приходится по старинке писать — жесткую отлаженную структуру.
Еще раз сорри за офф.топ
А скажите в какой программе можно нарисовать такие красивые классики? base_clasess.png :)
Статья интересна хотя бы тем, что показывает как можно организовать хранение классов и объектов в реляционной БД. Это как 3 способа хранения иерархических данных…
А то, что эта модель показывается на CMS, не так уж и критично. В конце-концов никто не отменял кеширования, Materialized Views, и т.п. извращений с помощью которых можно «придумать» способ заставить всю эту гибкость работать с приемлемой производительностью…
Ожидаю в следующих статьях увидеть как CMS будет строить и модифицировать (через Веб интерфейс) «нативные» SQL таблицы и индексы для хранения объектов данных. Для линков нативную таблицу я увидел, а вот как автор предполагает хранить товары в каталогах пока не вижу :)
А то, что эта модель показывается на CMS, не так уж и критично. В конце-концов никто не отменял кеширования, Materialized Views, и т.п. извращений с помощью которых можно «придумать» способ заставить всю эту гибкость работать с приемлемой производительностью…
Ожидаю в следующих статьях увидеть как CMS будет строить и модифицировать (через Веб интерфейс) «нативные» SQL таблицы и индексы для хранения объектов данных. Для линков нативную таблицу я увидел, а вот как автор предполагает хранить товары в каталогах пока не вижу :)
Уронили такому хорошему человеку сайт своим Хабраэффектом…
Это типа реализация flexible tree или я что-то путаю?
Объясните мне скудоумному в чем главная идея, почему не использовать уже готовую реализацию ORM?
В чем соль?
В чем соль?
Посмотрел архитектуру CMS. Есть модуль Request, спрашивается, а где же тогда Response?
Page, X и другие в зависимости от формата ответа
Мне кажется, что Response должен быть абстрактным классом с реализацией некоторой части логики, а Page и X должны наследоваться от Response и отдавать разные ответы. Т.е. ответы в виде XML, XHTML или же, к примеру, вывод в консоль, куда не надо выводить заголовки и где по-другому форматируется тело ответа.
У вас такая реализация, я правильно понимаю?
У вас такая реализация, я правильно понимаю?
Автор, кстати, не нашел, как у вас будет маршрутизироваться запрос внутри приложения?
И будет ли использован REST?
И будет ли использован REST?
О нем не думал и не знал ;)) пока только http.
о процессах внутри приложения ещё почти ничего не говорил… всё в свое время
о процессах внутри приложения ещё почти ничего не говорил… всё в свое время
Кстати, советую все модули (в ваших терминах) разрабатывать отдельно.
Относится к ним как к «черным ящикам». Для этого нужно понять, какие данные требуются для работы модуля, и какие данные должен отдать модуль (а точнее — инкапсулировать в себе).
В общем, я это к тому, чтобы как можно сильнее уменьшать связанность модулей, тогда рефакторить будеть сказочно удобно.
Относится к ним как к «черным ящикам». Для этого нужно понять, какие данные требуются для работы модуля, и какие данные должен отдать модуль (а точнее — инкапсулировать в себе).
В общем, я это к тому, чтобы как можно сильнее уменьшать связанность модулей, тогда рефакторить будеть сказочно удобно.
Да, многие CMS так устроены, тот же eZ Publish (www.ez.no)
Вот видимо так и рождается Друпал с 400 запросами на страницу… автору конечно удачи, и советую ознгакомиться, хотя бы в обьщих чертах с Ruby On Rails — вещь (вроде как) тормозная, и для реального использования не очень пригодная, но идей там очень много интересных!
Как эволюция cms и технологий, советую унифицировать и перейти на единый контроллер.
Кстати заметил и explay пошел по этому пути.
Чем проще система — тем она быстрее и стабильнее.
Посмотрите вокруг. Шейдеры видеокарт унифицировали. Ядро corei7 унифицированная эволюция ядра core.
Не зря все пытаются унифицировать и упростить.
Я думаю Вам надо все таки выбрать и определить идеологию. А потом и архитектуру.
Кстати заметил и explay пошел по этому пути.
Чем проще система — тем она быстрее и стабильнее.
Посмотрите вокруг. Шейдеры видеокарт унифицировали. Ядро corei7 унифицированная эволюция ядра core.
Не зря все пытаются унифицировать и упростить.
Я думаю Вам надо все таки выбрать и определить идеологию. А потом и архитектуру.
> выбрать и определить идеологию
я о ней рассказываю, но не могу все сразу изложить и в принципе не пытаюсь одной статьей все сразу рассказть))
я о ней рассказываю, но не могу все сразу изложить и в принципе не пытаюсь одной статьей все сразу рассказть))
Выходит, я унифицирую работу с данными. Не придется теперь в каждом новом модуле заботиться о таблицах в БД, да и модули теперь другим заняты
Вы пробовали писать под MVC системы?
Советую попробовать. Особенно попытаться поюзать ROR, прикоснуться, так сказать, к передовым вещам.
Правильно maxic говорит — унификация должна быть в сторону контроллера.
Заботиться о таблицах БД? Ну да, не надо, если есть хороший ORM (под php пока не встречал) и кодогенераторы + миграции.
В общем, велкам в личку:)
Советую попробовать. Особенно попытаться поюзать ROR, прикоснуться, так сказать, к передовым вещам.
Правильно maxic говорит — унификация должна быть в сторону контроллера.
Заботиться о таблицах БД? Ну да, не надо, если есть хороший ORM (под php пока не встречал) и кодогенераторы + миграции.
В общем, велкам в личку:)
Чем-то похоже на UMI CMS.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура CMS. Модель данных. Часть 1