:? Сначала делал так: Человек заходит и запрашивает раздел. Раздел проверяется на наличие в массиве, после чего подключается нужный контроллер, а в нем идет загрузка данных из необходимой таблицы. В контроллере задавался title и keywords, которые могли зависеть или не зависеть от статьи. Теперь хочу лучше, пора расти из этой дыры. Что пришло на ум: URI каждой страницы и раздела хранить в таблице pages. При обращении к странице, класс page делает запрос в базу, оттуда получает описание (только для раздела), title, keywords, descripiton, имя контроллера. Далее, подключает контроллер, который уже дополняет заготовок страницы необходимым контентом. Но здесь кроется несколько минусов: 1) Разделов несколько, следовательно, описание раздела тысячам других страниц не нужно. 2) Постоянный поиск по строке в базе 3) +1 еще один запрос, на получение этих title, keywords. Есть и другое решение, например, для разделов сделать загрузку из таблицы pages, а для обычных страниц, сделать title & keywords в таблице страниц. Например, в таблице news, добавить необходимые поля. Плюсы второго подхода в том, что нет необходимости делать поиск по строке в базе, нет лишнего запроса, а "все" данные можно вытащить одним запросом. Что скажете? Как у вас устроено?
От этого не уйдешь. Я два дня рисовал трехуровневые модели. В результате сократил таки до 2х (за полной ненадобностью 3го в маленьких вещах). А когда сделал, то осенила идея добавить связи. И тут меня пробило - получилась копия Zend_Table/Row Удалил все к черту. Еще полчаса вертел Zend_Table. Понял что мне не хватает мелких фишек под мой стиль. И за час написал свои модельки заново. Вот так и будем ездить.
У меня вот такая карячка: PHP: <?php $MainView->AddVar('KEYWORDS', ViewHelper::GetKeyWords()); Вообще, это класс есть в котором статические свойства. По проходу сценария в него собирается все кейвордсы. Данные беруться просто: из связанных данных как бы, ассоциированных архитектурой. PHP: <?php ViewHelper::AddKeyWord($Node->CatName); foreach ($Node->Tags as $Tag) { ViewHelper::AddKeyWord($Tag->Name); } То есть у меня уже все данные "и так хранятся" и "и так загружаются". Ну вот, если тебе интересно.
это тестовая версия =) и кстати, неплохо работает...пока ты мне скажи где нужны таблицы и массивы? разве только связки модулей писать
ты щас хочешь сказать, что возможность впрямого управления роутами из шаблона через УРЛ, есть велосипед? =)
роутами ли? Или все же вызов левых экшенов? И да, можешь не акцентироваться на своем коде. Поскольку я в нем не разбирался, а смотрел очень поверхностно. Поэтому как оно у тебя на самом деле - понятия не имею.
там УРЛ есть роут, по сути. без всяких левых таблиц, за исключением автолоада. ну реализация там не очень, да. но на идею назжеть не смей =) ты мне скажи, где тебе 3х уровневая модель понадобилась?
Конкретная задача - заготовка под систему уровня ERP. Фокус в том, что если писать все правильно, то одному мне надо не меньше года. Если писать на костылях, то можно уложиться в 3 месяца. А у меня заказ очень сильно перекликается с этим. Приходится себя бить по рукам каждый час, чтобы не усложнять безмерно текущую задачу.
Завернул однако. В 3х словах.... DataTransportObject - собственно структура не имеет ничего и не делает ничего кроме контроля за своей целостностью. Плюс может содержать в себе ссылку на породивший объект (но я еще не решил, слишком спорный момент). И возможно валидацию (хотя это уже слишком). DataMapperObject - маппер. может быть несколько. Интерфейс ввода/вывода. Занимается отображением структуры в куда угодно. Файл, БД, Форма. DataServiceObject - сервисный слой и логика. В ERP она есть и ее весьма много, плюс самих моделей немало, а в обычных задачах 2-3 модели и для нее хватает места в контроллерах или DTO. По сути это почти проекция MVC на модель.
Kreker ты несколько мудришь. У тебя есть некий статический контент - он собирается одним контроллером независимо от раздела (а отдается уже сервером, как статика). У тебя есть некий динамический контент - он легко отдается каждый своим контроллером в зависимости от используемых моделей.
Так в таком случае, где хранить данные для метатегов? У каждого раздела может быть своя таблица (или несколько).