Pull to refresh
24
0
Send message
А если в этот период поисковый бот зайдет? не хорошо получится.
Наверное стоит ли хранить закэшированную статичную версию сайта?!
ошибся, процедурное программирование.
Если записать в массив из mysql_fetch_assoc а в отдельном файле вывод с помощью foreach сделать, будет правильнее?

Вот пример:
pastebin.ru/301741
Да, библиотеки меня как раз заинтересовали благодаря возможности ведения логов, контроля ошибок и SQL — инъекций. Пытался сам что то написать, но не смог создать универсального решения для сложных запросов с вложенными SELECT и WHERE, и забросил это дело.

Попробую PDO.
Адреса я храню сейчас например в поисковике.
Поисковик собирает данные из нескольких таблиц в одну и генерирует адрес для каждой страницы.
хабра редактор съел table ,tr и td :(
В общем принцип что все циклы, и некоторые условия содержаться в файле шаблона.
Я чаще всего пытаюсь отдели логику от представления на примитивном уровне.
Что то вроде:
<?
//выборки из 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
Расширил статью, написал о основных синтаксических конструкциях и глобальных правилах.
Скорее наоборот :)
Начал заниматься сайтом и оптимизировать всё остальное.
Жаль что незнаком с макросами в C/C++. Сейчас почитал, и понял что необходимо развивать в этом направлении.
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
Обновил картинку, с фотошопом не особо дружу, но надеюсь так будет немного нагляднее.
www.sincous.com/conception.png
Пример:
pastebin.ru/301151
Бизнес-логика в <meta.index>, html шаблон вывода <strict.index>, затем всё это вставляется в основной шаблон для всех страниц <area.simpleTemplate>
Да, чуть позже расширю статью :)

Information

Rating
Does not participate
Registered
Activity