а может ну его, апи этот? берёшь, и где надо ручками запросик пишешь ну если кросс БД надо, Sql Билдером
на самом деле не такой уж и быдлокод получился. Так себе. Правда я еще не знаю, работают ли в похапэ конструкции вида return $this; смотри по коду. Есть $alowedFields. А в методе get есть проверка: все ли поля, которые отосланы в метод можно вызывать. Если поля bum_bara_bum нету в $allowedFields то оно будет просто пропущено. флоппик ткни пальцем что именно из этого мне нужно ага. Только вот я теперь за 3 минуты могу нафигачить около 10 разных вариантов вывода новостей. Или даже предоставить пользователю в админке возможность управлять вариантами вывода. А еще я напишу метод calculateHash (подсчет уникальных хешей на основе заданных параметров вывода - пробежаться по fields, params, filter). Для чего? для того, что б в методе get я мог на основе этого хеша и memcached/APC сделать кеширование. Хотя кеширование можно сделать и на уровне рендеринга. Ну что, по API по прежнему фигня? thanx to Psih за идею реализации API форума. Если б он не предложил это, то возможно я по прежнему писал бы для каждого вывода свой класс.
http://propel.phpdb.org/docs/api/1.3/ru ... teria.html Я больше о идее, тебе можно не завязывать его на ОРМ.
kostyl ну смотри: мне нужно получить id, заголовки, краткое содержание новостей, которые входят в раздел с id=2, отсортировать это дело по полю заголовок по возрастанию. пишу: PHP: <? $list = NewsCollection::create() ->filterCategory(2) ->order('title', 'ASC') ->get('id', 'titlдe', 'content_short'); // я оказался невнимателен и вместо "title" написал "titlдe". Такого поля в базе нет. Но умный метод get не будет производить выборку по нему, так как "titlдe" отсутствует в $allowedFields (см код класса). теперь я отдам $list на рендеринг шаблонизатору. Или перед этим помучаю маленько, например удалю все html-теги.
я тут подумал, какие даты нужны для новостей? ну к примеру: 1) дата публикации (когда новость была создана) 2) дата редактирования (если не редактировали - пусто) 3) дата (MAX из 1 и 2 пунктов, при выводе обычно будет сортироваться по этому полю в обратном порядке) 4) дата действия новости (после этого периода новость становится недоступной, ее нет в выводе, если пусто - новость доступна всегда) ваши идеи?
Одна дата - она же и добавления и редактирования. Вывод сортировать по ней. Действие новости определяется периодом в иниксах int(10)
Ну тогда две даты. Только если ни "если редактировали - пусто", а если даты совпадают значит не редактировали и вовод по редактированию...хотя ... ну смотря как ты хочешь отображать
есть seo-информация (page-title, meta-keywords, meta-description) для контента, новостей, разделов новостей. Хранить это все в каждой таблице или создать другую, в которой хранить только всю эту муру и связь с записями в таблице контента, новостей?
Смотря как у тебя организована связь. Исходя из принципов построения баз данных, то надо в отдельной таблице хранить, хотя бы чтобы не было дубляжа.
сейчас так categories: id, pid, title, ..., meta_k, meta_d, page_title entries: id, content, ..., meta_k, meta_d, page_title content: id, pid, content, ..., meta_k, meta_d, page_title __________________________ как можно сделать categories: id, pid, title, ... entries: id, content, ... content: id, pid, content, ... seo: entry_id, module, meta_k, meta_d, page_title В офисе товарищи сказали: оставляй как есть, выборка из одной таблицы будет быстрее чем из двух. А профита никакого все равно не получишь от такого разделения.
если у тебя для каких то categories entries и content, может быть одинаковая seo запись, то профит будет по месту и апдейту для этих каких то всех одновременно. Но так больше гемороя в коддинге... Ну и запросы чуть подольше. Хотя смотря как реализуешь классы сущьностей.