The-Stig_666, скачайте актуальную версию Mootools с официального сайта и подмените нею болезненный файл.
siv1987, да я смотрел только шаблонизатор. Больше меня данная си эм эс не интересовала. IPB - мой первый сайт был на нем. Много пересмотрел. Могу сказать одно - пускай выпускают фиксы безопасности дальше. :)
Тогда PHP не будет. Ибо echo это и есть часть встроенного шаблонизатор. Когда вы запускаете php файл, он может содержать в себе хоть миллион <? ?>, но именно эти скобки говорят интерпретатору о том, что выводиться не HTML, а используется встроенный шаблонизатор. То-бишь, PHP это и есть шаблонизатор. Так что даже от echo не убежишь - это часть шаблонизатора. Которая кстати еще и буферизируется, а значит предварительно записывается в память, а это уже не вывод один в один.
А с "русским" ООП (ради ООП) я уже знаком через DLE и IPB. Спасибо. Но таких оптимизаций нам не надо. 😂 Пока что ни один движок с подобным функционалом не работал быстрее моего. Значит могу себе позволить шаблонизатор. :)
Очень мало фреймворков на меня шиты. DOMElement HTML5 мне подошел, но к сожалению, он единственный написанный подходяще для моего проекта.
О ну да :) . Пик оптимизации. А зачем вам для единоразового использования свойства заносить его в локальную переменную? Да и чем ваше статическое свойство отличается от глобальной переменной? Это и есть глобальная переменная + наймспейс (упс, она зачем-то пропущена через метод... -20х к производительности). Не вижу ООП. Лучше посчитайте во сколько шагов вы получаете обычное anyname. А я бы на вашем месте раз бы проверил входящие данные, а потом бы делал с безопасным объектом все что нужно через функции или даже методы, но без такого извращения.
Кстати. В упор не понимаю. Зачем дублировать свойство в локальную переменную? Вы так надеетесь компенсировать низкую производительность? - Зря. Синтаксис мешает? - Создавать дубликат каждый раз такой же выход, как писать global в каждой функции в моем случае. Хотя нет. global хотя бы являеться обычной ссылкой, а тут как минимум 3 вызова перед созданием ссылки. :D
Только не говорите что метод post еще и генерирует свойство? Ой. Как все плохо.
Вообщем не будем. То что у нас разные взгляды ничего не означает. Вы пишите быстро, но медленное, а я пишу быстрое, но медленно. Это как сравнивать отшлифованный Apple и созданный роботом Somsung. Вот и вся разница.
bay_ebook, встроенный шаблонизатор не знает HTML вообще. :) Я уже молчу о классах.
И не окупиться производительность. preg_replace вариант шаблонизатора (как в Smarty) работает в 4 раза медленнее, а встроенный шаблонизатор это не очень удобно, во-первых, не контролируемо, и не так уж производительно каждый раз искать <? ?> и обрабатывать short_tags. :)
Шаблонизатор кэшируется. Да и без кэша 2-4 миллисекунды для обработки шаблона по сравнению с 12-60 миллисекундами Smarty. XML работает быстрее за регулярные выражение, хотя бы через строгую фильтрацию.
Я их обрабатываю как раз классом. Просто результат записываю в глобальный объект, а не в $зис->шпекси->крекси.
bay_ebook, в GET, POST, COOKIE попадают только безопасные данные. И я работаю с ними как с безопасными, а не каждый раз вызываю их обработку. Шарите? :) Если мне надо например запретить html, я не лезу в методы, а в JSON карте допустимых значений переписываю TYPE на text с html и усе. Все входящие данные с определенным индексом записываются с вырезанными тегами (либо можно закодировать, как уже нужно будет :) ).
GET нужно либо удалять либо хранить в оригинальном виде. Не понимаю, что вы там расширять собираетесь? Может вы еще пишите что-то типа Singleton::get('GET')['var']->toUpperCase(). Нее, ну извините, это бред, а не функционал.
ООП versus процедуры, это вечный спор. И давайте его не будем развивать. Машины любят больше процедурный код. Поэтому, если говорить именно об оптимизации программы, процедуры впереди. Если говорить о легкости масштабируемости кода, тогда ООП выигрывает. Но нужно тогда подстраивать ООП под себя. А если мне неудобен синглтон, зачем мне он? Что я выиграю используя ООП? - Только проиграю в производительности.
Мне дает существенный плюс использование DOMDocument в качестве шаблонизатора. Это действительно ООП. А вы небойсь используете регулярные выражения в шаблонизаторе. Вот видите какие мы разные. Я действительно контролирую качество, валидность кода, имею легкой доступ к классам и идентификаторам, а вы там GET в синглтоны пихаете. :D
Да? А я вот очищаю $_GET и записываю только те ключи, которые прошли валидацию. Представьте, делаю это без ООП!
Мне они нужны в первую очередь через наследование и эмуляцию неймспейсов, а уже потом объекты. Признаюсь, именно объект. контекст развит слабо. Но нужно различать объект от свойства, а не все писать в стиле ООП. Конфигурация это объект! И мне незачем обрабатывать то что я сам написал. А если и нужно будет, я сделаю это во время использования элемента массива.
Вы пишите ООП ради ООП. Усложняете программу и запутываете себя, пишите медленный код, которому не поможет никакой кэш. Задумайтесь-ка вы. ;)
Хорошо. Ошибся. Это ссылка. Но все-равно это более оптимизированный вариант чем ООП.
Вот и я не понимаю. Я говорю вам о служебных переменных, а вы мне ООП предлагаете.
Как раз меня это и не устраивает! Я делал замеры использование памяти и продуктивности оператора. global является указанием, что нужно использовать переменную за граню подпрограммы. global ничего не создает, в т.ч. ссылок! По всем тестам это работает лучше за заурядный сингтон. global = 1. указатель. Синглтон = 1. метод. 2. Метод set-get. 3. return. И в придачу ужасный синтаксис. Это часто бывает полезно, но не для глобальных массивов. Я уже говорил, что $_GET и прочее не зря сделано именно глобальным массивом, а не одиночкой. Вы согласны?
А не устраивает меня потому что нужно вести учет global (не дай Бог, где-то не напишешь) + опять таки шило на мыло по быстроте коддинга.
Закроем вопрос. Нельзя, так нельзя. Пока буду мучатся с Registry::.
bay_ebook, все с логикой у меня нормально. 20 родительских классов. Я использую наследование, но не направо-налево. И причем здесь наследование вообще? Проблема в приставке self, $this, Registry - нужно просто $. Какой конструктор не пиши, что не наследуй, будет либо $this либо self, либо имя класса. Мне нужен доллар. Я разделяю ООП и обычную конфигурацию. А для этого мне нужен глобальный массив. И точка. Понимаете? :)
Вот такое Registry::$LANG['DATE']['DAY_SHORT']['Tue'] или такое $this->LANG->DATE->DAY_SHORT->Tue + еще копирование ссылки на этот объект в __construct это пик дебильности и транжирства ресурсов. Здесь уже никакой кэш не поможет. Это и есть не оптимизированная архитектура. И логика в таком ООП разве только для самой программы, а программист-человек всегда будет путаться в $this. Глобальный объект это не $this. Глобальный объект это вообще не свойство. PHP дает нам отличный $_GET, $_POST. С вашей логикой писали бы Singletone::getInstanse('GET'). Извините меня тоже.
