Как стать автором
Обновить

Комментарии 102

Сайт проекта: boolive.ru Исходники в свободном доступе.
Вот. Наконец-то появилось то, что каждый может пощупать. Давно бы так.
В дауне сайтик. Ждать прийдется, пока оживет :)
Оживили.
а как в метаданных описываются связи? или это будет позже?
Позже будет пример, как вызовами методов модлуя Data будут созданы новые классы данных, определны свойства, созданы объекты. В принципе, можно поковырять исходники, если не терпится
не, мы подождём :-)
интересно было бы пощупать проект с точки зрения производительности…
не стоит пока;)
НЛО прилетело и опубликовало эту надпись здесь
Интересно: а не Вы ли сейчас boolive.ru abшкой щупаете?
кто-то щупает блин точно(
спрашивается — нафига все это хранить в БД? конструктить структуры надо в конфигах, и выхлопом генерировать оптимизированную схему (в SQL)
чтобы CMS была юзобильной для пользователя в первую очередь, а программистом уже во вторую
как раз-таки пользователям все равно, какая схема у БД.

Вы лучше расскажите, как будете накатывать мигрейшены — да и вообще любые изменения в структуре вашей базы (имена таблиц, колонок, их типы и т.лд.) или в именовании классов ;)
Изменять таблицы, то есть изменять уже существующие классы данных не стоит, это как в программе, если изменить класс, то получишь геморроя, вообще лучше сначала подумать прежде чем изменять.
Вместо создания мега системы для поддержки изменяемости классов, лучше просто это запретить делать и это будет даже естественно, так как в реальности класс зависим от объектов, группируя объекты (машины, деревья, животные…) с одинаковыми свойствами мы создаем класс, мы не можем изменить класс и тем самым изменить реальные объекты.
Конечно, возможность изменить имя класса вроде бы нужна, но её можно заменить созданием нового класса без риска на возникновение всяких непредвиденных ситуаций.
0_o вот это вы костыль придумали. Чтобы изменить имя класса — создать новый… это просто гениально :)
классы не нужно изменять каждый день
вообще, изменять имя класса и определния атрибутов ещё можно, а вот определние свойств или изменение наследовния уже влечет за собой серьзные структурные измения…
Для этого есть композиция. Советую в ГОФ глянуть ;)
Мне кажется что за эту гибкость придется платить очень большим оверхедом.
А что такое «оверхед»? Нагрузка серва?
возможно, не спорю)) все ради гибкости и скорее это даже эксперементальный проект… думаю, когда полностью всё расскажу и раставлю по полочкам, эти идеи можно будет примить в других проектах, а возможно в будущем появятся механихмы специально оптимизированные под предложенное)) например те же ОСУБД или что-то другое оригинально. Главное почувствовать гибкость…
Мне кажется что тебе стоило бы опробовать эти идеи сразу на ООПшной СУБД. Я думаю что за ними будущее, и было бы хорошо, если б кто-то готовился к нему.
существующие ОСУБД маразматичны, и для веб-проектов «для всех» их применение означает потерю огромной массы пользователей… Создавать же самому ОСУБД как-то затратно
не задумывались, почему появились всякие ORM вместо использования Объектных баз данных??
Потому что объектные базы ориентированы на большие проекты, например обслуживание телекоммуникационной сети, а для сайта — это чрезвычайно много. С этой работой справляются и реляционные БД.
Оружие нужно выбирать под жертву, а другими словами — из пушки по воробьям палить толку мало будет.

Чем эксперимент окончиться интересно, ибо проблема как хранить классы в реляционной БД достаточно непростая.

Помните, отрицательный результат — тоже результат. Желаю успеха.
пахнет идеологическим фанатизмом) что всегда чревато сказывается на производительности)
а чего такого сложного то?? все идеально))) просто и гибко и главное работает. А загрузка объектов из БД легко поддается кэшированию… да ещё какой гибкий механизм поиска реализован, ой ой ой)) в третьей части о нем.
На словах все идеально. В реальном мире идеальных вещей нет.
смотря как и на что смотреть, вопрос философский))
главное работает где?) на чем? на каких нагрузках?)) много чего легко поддается кешированию, а как у вас комментарии представлены? это тоже объекты которые кэшируются? и грузятся из кэша?))) ну ну) ничего простого тут не вижу вы нагородили излишних огородов, для всего что вы описали достаточно было две таблицы завести таблицу NODES и таблицу NODES_RELATIONS которая реализует связи много к много и этого бы вам хватило для создания модели графа и соответсвенно для реализации любых связей ну и еще вспомогательные таблицы тип таблица TYPES (типы — типы связей типы нод и т.д. прочая метаинформация) и таблицы с атрибутами нод все) выже нагородили ненужных сущностей
Если бы хватило, я бы их и применил.
смешно правда, вы сами предлагаете 3 сущности)) NODES, NODES_RELATIONS и TYPES
Зачем создавать отдельные таблицы для описания классов, если объекты каждого класса будут хранится в своих таблицах, и по этому уже будет понятно какого класса это объект и какие у него поля. Или вы хотите хранить объекты как-то по-другому?
все дело в предоставляемой гибкости. У класса, как и обычного объекта могут быть свойства — это подобие статических свойств в программировании. Например, на сайте будет форма для создания новости. Само слово «новость», описание что зачем и куда.., человеко-понятные заголовки для полей — все это свойства класса. В следующей части будет понятней.
также классы могут применяться для обобщения, например установка прав на «новости» — будет связь классом новостей… — это большая тема
к тому же нужно ещё хранить инфо о наследовании классов
CMS с метаданными — это жесть в плане производительности…
я понял секрет. чтобы получить плюс коменту — нужно упомянуть сакральную «производительность».

пробуем:

Производительность?!
«Производительность» — перестает быть мифом когда хостер начинает пинать вас за то что грузите сервер по самое небалуйся…
нагруженные проекты на шаред-хостинге?
А почему нет?
Одно дело — легкая cms на инклудах, которая и на шареде ведет себя быстро, а другое — монстр, который на коло нужно вешать, как минимум :)

ЗЫ: Рано говорить о производительности системы, которой еще нет :)
интересно. ждем следующую часть. надеюсь в след. части будет больше конкретных примеров
будут одни примеры
Поддерживаю. Вообще, все схемы на сайте в чём рисовались?
в векторном редакторе, не нашел редактора диаграмм для своих фантазий ;))
А потом CMS будет тормозить как не понятно что. Тут даже особо кеширование не поможет. Представьте себе, как это все прекрасно ляжет под нагрузками…

Создать идеальную CMS — это утопия.
Слушайте, речь не об идиальной CMS. Это больше эксперименты в поисках достижения гибкости cms о которой все мечтают и от чегго каждый первый хотябы думал о создании своей cms
Как CMS не растягивай и как её не согни — это все равно коробка, а коробки нужно использовать по назначению — для упаковки типовых продуктов, под которые они собсно и создавались. Нужен гибкий инструмент — используй фреймворк, благо достойных много — Symfony, Django, Ruby, .Net… А идея загнать классы в таблицы не кажется интересной.
Вы думаете о праграмистах. Я делаю систему, опираясь на желаниях пользователей — иметь гибкие возможности в управлении содержимым сайта — создать новый материал, что-то изменть, добавить фоток, позволить коментировать то-то — это так минимум на словах. Фреймворки мало чем помогут в создании подобных возможностей.
О пользователях я думаю. В первую очеред они хотят быстро управлять содержимым, и чтобы думать поменьше, и чтобы мышка сама в нужном напрвлении двигалась. А вы их заставляете конструировать структуры, описывать объекты, ещё и в идеологию нужно предварительно вникнуть. Это им меньше всего надо, на мой взгляд. Сорее всего они списхнут все на обслугу — коим часто выступает програмист средней руки, думаю в нормальном виде с классами куда приятнее работать, и эффект на порядок выше.
Ну это ещё смотря как реализовать. Предложенная модель не определяет как будет выглядеть gui интерфейс создания этих самых классов. А сделать можно очень просто, программерские понятия класса и объекта заменить на обыденные, например тип материала и сам материал… Посмотрите, даже связи между сущностями упрощены и предложены два варианта «использовать» и «состоять» — как раз понятно и обыденно)) И вообще объектный подход как раз естественен для человека.
Думаю, что у CMS есть 2 типа пользователей:

— Интеграторы (те, кто делает сайты на основе CMS)
— Администраторы сайтов ( кто пользуется плодами интеграторов )

Для первых и предназначена гибкость, а вот вторым нужна простота и производительность…
В UMI-CMS несколько схожий по идеологии конструктор типов данных, в 90% случаев работет с ним только программист устанавливающий проект на систему. Вобще любые манипуляциии со структурой данных в большинстве случаев больно сказываются на работе сайта, т.к. переплетаются с шаблонами и прочим подобным, без представлений о том как построен проект туда лезть не следует, это скорее зона разработчика чем пользователя.
создать объект (статью, комментарий...) ещё проще, точнее сделать для его создания удобный веб интерфейс
«точнее сделать для его создания удобный веб интерфейс » — золотые слова, юзеру нравиться понимать что он создает, минимум абстракций — оставьте их программисту

да что вы все к нагрузкам/производительности-то прикапываетесь?
тема жутко академическая. человек рассказывает свою практику. человек рассказывает свои идеи.
эти идеи, возможно, простимулируют читателей на собственные подвиги, на новые реализации старого, итд итп.
он никого не заставляет делать так, как пишет. и он не пишет гугл — под 10b хитов в день этому коду никогда не бывать.
Вань, ты хочешь сказать, что CMS — это суто академическая тема?:-))

Вопросов бы не было, если бы человек написал про модель данных без привязки к «архитектуре CMS».
А чего все уперлись в тормоза? Разве нет рынка сайтов, которым далеко до высокой и средней нагрузки? Да таких, IMHO, большинство, и в них подобный подход как раз и можно будет употребить.
Поздравляю, вы виртуозно разложили грабли в тёмном амбаре. Осталось только включить музыку и начать танцевать.

Про мелкие ляпы типа "«использовать» (агрегация, ассоциация)" даже писать не хочется :)

Уверяю вас, когда я расскажу о теории на основе которой все построено, вы меня совсем не поймете и все забракуете, так я многое изменил во всем известной объектной модели от Г.Буча :))) и знаете это все работает
Будте любезны, расскажите.
в четвертой части статьи расскажу) будет хоть повод интерисоваться)
«использовать» — и это все не от балды взято, между прочим идеи и теория на основе которой все строится развивается уже год с лишним, не надейтесть, что я тупой в ооп))
Если вы замечательно разбираетесь в объектном проектировании, в чем я не сомневаюсь, то зачем такие сложности? Почему не использовать для достижения гибкости стандартные паттерны?

Ваши эти «состоит» и «использует» давно уже существуют в нормальных определениях фабрика, бридж, адаптер… =)
изобретаете велосипед, чем проще, тем лучше
подобный комментарий любой способен написать… даже не поспоришь
а вот возьмите и напишите, как проще и как лучше. м? :-)
Не поверите, но давно уже написал. И в ней чтобы собрать одну страницу не надо делать 15 запросов к базе данных. Гибкость штука хорошая, но надо знать меру.
напишите не код, а статью. код каждый горазд писать «идеальный и производительный».
нет слов)) предпочитаю заниматься делом, а не бумагомарательством.
к чему вы отнесёте свой первый критичный комментарий тогда? к делу или к марательству? :-)
Хоть и не совсем в тему, но все же:

Мож кто бросит линком на статейки описывающие написание модульного движка… т.е. как в распространенных cms и blogs. Чтоб с интеграцией в админку и последующей активацией… нифига найти не могу… так и приходится по старинке писать — жесткую отлаженную структуру.

Еще раз сорри за офф.топ
А скажите в какой программе можно нарисовать такие красивые классики? base_clasess.png :)
НЛО прилетело и опубликовало эту надпись здесь
Статья интересна хотя бы тем, что показывает как можно организовать хранение классов и объектов в реляционной БД. Это как 3 способа хранения иерархических данных…
А то, что эта модель показывается на CMS, не так уж и критично. В конце-концов никто не отменял кеширования, Materialized Views, и т.п. извращений с помощью которых можно «придумать» способ заставить всю эту гибкость работать с приемлемой производительностью…
Ожидаю в следующих статьях увидеть как CMS будет строить и модифицировать (через Веб интерфейс) «нативные» SQL таблицы и индексы для хранения объектов данных. Для линков нативную таблицу я увидел, а вот как автор предполагает хранить товары в каталогах пока не вижу :)
Уронили такому хорошему человеку сайт своим Хабраэффектом…
мораль: не хочешь завалить сайт — не пиши о нём на хабре? :-)
Это типа реализация flexible tree или я что-то путаю?
путаете. Это спопсоб представления объектной модели в таблицах
Объясните мне скудоумному в чем главная идея, почему не использовать уже готовую реализацию ORM?
В чем соль?
существующие ORM связаны с кодом — классы программируются, структура программируетя
Посмотрел архитектуру CMS. Есть модуль Request, спрашивается, а где же тогда Response?
Page, X и другие в зависимости от формата ответа
Мне кажется, что Response должен быть абстрактным классом с реализацией некоторой части логики, а Page и X должны наследоваться от Response и отдавать разные ответы. Т.е. ответы в виде XML, XHTML или же, к примеру, вывод в консоль, куда не надо выводить заголовки и где по-другому форматируется тело ответа.

У вас такая реализация, я правильно понимаю?
Я с вами согласен, можно сделать модуль Response, который как и Request по сути ничего делать не будет, только)))) но будет интерфейсом для всех других модулей формрующих результат
Автор, кстати, не нашел, как у вас будет маршрутизироваться запрос внутри приложения?
И будет ли использован REST?
О нем не думал и не знал ;)) пока только http.
о процессах внутри приложения ещё почти ничего не говорил… всё в свое время
Кстати, советую все модули (в ваших терминах) разрабатывать отдельно.
Относится к ним как к «черным ящикам». Для этого нужно понять, какие данные требуются для работы модуля, и какие данные должен отдать модуль (а точнее — инкапсулировать в себе).

В общем, я это к тому, чтобы как можно сильнее уменьшать связанность модулей, тогда рефакторить будеть сказочно удобно.
те есть вместо событий придумать общий интерфес работы с модулями?
Bonch прав кстати и я тоже так считаю. Модуль должен быть вообще как отдельная программа. И желательно «придумать» не только общий интерфейс, но и единый контроллер.
Да, многие CMS так устроены, тот же eZ Publish (www.ez.no)
Вот видимо так и рождается Друпал с 400 запросами на страницу… автору конечно удачи, и советую ознгакомиться, хотя бы в обьщих чертах с Ruby On Rails — вещь (вроде как) тормозная, и для реального использования не очень пригодная, но идей там очень много интересных!
в друпале cck и view сбоку приписались
Как эволюция cms и технологий, советую унифицировать и перейти на единый контроллер.
Кстати заметил и explay пошел по этому пути.
Чем проще система — тем она быстрее и стабильнее.
Посмотрите вокруг. Шейдеры видеокарт унифицировали. Ядро corei7 унифицированная эволюция ядра core.
Не зря все пытаются унифицировать и упростить.
Я думаю Вам надо все таки выбрать и определить идеологию. А потом и архитектуру.
> выбрать и определить идеологию
я о ней рассказываю, но не могу все сразу изложить и в принципе не пытаюсь одной статьей все сразу рассказть))
Идеология должна быть в тезисах — этого достаточно, а здесь Война и мир ;)
Это уже не идеология, а демагогия ;)
Выходит, я унифицирую работу с данными. Не придется теперь в каждом новом модуле заботиться о таблицах в БД, да и модули теперь другим заняты
Вы пробовали писать под MVC системы?
Советую попробовать. Особенно попытаться поюзать ROR, прикоснуться, так сказать, к передовым вещам.

Правильно maxic говорит — унификация должна быть в сторону контроллера.

Заботиться о таблицах БД? Ну да, не надо, если есть хороший ORM (под php пока не встречал) и кодогенераторы + миграции.

В общем, велкам в личку:)
Чем-то похоже на UMI CMS.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории