Оно это так, мне тоже так удобней, но это приводит к нарастанию логики внутри шаблона, от чего многие хотят избавится, и думают, что создав отдельный слой — шаблонизатор, всё будет гуд, но это утопия. Если нужно избавится от логики в шаблоне, то нужно работать над архитектурой системы, над архитектурой компонента представления. Решением я вижу только в детализации шаблонов. Если же архитектура требует логики в шаблоне, то люди, не извращайтесь, используйте пхп :))
Если удастся вытащить полностью логику из шаблона, то конечно лучше применить простые вставки, типа %v[head]%, тогда мы ещё и предотвратим использование php. Когда не получается обойтись без логики в шаблоне, тогда лучше не извращаться и применять php. :)
> Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
Поэтому я говорю о детализации. Шаблоны могут быть вплоть до минимальных единиц информации в системе, в моём случае – это сущности. В реальности может получиться, что не потребуется создавать шаблон для новости, так как новость соберется из шаблонов её заголовка и текста. Избавится от необходимости логики в шаблоне реально, и при этом иметь супер гибкость. Всё зависит от архитектуры системы и вопрос этот не прост для обсуждения здесь. Конечно, компонент представления получится не легким, но это как с детализацией трехмерной графики – отличная картинка за большее процессорное время. Во всяком случаи мы не анимацию делаем, и может использовать многоуровневое кэширование.
Представление — это отдельный компонент системы со своей логикой предназначенной для подготовки данных для рендеринга в соответствующий формат, обычно в html. Шаблон — это как скин у десктопных программ — ему не нужна логика. Почему вы считаете шаблон видом? Если в шаблон запихивать логику, то рано или поздно рождаются монстры типа смарти со своим фактически языком программирования. А у нас какая цель — чтобы шаблон просто отобразил то, что ему дали.
На сегодняшний день ещё нет идеально реализованного «вида», а ведь поверьте, через детализацию шаблонов в них даже циклы и условные операторы не нужны будут.
Загибулина в том, что первостепенна цель, а не инструмент, абсурдно судить какой молоток правильный не зная какой гвоздь забивать. В общем, сколько не говори, как хороши всякие методики, паттерны и прочее, о каждом я знаю, но выбираю или придумываю своё, именно то, что лучшим образом приблизит цель к осуществлению.
Спасибо за пожелания, приятно что спустя более полугода появляются новые комменты :)
Вы не первый, кто упрекает меня в использовании статичных классов для модулей движка. Да что там, я сам, когда только начинал делать двиг, пытался сделать красивую правильную объектную структуру кода, в частности для модулей использовался паттерн singliton. Но когда прорисовалась полностью архитектура движка, решено было отказаться от правильной объектности в коде не в ущерб его гибкости, применение статичных классов для модулей только упростило программный код.
Архитектура движка такая, что желание в будущем добавлять новую логику решается через обработку событий, незачем что-то переопределять, когда не нужное можно просто отключить. С умными книжками по ооп я очень даже знаком, даже более. Только вот идеология движка не в применении объектно-ориентированного кода, не в привычной всем реализации MVC и других штучек из книжек, а в гибкости модели данных и эта гибкость не достигается правильной объектностью программного кода. Незачем судить об использовании статических классов, когда вами не видна архитектура движка комплексно. Это не в обиду вам, но если увидите изюминку в архитектуре движка, а это в основном касается модели данных и её использования, то вопросы о статичности классов модулей уже не будут вас волновать.
:)
В том и дело что с модулями так и надо — напрямую обращаться к ним (либо через события), незачем модули представлять как объекты и передавать их куда-то в качестве аргументов, хранить ссылки на них и другое. Там где нужны объекты, используются объекты — всё в меру, всё для достижения гибкости и простоты. Сейчас на движке поднимается серьезный проект и поверьте, от того что модули являются статическими классами не возникло не малейшей мысли об ущербности. Возможно просто у вас свое представление, что должен делать модуль и почему он должен быть объектом. :)
Ну а что не так? Вам (да и мне) очень нравится как удобно в NS выборки делать и вы того же хотите добиться в управлении, так ведь? Вы скрыли логику в триггерах, но забыли главное — минимизировать нагрузку. Предложенный вами вариант не устраняет главного минуса NS.
> Я не предлагаю замены
А для чего статья? Кому она будет полезна, если этим не заменить другие алгоритмы? Не поленились бы хотябы написать, где это творение лучше всего использовать и привели бы сравнение с NS без триггеров.
Судя по всему вас в обще не интерисуют другие подходы. Как ещё объяснить резкую критику и сплошное минусование?
Понадобится — добавьте, для этого только ALTER сделать, а весь миллион записей не нужно инициализировать, установка значений только у добавляемых узлов будет происходить точно также, если бы добавление колонок не потребовалось.
Да и ещё раз говорю, для каждой задачи свой алгоритм и не надо делать из NS универсальное решение (судя по комментам) — он хорош только, когда требуется работать с очень глубокой иерархией и если её изменение — редкость. Но так получается, что веб движется в сторону абсолютной динамичности, данные постоянно обновляются, поэтому такое внимание к алгоритмам изменяющие данные. Как раз для этого и оказалось выгодней MP алгоритм реализовать с небольшой избыточностью, чтоб и изменение иерархии происходило быстро и поиск/чтение тоже.
Если не согласны, то уж постарайтесь аргументировать, а не только делать вид всезнающего.
Небольшая избыточность при распахивании пути по колонкам выдаёт большую скорость, так как поиск уже осуществляется по индексированным целочисленным полям, плюс ко всему появляются возможности работы с иерархией как в алгоритме NS. На практике глубина иерархии больше 10 редкость, вы либо создаёте 10 колонок, либо тратите процессорное время с вашим алгоритмом для NS. Всё же следует для каждой задачи применять соответствующее решение. За статью про NS спасибо, но его уже со всех сторон изжевали, хотелось бы увидеть что-то новое.
> Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
Поэтому я говорю о детализации. Шаблоны могут быть вплоть до минимальных единиц информации в системе, в моём случае – это сущности. В реальности может получиться, что не потребуется создавать шаблон для новости, так как новость соберется из шаблонов её заголовка и текста. Избавится от необходимости логики в шаблоне реально, и при этом иметь супер гибкость. Всё зависит от архитектуры системы и вопрос этот не прост для обсуждения здесь. Конечно, компонент представления получится не легким, но это как с детализацией трехмерной графики – отличная картинка за большее процессорное время. Во всяком случаи мы не анимацию делаем, и может использовать многоуровневое кэширование.
На сегодняшний день ещё нет идеально реализованного «вида», а ведь поверьте, через детализацию шаблонов в них даже циклы и условные операторы не нужны будут.
Спасибо за пожелания, приятно что спустя более полугода появляются новые комменты :)
Тут боятся незачем, я только рад что у меня оно особенное :)
Архитектура движка такая, что желание в будущем добавлять новую логику решается через обработку событий, незачем что-то переопределять, когда не нужное можно просто отключить. С умными книжками по ооп я очень даже знаком, даже более. Только вот идеология движка не в применении объектно-ориентированного кода, не в привычной всем реализации MVC и других штучек из книжек, а в гибкости модели данных и эта гибкость не достигается правильной объектностью программного кода. Незачем судить об использовании статических классов, когда вами не видна архитектура движка комплексно. Это не в обиду вам, но если увидите изюминку в архитектуре движка, а это в основном касается модели данных и её использования, то вопросы о статичности классов модулей уже не будут вас волновать.
:)
:)
> Я не предлагаю замены
А для чего статья? Кому она будет полезна, если этим не заменить другие алгоритмы? Не поленились бы хотябы написать, где это творение лучше всего использовать и привели бы сравнение с NS без триггеров.
Судя по всему вас в обще не интерисуют другие подходы. Как ещё объяснить резкую критику и сплошное минусование?
Да и ещё раз говорю, для каждой задачи свой алгоритм и не надо делать из NS универсальное решение (судя по комментам) — он хорош только, когда требуется работать с очень глубокой иерархией и если её изменение — редкость. Но так получается, что веб движется в сторону абсолютной динамичности, данные постоянно обновляются, поэтому такое внимание к алгоритмам изменяющие данные. Как раз для этого и оказалось выгодней MP алгоритм реализовать с небольшой избыточностью, чтоб и изменение иерархии происходило быстро и поиск/чтение тоже.
Небольшая избыточность при распахивании пути по колонкам выдаёт большую скорость, так как поиск уже осуществляется по индексированным целочисленным полям, плюс ко всему появляются возможности работы с иерархией как в алгоритме NS. На практике глубина иерархии больше 10 редкость, вы либо создаёте 10 колонок, либо тратите процессорное время с вашим алгоритмом для NS. Всё же следует для каждой задачи применять соответствующее решение. За статью про NS спасибо, но его уже со всех сторон изжевали, хотелось бы увидеть что-то новое.