Да, библиотеки меня как раз заинтересовали благодаря возможности ведения логов, контроля ошибок и SQL — инъекций. Пытался сам что то написать, но не смог создать универсального решения для сложных запросов с вложенными SELECT и WHERE, и забросил это дело.
Да, вижу с разделителями я многократно погорячился :/
Получается хранить в одном поле адреса вида /profile/121/56/ тоже глупо,
так как при малейшем изменении прийдется регэкспами перелопатить все таблицы.
Насчет разделителей:
В случае если мы имеем список фотографий одного пользователя, решением в лоб вижу запись в поле `foto` таблицы `users` через разделители список названий фотографий. Решение как я понимаю сработает быстрее чем создание дополнительной таблицы и занесение туда каждой фотографии.
Как бы Вы это решили? Например для среднего проекта в 1000 пользователей / сутки (ориентация проекта — отнють не фотографии, однако они необходимы)
С затратами времени и памяти от инклудов :)
Аналог #include при создании страницы сразу вставляет файл в указанный блок, в отличие от <? include(''); ?>
Можно разделять и структурировать файлы так, как Вам удобно.
один xml файл может выглядеть так:
#include catalog.xml
#include blogs.xml
#include work.xml
#include repository/global.xml
page — это названия классов для страниц. Можно использовать любой свой префикс (всё настраивается в скрипте). При компиляции страницы index (или какую вы указали) будет выборка <page.*> (где * — это название страницы). Структурные блоки также настраиваемые.
Можно написать например [!page.index] и т.д.
sincous, area, unicate — классы можно назвать произвольно. Я так назвал, только ради подсветки синтаксиса «неправильных» html тегов в Zend Studio.
Альфа версия парсера уже написана, на ней работает сейчас 2 «подопытных» сайта (sevlux.net и nouts.net смотреть исходники HTML в самом низу дебаг строка).
Проекты небольшие, по времени генерации страницы, и затратам памяти:
pageGenTime:0.00451 sec. memoryUsage:238.34375 Kb
pageGenTime:0.00801 sec. memoryUsage:440.703125 Kb
Пример: pastebin.ru/301151
Бизнес-логика в <meta.index>, html шаблон вывода <strict.index>, затем всё это вставляется в основной шаблон для всех страниц <area.simpleTemplate>
Наверное стоит ли хранить закэшированную статичную версию сайта?!
Вот пример:
pastebin.ru/301741
Попробую PDO.
Поисковик собирает данные из нескольких таблиц в одну и генерирует адрес для каждой страницы.
В общем принцип что все циклы, и некоторые условия содержаться в файле шаблона.
Что то вроде:
<?
//выборки из mysql и вычисления
?>
И отдельным файлом отображение:
<? while ($assoc = mysql_fetch_assoc($select['users'])) { ?>
<? echo $assoc['name']; ?>
<? } ?>
Какие могут быть проблеммы в таком подходе?
Получается хранить в одном поле адреса вида /profile/121/56/ тоже глупо,
так как при малейшем изменении прийдется регэкспами перелопатить все таблицы.
В случае если мы имеем список фотографий одного пользователя, решением в лоб вижу запись в поле `foto` таблицы `users` через разделители список названий фотографий. Решение как я понимаю сработает быстрее чем создание дополнительной таблицы и занесение туда каждой фотографии.
Как бы Вы это решили? Например для среднего проекта в 1000 пользователей / сутки (ориентация проекта — отнють не фотографии, однако они необходимы)
Аналог #include при создании страницы сразу вставляет файл в указанный блок, в отличие от <? include(''); ?>
один xml файл может выглядеть так:
#include catalog.xml
#include blogs.xml
#include work.xml
#include repository/global.xml
Начал заниматься сайтом и оптимизировать всё остальное.
Можно написать например [!page.index] и т.д.
sincous, area, unicate — классы можно назвать произвольно. Я так назвал, только ради подсветки синтаксиса «неправильных» html тегов в Zend Studio.
Проекты небольшие, по времени генерации страницы, и затратам памяти:
pageGenTime:0.00451 sec. memoryUsage:238.34375 Kb
pageGenTime:0.00801 sec. memoryUsage:440.703125 Kb
www.sincous.com/conception.png
pastebin.ru/301151
Бизнес-логика в <meta.index>, html шаблон вывода <strict.index>, затем всё это вставляется в основной шаблон для всех страниц <area.simpleTemplate>