Объектное ориентированное хранение информации (деревья + классы с наследованием)
- Автор темы 440hz
- Дата начала
tf
крылья рулят
440hz
хорошая идея. у меня сейчас почти также реализовано. только на каталоге продукции http://www.dgvision.ru/product/product_337.htm. сейчас вслед твоей идеи поделил все на два класса - класс дерево и класс произвольных параметров. отталось все совместить
ps/ доклад по конференци 6 не хочет написать по данной теме или в журнал phpinside
хорошая идея. у меня сейчас почти также реализовано. только на каталоге продукции http://www.dgvision.ru/product/product_337.htm. сейчас вслед твоей идеи поделил все на два класса - класс дерево и класс произвольных параметров. отталось все совместить
ps/ доклад по конференци 6 не хочет написать по данной теме или в журнал phpinside
Novice
Новичок
А есть возможность НЕ наследовать некоторые свойства родительского объекта? то есть если в "Произведения" есть "стоимость", а в "АРХИТЕКТУРА" оно мне не надо например... Хотя в этом может быть и фишка ОО подхода 
А чем данная реализация отличаеться например от такой...
Дерево держим в Nested Sets, каждая ветка может быть как родительской для других так и конечным модулем "каталог" скажем, в котором уже настраиваються стрпуктуры вида:
Информация
- автор (инпут)
- источник (инпут)
- дата (html_date)
Данные
- название (инпут)
- описание (текстария)
- картинка (html_img)
- содержание (wysisyg)
и тд...
Наследования тут конечно нет, но реализуеться намного проще с меньшим количеством таблиц...
ЗЫ возможно я не просек темы в силу неопытности, так что не ругайте.
А чем данная реализация отличаеться например от такой...
Дерево держим в Nested Sets, каждая ветка может быть как родительской для других так и конечным модулем "каталог" скажем, в котором уже настраиваються стрпуктуры вида:
Информация
- автор (инпут)
- источник (инпут)
- дата (html_date)
Данные
- название (инпут)
- описание (текстария)
- картинка (html_img)
- содержание (wysisyg)
и тд...
Наследования тут конечно нет, но реализуеться намного проще с меньшим количеством таблиц...
ЗЫ возможно я не просек темы в силу неопытности, так что не ругайте.
440hz
php.ru
1. дописать галку к свойсту с признаком "не наследуемое" - делов на пару минут.Автор оригинала: Novice
А есть возможность НЕ наследовать некоторые свойства родительского объекта? то есть если в "Произведения" есть "стоимость", а в "АРХИТЕКТУРА" оно мне не надо например... Хотя в этом может быть и фишка ОО подхода
А чем данная реализация отличаеться например от такой...
Дерево держим в Nested Sets, каждая ветка может быть как родительской для других так и конечным модулем "каталог" скажем, в котором уже настраиваються стрпуктуры вида:
Информация
- автор (инпут)
- источник (инпут)
- дата (html_date)
Данные
- название (инпут)
- описание (текстария)
- картинка (html_img)
- содержание (wysisyg)
и тд...
Наследования тут конечно нет, но реализуеться намного проще с меньшим количеством таблиц...
2. схема там такая:
- есть дерево наследования, где хранится информация о принадлежности узлов друг другу
- есть свойства, которые знают к какому узлу дерева они относятся, их тип и значения.
- есть объекты, которые строятся на основе узла, принадлежащих ему свойств, их значений и наследуемых свойств от родителей.
все это укладываетс в таблицы:
1 таблица само дерево.
2 таблицы на свойства узла
2 таблицы на объекты и их свойства
1 таблица на связи объектов между друг другом.
придумывалось под конкретный проект, но вылилось, наверное, в нечто более глобальное. более свежие версии решения работают с объектами немного по другому. очень расширились методы классов. особенно в поиске и фильтрации.
как и было заявлено - готовлю исходники с примерами.
kostya.sys
Новичок
идея интересная
не могу сказить что новая, так как долго работал с подобным но на базе Zope/python
а в прошлом году занялся своей CMS уже на php.
Концепция у меня схожая, только я пока не заморачивался с наследованием, так как оно в большинстве случеев мешало мне еще Zope/python.
Ну и называется у меня это не классы, а категории.
В добавок каждая категория может иметь свой родной шаблон отображения, либо комплект шаблонов (версия для печати, в формате ворд, pdf как-то тоже делал, но замучался с таблицами и бросил)
Ну и сама разбивка у меня другая.
Категории у меня обособлены от дерева и от структуры.
Само дерево представляет непосредственно экземпляры контент-классов (читай категорий).
Плюс есть возможность задавать категриии разрешенные к созданию в контексте того или иного узла. При чем задается это как в дереве так и в контексте категории.
Категории у меня расширяют атрибутику основных "классов" системы. Пока их у меня 4:
Папка (только в ней могут быть потомки), документ (под него в принципе категории и писались, так как он непосредственный контейнер информации), голосование, форма обратной связи (тоже конструируется)
В принципе создав какую-либо категорию в бэк-энде уже можно с ней работать.
А для фронт-энда зачастую нужно делать отдельный шаблон.
Ну и обратные связи приходица доставать только на уровне SQL, что мне не очень нравится, но в мускуле ничего с этим не поделаешь
не могу сказить что новая, так как долго работал с подобным но на базе Zope/python
а в прошлом году занялся своей CMS уже на php.
Концепция у меня схожая, только я пока не заморачивался с наследованием, так как оно в большинстве случеев мешало мне еще Zope/python.
Ну и называется у меня это не классы, а категории.
В добавок каждая категория может иметь свой родной шаблон отображения, либо комплект шаблонов (версия для печати, в формате ворд, pdf как-то тоже делал, но замучался с таблицами и бросил)
Ну и сама разбивка у меня другая.
Категории у меня обособлены от дерева и от структуры.
Само дерево представляет непосредственно экземпляры контент-классов (читай категорий).
Плюс есть возможность задавать категриии разрешенные к созданию в контексте того или иного узла. При чем задается это как в дереве так и в контексте категории.
Категории у меня расширяют атрибутику основных "классов" системы. Пока их у меня 4:
Папка (только в ней могут быть потомки), документ (под него в принципе категории и писались, так как он непосредственный контейнер информации), голосование, форма обратной связи (тоже конструируется)
В принципе создав какую-либо категорию в бэк-энде уже можно с ней работать.
А для фронт-энда зачастую нужно делать отдельный шаблон.
Ну и обратные связи приходица доставать только на уровне SQL, что мне не очень нравится, но в мускуле ничего с этим не поделаешь
440hz
php.ru
kostya.sys
1. никто не претендует на новость. такое уже делалось не раз и дже не на PHP, даже когда еще персоналок не было. 8)
2. вариантов реализации "Объектной надстройки" над линейным хранилищем (SQL) много.
3. тут в бек-енде имеем стандартный набор для управления всеми типа объектов и их связями.
4. для фронт-енда пишется все отдельно. тут можно или шаблоны прицекплять или еще что. я просто писал код. так было быстрее, т.к. типов объектов в данной схеме немного.
1. никто не претендует на новость. такое уже делалось не раз и дже не на PHP, даже когда еще персоналок не было. 8)
2. вариантов реализации "Объектной надстройки" над линейным хранилищем (SQL) много.
3. тут в бек-енде имеем стандартный набор для управления всеми типа объектов и их связями.
4. для фронт-енда пишется все отдельно. тут можно или шаблоны прицекплять или еще что. я просто писал код. так было быстрее, т.к. типов объектов в данной схеме немного.
Sherman
Mephi
Тоже реализовывал примерно такую же систему.
Пришел к выводу, что:
1. Интерфейс становится слишком сложным для неподготовленного юзера.
2. Интерфейс становится жутко неудобным, т.к. не заточен под конкретную задачу, а наоборот максимально обобщает систему(т.е. о юзабилити можно забыть).
3. Резко ограничивает возможности кастомизации.
Третий пункт поясню.
Если делать шаблонные сайты, то нет проблем. Но как только появляется нужда/необходиость выйти за рамки системы(а точнее возможнойстей метаданных, и "стандартного" API), тут же начинаются серьезные проблемы.
4. Стоимость разработки и поддержки такого решения тоже не последнее дело.
p.s. Концепция CMF более гибка и при этом не обладает четвертым пунктом(если грамотно подойти к выбору CMF). Т.е. лучше строить дом из кирпичей, и делать классные узоры, при этом не теряя надежности, чем клепать хрущевки из блоков
вот примерно с чего начинал, и потом от этого ушел:
http://www.ljplus.ru/img/g/a/gabaidulin/summary.gif
p.p.s. Правда стоит отметить, что в последнее время занимаюсь совершенно непохожими проектами вплане бизнес сущностей, источников данным и т.д. Иными словами для каждого проекта мне бы пришлось менять функционал или делать отдельную версию системы, а так в качестве CRM-о подобного решения наверное неплохо...
Пришел к выводу, что:
1. Интерфейс становится слишком сложным для неподготовленного юзера.
2. Интерфейс становится жутко неудобным, т.к. не заточен под конкретную задачу, а наоборот максимально обобщает систему(т.е. о юзабилити можно забыть).
3. Резко ограничивает возможности кастомизации.
Третий пункт поясню.
Если делать шаблонные сайты, то нет проблем. Но как только появляется нужда/необходиость выйти за рамки системы(а точнее возможнойстей метаданных, и "стандартного" API), тут же начинаются серьезные проблемы.
4. Стоимость разработки и поддержки такого решения тоже не последнее дело.
p.s. Концепция CMF более гибка и при этом не обладает четвертым пунктом(если грамотно подойти к выбору CMF). Т.е. лучше строить дом из кирпичей, и делать классные узоры, при этом не теряя надежности, чем клепать хрущевки из блоков
вот примерно с чего начинал, и потом от этого ушел:
http://www.ljplus.ru/img/g/a/gabaidulin/summary.gif
p.p.s. Правда стоит отметить, что в последнее время занимаюсь совершенно непохожими проектами вплане бизнес сущностей, источников данным и т.д. Иными словами для каждого проекта мне бы пришлось менять функционал или делать отдельную версию системы, а так в качестве CRM-о подобного решения наверное неплохо...
Rammstein
PHPClub::News
Sherman
Всё зависит от реализации интерфейса и от возможности его костомизации. Взять тот же Linux: можно работать в консоле, можно в стандартном KDE или же (лучший вариант) затюнить KDE под свои потребности. В этом смысле KDE почти идеал.
Что касается источников данных, то можно и их реализовать.. Т.е. чтобы разным узлам в дереве соответствовали бы разные источники данных.
Всё зависит от реализации интерфейса и от возможности его костомизации. Взять тот же Linux: можно работать в консоле, можно в стандартном KDE или же (лучший вариант) затюнить KDE под свои потребности. В этом смысле KDE почти идеал.
Что касается источников данных, то можно и их реализовать.. Т.е. чтобы разным узлам в дереве соответствовали бы разные источники данных.
440hz
php.ru
дедушка АУ
Новичок
440hz
вопрос к вам:
а если я захочу свойство 'datetime' у объекта?
как этот тип поля опишу в таблице со свойствами объекта?
т.е. я так понимаю там все свойства - текстовые поля...
конечно можно string'ом 23.05.06 парсить и выводить и проч.. а как же сортировка в таком случае? а как выборка под датам?
спасибо
вопрос к вам:
а если я захочу свойство 'datetime' у объекта?
как этот тип поля опишу в таблице со свойствами объекта?
т.е. я так понимаю там все свойства - текстовые поля...
конечно можно string'ом 23.05.06 парсить и выводить и проч.. а как же сортировка в таком случае? а как выборка под датам?
спасибо