Создаю новый движок (CMS/CMF) на PHP5

[atv]

раньше не приходилось проводить сравнения движков, да и не совсем понятно в каком виде это надо сделать...

Всё очень просто, поставь себя на место тех кого ты пытаешься заинтересовать.

Например, предлагаю тебе присоединиться к проектам LightOrm и PHP_Application, что скажешь?

 

[d1gi]

atv
выше (26.05.09 14:04) я описал концепцию модели данных моего движка, вы можете нечто подобное привести для вышеуказанных вами проектов? вполне возможно в этих, а может и в каких то других проектах, о которых я либо ничего еще незнаю, либо знаю только о их существовании, может в каком-нить из них нашел бы именно тот инструмент, который мне был бы удобен для работы

 

[Lightning]

AmdY

когда запросы к базе делаются прямо в контроллере, можно сразу забивать гвозди в крышку гроба этой CMS.

Смешно В юмор нужно было написать.

Вот еще шутки:
- Если Вы делаете "прямые" запросы к базе вместо использования ОРМ, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы используете ОРМ вместо "прямых" запросов к базе, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы используете синглтоны, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы не практикуете TDD, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы практикуете TDD, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы используете MySQL а не Postgres, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы используете Postgres а не MySQL, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы пишете на PHP5, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы пишете на Python, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы пишете на Ruby, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы делаете отступы табуляциями а не пробелами, можно сразу забивать гвозди в крышку гроба Вашей CMS.
- Если Вы делаете отступы пробелами а не табуляциями, можно сразу забивать гвозди в крышку гроба Вашей CMS.

и т.д. ))))))))

 

[atv]

я описал концепцию модели данных моего движка, вы можете нечто подобное привести для вышеуказанных вами проектов

Это есть на страницах этих проектов, но тебе даже это лень почитать, вот и делай выводы.

 

[d1gi]

Lightning
поулыбался! ) особенно про пхп5!!! %))) ой как долго я с напарником пилил эту тему )))

а вообще не стоит обращать на проявления эмоций товарища AmdY, но он желает рассказать нам всем о "слабом звене в цепи", которое нашел в моём исходнике, надеюсь он это сделает с ссылкой на сам код (например какой файл, строчка и что в там не так).

вообще, я бы с удовольствием по больше комментариев послушал на тему качества исходного кода вообще и идеи модели в целом

-~{}~ 27.05.09 02:11:

atv
я понял вашу позицию, могу только выразить благодарность за ваше личное внимание.

 

[weregod]

ТС, рассмотрите иное толкование терминов:
Мультидоменность (алиасовость, чтоли) - это когда одно и то же наполнение безглючно крутится на разных доменах. Если Ваш продукт приобретет популярность, возможно появятся клиенты с различными хотелками, как "хочу, чтобы при заходе на domain2.com безусловно перебрасывало на domain1.com", "хочу, чтобы при заходе на domain1.com и domain2.com было всё равно, куда зашел, плюс конент был идентичен", "хочу, чтобы после авторизации на domain1.com и случайном наборе domain2.com пользователь оставался авторизован"...

Мультисайтовость - это когда разное наполнение "разных" сайтов доступно в одном и том же бэкэнде в рамках одного клиента.

Можно развить дальше.

 

[d1gi]

weregod
всё верно всё это заложено в движок хотя и далеко не всё в данный момент работает...

 

[AmdY]

Lightning
ты считаешь это нормальным, вместо получения новости методом News::getList($groupId, $lang) или News::getList($groupId, $lang, $offset, $perPage) ?
далее в классе News
огромный метод run, почему его не разделить хотя бы на 2 приватных метода _show_item(), _show_page(). пэйджинг тоже можно вынести в абстрактный метод родителя(Module).

а вот это
$sql = "SELECT `descr`, `title`, `name` FROM `news_groups` WHERE `group_id` = '$this->news_group_id'";
$result = $this->DB->query($sql);
$row = $result->fetchObject();
$this->output_data['title'] = $row->title;
$this->output_data['descr'] = $row->descr;
$this->output_data['name'] = $row->name;
почему не достать данные сразу в массиве и смержить с $this->output_data

там же $data['title'] = "Страница №" . $tmp['value'];
зачем тогда столько гемора с языком новостей, если не переводишь такие куски: $data['title'] = translate("Страница №", $language_id) . $tmp['value'];
да и вообще, метода parseURI не должно быть здесь, как и пэйджинга.

основная проблема, что полученный код не может быть легко реиспользованым в другом модуле. а отсутсвие модели News потребует кучу проблем при доработке модуля и нарушает его целостность.

 

[Alexandre]

News::getList($groupId, $lang, $offset, $perPage)

согласен, костляво
Класс новости должен отвечать за подготовку данных (модель)
гламурнее так:
$Pager = new Pager( $offset , $perPage);
$news = new News( ..., $lang );
$news->setPaging( $Pager );
$news_list = $news->getList( $groupId );

 

[d1gi]

Автор оригинала: AmdY
огромный метод run, почему его не разделить хотя бы на 2 приватных метода _show_item(), _show_page().

да, согласен, так будет красивее

Автор оригинала: AmdY
пэйджинг тоже можно вынести в абстрактный метод родителя(Module).

пейджинг вынести я хочу, но не в метод родителя, а скорее как отдельный классик в виде компонента т.к. далеко не всем модулям нужен будет пейджинг вообще, а кому надо будет, тот подцепит.

Автор оригинала: AmdY
а вот это
$sql = "SELECT `descr`, `title`, `name` FROM `news_groups` WHERE `group_id` = '$this->news_group_id'";
$result = $this->DB->query($sql);
$row = $result->fetchObject();
$this->output_data['title'] = $row->title;
$this->output_data['descr'] = $row->descr;
$this->output_data['name'] = $row->name;
почему не достать данные сразу в массиве и смержить с $this->output_data

ммм... неуверен, но если допустим в $this->output_data будет уже какие-то значения, например $this->output_data['value'] , то что будет после мержинга в $this->output_data? вроде как мы потеряем значение 'value'

Автор оригинала: AmdY
там же $data['title'] = "Страница №" . $tmp['value'];
зачем тогда столько гемора с языком новостей, если не переводишь такие куски: $data['title'] = translate("Страница №", $language_id) . $tmp['value'];

// @todo сделать перевод
читаем одну строчку выше

Автор оригинала: AmdY
да и вообще, метода parseURI не должно быть здесь, как и пэйджинга.

это концепция движка т.е. только сам модуль знает как надо распарсить ту часть УРИ, которая предназначается для него, в частности модуль News распознаёт парсинг номера страницы и название самой новости в виде "mynews.html". в будужем планируется дописать парсинг строчек вида /2009/05/27/mynews.html , а например по запросу /2009/05/27/ - выводит ьвсе новости за день, по /2009/05/ - за месяц и т.д.

Автор оригинала: AmdY
основная проблема, что полученный код не может быть легко реиспользованым в другом модуле. а отсутсвие модели News потребует кучу проблем при доработке модуля и нарушает его целостность.

да, согласен, часть кода надо будет разбить на более узко-направленные приватные методы, а часть вообще вынести в другие классы

 

[AmdY]

просто вынеси общеупотребительные методы в родителя, их же никто не мешает переопределить в самом контроллере, если нужно.
насчёт мерджинга, я специально захватил строчку запроса, там три колонки, из которых все передаются в аутпут.
кстати, ты не используешь плэйсхолдеры для запросов, у тебя параметры типо '$this->news_group_id ескейпятся где-то?

 

[vegaplex]

привет, понравилась идея описанная как "суть движка" в вики, однако, это скорее должно быть не алгоритм работы (определяющий шаблонизацию) движка как такового, а как одна из возможных стратегий раутинга и маршрутизации запроса, с последующей шаблонизацией каждого раздела сайта на своём уникальном дизигне.
Особо исходник не смотел, но сорь, в целом кажется очень сырым, например, тот факт, что важные системные классы наследуют от некоего Object, который объявлен как абстракт, и далее коммент - Подумать надо ли делать верхний класс для всех объектов. (тема много раз обтиралась, и существует множество ИМХОв, моё такое - что ДЛЯ ВСЕХ это нафик не надо, а в тех случаях, когда мы хотим придать общую базовую ф-ность, нам достаточно композиции сервисного объекта, который знает как сделать что-то общее - наприемр кэш объектов, сериализацию, тот же Обзёрвер и прочее)

Как я понял, в оригинале предполагалась некая ЦМСка для сателлитов или чего-то вроде?

зы: может лучше переписать кой-чё в ДЛЕ?
зыы: насчёт структуры - ну очень много хардкодинга на всех слоях системы, здесь и ХТМЛ в бизнес-логики (или, например Texter.php - реализует логику представления ???), и заранее заданные проперти в классах и т.д. Если интересно мой мнение - отпишусь как-нить после

сама идея прикольнула, так как для меня, в данный момент актальна - рисую нечто подобное

 

[Alexandre]

Подумать надо ли делать верхний класс для всех объектов

классики ООП этого делать не советуют без видимой на это причины
надо делать интерфейс и осуществлять наследие от интерфейсного класса

 

[vegaplex]

проблема здесь в том, что в ПЫХе отсутствует множественное наследование, и некий класс на каком-либо уровне иерархии классов, востребовавший функциональность этого базового класса, вынужден изначально наследовать по иерархии этого базового класса (либо же имплементировать методы реализуемого интерфейса... то есть солянка ещё та, кроме того, нет никакой гарантии, что в последствии, от этого класса ничто не будет наследовать функционал иерархии, но без необходимости в методах базового класса) , и следовательно вся архитектура системы будет изобиловать параллельными иерархиями классов, добавляющих некий общий базовый функционал по необходимости для себя, и последующего навязывания "потомкам" ненужного им функционала.
Разумеется, некоторые это решают декораторами, проксями и даже видел пару проектов, где народ городит ко всему этому бриджи и прочее, но ИМХО, в большенстве случаев, множество проблем решается делегированием, что я собственно и имел ввидую.

 

[Lightning]

проблема здесь в том, что в ПЫХе отсутствует множественное наследование

В классическом ООП нету множественного наследования и это, ИМХО, правильно.

 

[vegaplex]

разумеется, множественное наследование - наследие времён когда методология проектирования не была востребована и развита как сейчас, и множество людей, просто серьёзно не подходили к анализу проблем ассоциаций объектов. В качестве способа обхода проблемы наследования всех объектов от базового суперкласса, я имел ввиду делегирование, а не синтаксическое "ограничение" ПХП, однако, множественное наследование, именно в этом случае, оказалось бы полезным, НО, до того, когда бы ТС, не начал рассматривать варианты с делегированием.

в любом случае, базовые суперклассы, ИМХО, имеют смысл только в языках с жёсткой типизацией (для ПХП это просто не нужно), либо же для очень-очень специфичных фреймвёрков(с некой особой предметной областью... ну например матрица ) , и то далеко не на всех слоях.

 

[d1gi]

Автор оригинала: vegaplex
привет, понравилась идея описанная как "суть движка" в вики, однако, это скорее должно быть не алгоритм работы (определяющий шаблонизацию) движка как такового, а как одна из возможных стратегий раутинга и маршрутизации запроса, с последующей шаблонизацией каждого раздела сайта на своём уникальном дизигне.
Особо исходник не смотел, но сорь, в целом кажется очень сырым, например, тот факт, что важные системные классы наследуют от некоего Object, который объявлен как абстракт, и далее коммент - Подумать надо ли делать верхний класс для всех объектов. (тема много раз обтиралась, и существует множество ИМХОв, моё такое - что ДЛЯ ВСЕХ это нафик не надо, а в тех случаях, когда мы хотим придать общую базовую ф-ность, нам достаточно композиции сервисного объекта, который знает как сделать что-то общее - наприемр кэш объектов, сериализацию, тот же Обзёрвер и прочее)

код дейсвителньо далёк от идеала... и я с удовольсвием выслушаю мнение профессионального сообщества и внесу изменения в лучшую сторону сечас на вики выложил версию, где убран класс Object, а то он дейсвителньо многих смущает ; )

Автор оригинала: vegaplex
Как я понял, в оригинале предполагалась некая ЦМСка для сателлитов или чего-то вроде? ; )

изначально и до сихпор предполагается достаточно универсальная цмс для создания наиболее распространённых типов сайтиков т.е. с новостными лентами, каталогами, фотогалереями, каментами и т.д...

на счет оптимизации под блоговую систему изначально не думал... но мне кажется потенциал есть и дальше будет видно, вполне возможно и блоги можно будет поднимать )

Автор оригинала: vegaplex
зы: может лучше переписать кой-чё в ДЛЕ? ; )

дело личное каждай в праве делать то, что он считает для себя наилучшим ; )

Автор оригинала: vegaplex
зыы: насчёт структуры - ну очень много хардкодинга на всех слоях системы, здесь и ХТМЛ в бизнес-логики (или, например Texter.php - реализует логику представления ???), и заранее заданные проперти в классах и т.д. Если интересно мой мнение - отпишусь как-нить после

ээм.. а где именно ХТМЛ в бизнес-логики? мнение очень интересно! : )
Texter.php работает только с данными. Texter.tpl их отображает.

Автор оригинала: vegaplex
сама идея прикольнула, так как для меня, в данный момент актальна - рисую нечто подобное ; )

можно попробовать объединиться ; )


ЗЫ: сейчас занимаюсь формулированием логики работы кеширования т.к. без эффективного кеширования на этом движке далеко не уехать

 

[jonjonson]

может лучше переписать кой-чё в ДЛЕ? ; )

Лучше на ось комерц. И ещё пхп бэ бэ прикрутить версии 2, а то 3-я очень сырая.

 

[vegaplex]

Ок, если коротко - на том уровне развития, который имеется чейчас, сказать можно пожалуй только о реализации отдельных модулей, так как сама архитектура, более чем уверен, будет меняться ещё много раз, и просто постом это всё не обхватишь, ибо ИМХО, нужно менять очень много чего (кстати, небольшой совет - подымите у себя форум, где бы каждый подфорум покрывал конкретную часть/слой движка, и конечно же тесты, так как они дают возможность, наряду с другими фитчами, как бы "видеть" слабые места и несовершенства архитектуры)

1. а где именно ХТМЛ в бизнес-логики?
ок, ну ошибся, не ХТМ, а ХТМЛ+яваскрипт
вы действительно считаете, что "универсальный" модуль текстер, относящийся к БЛ должен и имеет право знать размеры создаваемого окна яваскриптом ???
2. про слой доступа к данным в БЛ тебе уже писали
ясен, я не утверждаю, что ОРМ или элементарные датамепперы, шлюзы и прочее должны быть, но как показыват практика, для достаточно универсальных цмс использовать подобные, злом не является, не говоря уже хотя бы об элементарном сервисе абстрагирования БД, кроме того, на проектах использующих универсалки, далеко не каждый программист логики должен знать структуру БД...

про текстер всё, то есть, если это исправить (убрать), то прийдётся перепроектировать...

ну так... куча всего по мелочи, описывать не буду... например улыбнул класс User в файле Engine.php и т.д. (это если не затрагивая всяческих архитектурных жёсткосвязанных элементов как в модулях, так и в их ассоциациях)

порадовало то, что не клонируете руби и близнецов, именно поэтому сказал, что не следует один из возможных способов маршрутизации запроса завязывать как логику движку в целом для достаточно универсальных цмс

в общем, мой совет - подымайте форум маппящий в подфорумы структуру движка.

-~{}~ 30.05.09 20:53:

Автор оригинала: d1gi
ЗЫ: сейчас занимаюсь формулированием логики работы кеширования т.к. без эффективного кеширования на этом движке далеко не уехать

не сейчас, кеширование, как сущность, в идеале должна подключаться прозрачно... если занимаетесь именно самой БЛ кэширования, то имхо, может сперва разработать более-менее стебл движка, и в последствии заниматься уже конкретными модулями... забудьте про новости, поиск, "меню", навигацию и т.д. это всё прозрачно-подключаемые модули к основному каркасу, ИМХО.
удачи

 

[d1gi]

дык неделю назад еще поднял до того как первый пост тут написать

htp://digi.org.ru/engine_forum/