Вы уж определитесь: или реально писать и тестировать код на всякой фигне или же выкидывать ненужный код сразу, дабы не засорять.
MAXUS пишет:
при организации динамического кэша.
Стукните по башке архитектору томиком GoF (или ещё чем тематическим) и используйте адекватные задаче шаблоны проектирования.
Ну, то что __DIR__ в 5.2 не работает это понятно. Просто кусок кода выдрал из того, что под 5.2 тоже должно работать.
А насчет шаблонов. Можно непосредственно мне по башке стукнуть и подсказать, какой адекватный шаблон использовать для кэширования в шаблонизаторе?
Опишу задачу.
Есть файл вида (HTML со вставками кода шаблонизатора). Он парсится и создается файл с классом с определенным именем в папке с кэшем (назовем это так).
При запуске страницы сначала проверяется скомпилированный кэш-файл с классом. Если его нет или он протух (определяется по нескольким параметрам, не только по времени файла), то файл вида перекомпилируется.
После этого используется скомпилированный класс.
Прям любопытно стало, это стандартная смс была, которая автоматически постится, типа "я занят" насчет шаблонов или что-то конкретное имеется в виду и есть какой-то шаблон, который решает задачу?
Дополнение
ЗЫ Мне кажется, что количество невинно убиенных томиком GoF в мире (или только в России) растет неоправданно быстрыми темпами
class_name
Имя класса. Воспринимается без учета регистра.
autoload
Вызывать ли по умолчанию __autoload.
Там фишка в том, что я при помощи class_exists по сути проверял наличие файла. У меня идет проверка есть ли файл и не устарел ли он. Но вместо file_exists я наивный хотел использовать более 'целевую' функцию class_exists, но оказалось, что был не прав.
В принципе, если бы не надо было проверять не устарел ли файл, то я бы воспользовался флагом autoload в class_exists, но у меня, если файл устарел, его надо поменять и только после этого он используется и, соответственно, загружается.
Столкнулся с интересным нюансом при организации динамического кэша.
При использовании автозагрузки классов всем известная функция class_exists(), которая должна проверять, существует ли класс, не просто проверяет, но и загружает класс. Выявляется это и несколько вводит в заблуждение, если после вызова функции динамически изменить класс, т.е. переписать файл.
Вместо ожидаемого (мной) 'Класс some_class существует, 2', на экран выводится 'Класс some_class существует, 1'...
В принципе, ничего удивительного тут нет и логика понятна. Class_exists() проверяет наличие класса, т.е. был ли он загружен, при этом при обращении к классу происходит его автозагрузка. Далее динамические изменения файла уже ни на что не влияют, т.к. файл в новом виде уже не подгружается и используется старый класс.
Из-за того что база будет достаточно большая - стараюсь избежать JOINов с заботой о производительности.
Тебе совершенно верно подсказал IllusionMH. Послушай умного совета. А Join не будет напрягать базу, если ты индексы правильно составишь.
У тебя есть две таблицы с уникальными индексами: Фильмы и Продюсеры. Фильмы не могут дублироваться (id - Primary key), Продюсеры не могут дублироваться (id - Primary key). Третья таблица будет содержать id продюсера и id фильма и поскольку это индексированные поля, то JOIN вообще не будет напрягать выборку.
А то, как ты собираешься свою проблему решать, приведет к хаосу в таблице, в том числе увеличит ее размер на диске.
Первый скрипт выполняет передачу данных ассинхронно.
При клике на кнопку начинает выполняться второй скрипт, который считывает результат выполнения первого скрипта, но первый скрипт не закончил свое выполнение на 100%. В результате второй скрипт считал не полную информацию
Есть для такой ситуации что-нибудь аля $(document).ready()?
1. А насколько, в принципе, оправдано наличие кнопки, которая запускает второй скрипт?
1.1 Можно ведь инициировать запуск второго скрипта после того, как выполнится первый. Даже при асинхронном запросе.
1.2 Ну, или по завершению первого скрипта создавать объект с полученными данными, а по нажатию на кнопку второго скрипта проверять наличие этого объекта и запускать второй скрипт только если этот объект существует.
2. А кнопку при генерации рисуй сразу с атрибутом disabled, а по выполнению первого скрипта удаляй этот атрибут. Только в этом случае см. п.1
Каждый пункт слева добавляет что-то к фильтру - и на каждый новый запрос, о чём я и написал в первом вопросе. В сумме их и выходит 30-80 штук.
А ты можешь ТЗ поподробнее сформулировать? Простыми словами, что конкретно требуется? Без привязки к реализации. Типа сначала слева категории такие-то. В листинге соответственно картинки. Ткнули на картинку, как должна изменяться менюха слева и что должны получить в листинге? И т.д. Просто заинтересовала задача. Интуиция подсказывает, что ход мыслей не правильный. 80 запросов - этому явный признак.
По результатам тестов могу сказать, что реализация на джойнах не даёт существенного преимущества, а вот вариант Мелкий с групповыми функциями и хевингами действительно работает в 2 раза быстрее - за что ему большое спасибо
Вопросы:
1. Так надо, что все запросы в body видны?
2. Если я правильно понимаю, слева в меню все равно количество товаров в категории выводится без учета текущих фильтров. Зачем тогда огород городить? Просто создать таблицу, в которой фиксировать количество товара в категории. Принцип лучше посчитать один раз и сохранить, чем каждый раз пересчитывать. Летать будет.
ЗЫ Да и с комбинациями категорий теоретически можно заморочиться. Как вариант... В таблице, которая хранит количество товаров по категории, ключ делаешь хэшем из комбинации категорий. Сохраняешь при записи товарной позиции (или при присвоении товару категории).
Типа hash = для сына+солидный+на день рождения. Только при создании ключа сортируешь свойства определенным образом. Например, по алфавиту. Тогда hash в примере перестроится на для сына+на день рождения+солидный...
ЗЗЫ А вообще, судя по тому, что у тебя в body генерится более 80 запросов, ты что-то явно делаешь не так и оптимизация заключается как раз в том, чтобы этот косяк выкупить. Подозреваю, что после этого у тебя и без специальных таблиц летать будет.
Ну и всё-таки ещё разок про определённость и доступность...
Да я ведь и не спорю. Просто речь была о кэше и о предложении реализовать его через __get(). Я просто отметил, что эту особенность надо учитывать. А так, кмк, это типичный реестр с некоторыми нюансами.
В первом случае - не определена и, следовательно, не доступна; во втором - определена и доступна (поскольку public).
Ну дак. А я о чем говорю? Соответственно, если свойство определить, то __get() не отработает. Соответственно, в случае с задачей создать кэш объекта надо это учитывать. Синглтон так создать можно, а вот кэшировать не получится.
Ну и ты вот скажи, удобно читать вывод var_dump без тэга <pre>? Я может чего не понимаю, вполне допускаю это, но в данном случае идет вывод string и особой роли не играет. А меня лично напрягает постоянно в примерах дописывать <pre> и </pre>... А по иному читать вывод не удобно. В данном случае скопипастил код, запустил и все понял без дополнительных изощрений. Или я не прав?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 329
