Меню
Что нового?

Вопрос по архитектуре:)

c0dex написал(а):
Я спросил если у тебя изменится шаблон, что ты будешь делать? Как приложение узнает, что надо перегенерировать кеш?
Нажмите для раскрытия...
Проверка md5 кеша шаблона, хотя легче сделать функцию которая будет указывать что нужно перегенерировать
 
fixxxer написал(а):
Кэшировать надо прежде всего результаты выполнения sql-запросов и подобных тяжелых операций, остальное опционально. Если использовать нормальные шаблоны (которые написаны в php или компилируются в php, а не какое-нибудь дерьмо с заменой регулярками), все и так будет достаточно быстро. По крайней мере, пока это станет узким местом, можно внести много других исправлений - не надо оптимизировать то, что не тормозит.



Очеь просто, не надо делать ничего, никаких глупостей. Нет никаких "опасных" символов. Есть ошибки программиста, когда в определенном контексте строка выполняется как код или инструкции или не приводится к заданному формату. То есть если пишешь в базу - используешь плейсхолдеры, выводишь html - использовуешь htmlspecialchars, пишешь, например, rtf или pdf - експейпишь как там в нем положено.


Это еще зачем? Что, html - единственно возможный формат данных?

То есть security.php надо выбросить.
Нажмите для раскрытия...
Спасибо!
 
artapp-ds
Учти только, разные строки могут давать одинаковый md5 ;0
 
Встречающиеся в реальном мире строки в общем-то скорее не могут, чем могут. :) Вероятность есть но почти нулевая.

Альтернатива - sha1, sha256 и т.п.
 
Ну да, а твоя реализация сейчас просто идеальна? ;)
 
Похоже в голове ты полагаешь, что хэши файлов считает дух святый. Тебя наверное удивит, что количество ресурсов, требуемое на это сравнимо с парсингом этого самого шаблона.
 
А зачем парсить шаблон? зачем лишняя прослойка для шаблонизатора?
 
Хочу сделать что то типа следующего: в массив записываются все значения текущей страницы (те что будут выводится в шаблоне), контроллер кеша проверяет есть ли уже такая страница с такими значениями, если есть выводит из нее, если же нет, то создает ее, сохраняет и выводит. Да вот такая вот лишняя прослойка, и я понимаю что в шаблоне того же интернет магазина сотни переменных, но кто мешает логически их разделить и выводит по кусочкам(разбить на view's)? Например footer в 65% всегда один и тот же. Еще можно сжимать html, css, js. Тем более что фреймворк студийный, которым будут пользоваться максимум три разработчика, которые знают что и как нужно делать с ним.
 
Тем более что фреймворк студийный, которым будут пользоваться максимум три разработчика, которые знают что и как нужно делать с ним.
Нажмите для раскрытия...
Тогда ОНЛИ любой известный фреймворк (ZF/Kohana/Yii), потому что доделывать за вами результаты трудов, придется таким как мы, уж простите. Тут мало найдется народу к кому не приходили клиенты студий и не просили там что-то доделать после того как студия слилась.

PS: В общем я возможно слишком резок, но все таки так, как ты задумал делать не стоит. Для кеширования вывода есть готовые решения. Так же как и для кеширования чистых данных.
 
c0dex написал(а):
Тут мало найдется народу к кому не приходили клиенты студий и не просили там что-то доделать после того как студия слилась.
Нажмите для раскрытия...
А как же документация и расписание на пальцах что и как. Да и вообще 70% примерно хватает админки:)
 
artapp-ds написал(а):
А зачем парсить шаблон? зачем лишняя прослойка для шаблонизатора?
Нажмите для раскрытия...
А не рано ли тебе писать движок, если на такой вопрос ответа не знаешь?

А как же документация и
Нажмите для раскрытия...
Смеешься? Если большинство из них не знают, чем нужно по клавиатуре бить, думаешь, что они слышали про документацию?
 
Войдите или зарегистрируйтесь для ответа.
Сверху