Идеальная архитектура сайта

Rammstein

PHPClub::News
Идеальная архитектура сайта

Возникла такая проблема - несколько раз переписываю движок для сайта по причине неправильности подхода. Сейчас это уже хоть что-то. Первые две попытки были связаны с созданием actions, т.е. на каждой странице инициализируется один модуль, но это было давно и не правда, т.к. давно уже понял, что это не приемлемо для портала.

test.gm.rikt.ru - последнее из того что делаю. Немного взял у Котерова. Фактически все действия вызывают из шаблона. На всё про всё отводится один контроллер, который отвечает за логику выбора имени шаблона и (пока это на соплях, но всёже) попытка разобрать ЧПУ. Модули - по сути обычные plugin'ы Smarty. За исключением того, что фактически плагин один - load_module, который уже по параметру name загружает другие plugin'ы. Смысл этого в том, чтобы палгины не зависели от шаблонизатора.

Вроде бы всё хорошо, НО при попытке сделать модули более универсальными - в шаблон переходит слишком много логики! В итоге получаем такого рода строки в шаблонах:
{capture name="sql"}is_on=1 AND date>'{$URL_PATTERN_MATCHES.1}{if strlen($URL_PATTERN_MATCHES.2) == 2}{$URL_PATTERN_MATCHES.2}{else}0{$URL_PATTERN_MATCHES.2}{/if}{if strlen($URL_PATTERN_MATCHES.3) == 2}{$URL_PATTERN_MATCHES.3}{else}0{$URL_PATTERN_MATCHES.3}{/if}000000' AND date<'{$URL_PATTERN_MATCHES.1}{if $URL_PATTERN_MATCHES.2 > 9}{$URL_PATTERN_MATCHES.2}{else}0{$URL_PATTERN_MATCHES.2}{/if}{if $URL_PATTERN_MATCHES.3 > 9}{$URL_PATTERN_MATCHES.3}{else}0{$URL_PATTERN_MATCHES.3}{/if}235959'{/capture} от которых дизайнер повесится.

По сути все модули делают одно и то же - выбирают из БД определённые записи, присоединяют данные из других таблиц. Как бы это всё сделать проще?

Во-первых это скорее всего что-то типа PEAR_DataObjects и создание универсальных модулей, способных выводить объекты по определённым правилам. ВОТ ЭТО ГЛАВНАЯ ПРОБЛЕМА - универсальные модули и объекты. Это я и предлагаю обсудить.

В простейшем случае это:
- Вывод списка объектов по шаблону с ограничениями на количество записей
- Вывод отдельного объекта по шаблону.

Опять же что делать с условиями? Безопасность?

Появились вопросы - задавайте. Я тут собрал слишком много в одну кучу и понять это будет достаточно сложно :)
 

Нечто

Психолог РНРClub
при попытке сделать модули более универсальными - в шаблон переходит слишком много логики!
Бред. Ты просто не можешь отделить представление от приложения, и приведенный пример - тому подтверждение.
ВОТ ЭТО ГЛАВНАЯ ПРОБЛЕМА - универсальные модули и объекты.
Не нужно перескакивать на утопию - разберись сначала с первым.
Кроме того, нет ничего "идеального", как и нет ничего "универсального" - не те термины используешь. Везде есть ограничения архитектуры, есть ТЗ, которое описывает последнюю, и т.д. и т.п. Где это?
Про вывод разных сущностей в шаблоне: в этом деле может помочь, например, кейворд helper objects. Теория уже есть давно. Это, imho, практика.
 

BeGe

Вождь Апачей, блин (c)
Народ попробуйте почитать для начала как НАДО делать CMS на основе открытых и работающих вещей, которые польузются попульрностью в мире. Пример Apache Cocoon, Limb и пожалуйста прекратит нести этот бред.
 

Ganer

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

faustmen

Guest
{capture name="sql"}is_on=1 AND date>'{$URL_PATTERN_MATCHES.1}{if strlen($URL_PATTERN_MATCHES.2) == 2}{$URL_PATTERN_MATCHES.2}{else}0{$URL_PATTERN_MATCHES.2}{/if}{if strlen($URL_PATTERN_MATCHES.3) == 2}{$URL_PATTERN_MATCHES.3}{else}0{$URL_PATTERN_MATCHES.3}{/if}000000' AND date<'{$URL_PATTERN_MATCHES.1}{if $URL_PATTERN_MATCHES.2 > 9}{$URL_PATTERN_MATCHES.2}{else}0{$URL_PATTERN_MATCHES.2}{/if}{if $URL_PATTERN_MATCHES.3 > 9}{$URL_PATTERN_MATCHES.3}{else}0{$URL_PATTERN_MATCHES.3}{/if}235959'{/capture} от которых дизайнер повесится.
Какое убожество. Убил бы..
 

ForJest

- свежая кровь
faustmen
Кого убил бы? Дизайнера который уже и так повесился? :)
 

Rammstein

PHPClub::News
Так, писать не получается, но я тут ежедневно читал, что вы тут писали =)

2 Нечто
Это не бред - это попытка сделать универсальный модуль... хотя, пожалуй, бред присутствует :) В том то и проблема: больше отделяем - получаем меньшую универсальность

2 BeGe
Ориентироваться на этих монстров? Зачем? У них далеко не всё так гладко.

2 Ganer
Ты не прав (или я просто неправильно тебя понимаю). Организация поратла с кучей информации на страницах методом action'ов - геморой ещё тот. Сделать модуль проще =) Шаблон решает (с)

2 faustmen
Ни надо)


Как результат моих размышлений - пытаюсь создать своего рода ADO =) Слишком громко) Посмотрел более тщательно PEAR DB_DataObject - фигня. Нецелесообразное использование запросов. Зачем посылать 10 запросов, когда можно обойтись одним и хранить результат? Не, ну понимаю если нужно извлечь 10 000 габаритных записей. Тут лучше по одной, но не забивать особо память (даже на достаточно хорошем хостинге под один процесс её не так много выдают). Делаю фактически тоже, но более рационально (IMHO). DO - база для всего остального (кидайте камни - всёравно не переубедите). Будет правлиьно организовано хранение объектов - будет и больше количество менее универсальных, но более правильных, в отношении логики, модулей.

Ещё, предлагаю поднять вопрос о ЧПУ. Нужно ли это? Как реализовать? Своё мнение выложу в следующий раз, а сейчас уже полночь - пора спать.
 

Нечто

Психолог РНРClub
Rammstein
Это не бред - это попытка сделать универсальный модуль...
Хорошо. Скажу по-другому: эта попытка совсем не удалась.
Будет правлиьно организовано хранение объектов - будет и больше количество менее универсальных, но более правильных, в отношении логики, модулей.
То, что хранилище будет правильно реализовано, не значит, что у тебя получатся "правильные" модули - мой вывод из приведенного в самом начале куска кода.
Тем не менее, как я понял, тебя интересует ORM, и ты считаешь, что это универсально? ORM удобен тогда, когда изначально известны потенциальные "объекты" и то, что с ними будем делать. Это не универсальность, а скорее адаптивность: генерируем набор классов + таблицы БД под каждый проект и вперед к эстетике - красивый ОО-код.
 

Rammstein

PHPClub::News
2 Нечто
Есть уже готовые решения, отвечающие следующим запросам?
- возможность древовидной организации структуры хранения данных (или достаточно простая расширяемость до этого уровня)
- возможность задания связей типа: 1:1 1:M M:M
Плюс желательно более рациональное использование запросов или продвинутое кэширование.

Так кто-нить по ЧПУ выскажется?

-~{}~ 02.09.05 16:46:

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

Нечто

Психолог РНРClub
Rammstein
Готовые есть (в основном под php5) - в поиск по ORM.

В частности у меня есть своя библиотека древовидного репозитария такого рода, что ты описал (но это не ORM).
1. В каждом репозитарии (базе данных) есть коллекции (пара таблиц), которые и являются деревьями. Алгоритм - adjacency list (nested sets тормозят при обновлении большого объема). Запросы через xpath-подобный синтаксис (все фичи, какие можно было уместить в 1 запрос). 1 xpath-запрос = 1 оптимизированный sql-мегаджойн. Есть еще экспорт/импорт XML.
2. Сейчас думаю по-поводу узлов-ссылок, которые позволят делать кросс-связи в рамках коллекции или даже всего репозитария.

Реализовать это несложно, так что если будут затыки, возможно смогу подсказать. Был только гемор по-поводу оптимизации запроса и реализации фич xpath. Еще нужно сразу решить, будешь ли вводить узлы разных типов (связь, текст, дата и т.п.) или пихать все в одну таблицу значений (что, естественно, проще). Оверхеды сего творения, имхо, все же окупаются удобством и скоростью разработки.

Так кто-нить по ЧПУ выскажется?
Что про это говорить?
 

Rammstein

PHPClub::News
2 Нечто
Это на MySQL или в XML? Видимо в MySQL...

Про ЧПУ - нужно или нет. И как реализовать разбор. Т.е. для разных модулей этот разбор разный должен быть. Или изначально проектировать модули под ЧПУ (так проще)?
 

BeGe

Вождь Апачей, блин (c)
Ребята, а вы не пробывали сначала изучить готовые решения - перед тем как писать своё ?!!, а то все идеальная структуруа, самая кртуая CMS... Посмотрите что есть - какие там проблемы, каие проблемы были, как они решались.
 

Нечто

Психолог РНРClub
BeGe
Гениально. До тебя никто не догадался.
Не держи других за дураков.
 

maxim

Новичок
2 Rammstein
----
Первые две попытки были связаны с созданием actions, т.е. на каждой странице инициализируется один модуль,
----
А сделать карту страницы и на ней выполнить несколько actions никак? А шаблон оставить дизайнерам. Или ты под шаблоном понимаешь набор элементов страницы (форма поиска, голосование, статья, баннеры, последние новости ...)?


---
Был только гемор по-поводу оптимизации запроса и реализации фич xpath.
---
Решил?
 

Rammstein

PHPClub::News
Как я понял, чтобы сделать большее количество модулей, обращающихся к данным, нужно организовать более простой механизм работы с этими данными. Прочитал про DAO на sun.com. Вроде интересная идея. Но опять же нужно думать об оптимизации. Всё больше и больше думаю о том, что кто-то сильно головой ударился, делая PEAR DB_DataObject...
 
Сверху