нет блин, серьезный вопрос

чем больше таких как ты, тем дороже стоят знания почему так не надо делать

а как надо делать? Я бы вообще забил на тупй баг: повторяющиеся изображения в слайдере

т.к. решение проблемы уже занимает кучу времени. Ну повторяется, ну и что? Ой у юзера дежа вю случится

сразу забирай из бд свой список ссылок без дубликатов

Так этот список ссылок формируется в Smarty шаблоне из различных источников (таблиц БД)

Проблема не в смарти а в кривой архитектуре в целом

Какого хера смарти (фронт) лезет в бд?

Архитектуру не выбирают. Она навязана сверху.

Спросите разработчиков Oxid

Из Совершенного кода

Там сейчас так и просится (в коде шаблона) микро разделение на View и Controller.

На чем пейсать этот ваш микро контроллер в смарти шаблоне?

Смарти == view из MVC, view != controller

Зачем его туда пихать?

Но у меня нет контоллера!

touch path/to/your/Controller.php

не благодари

я должен минимизировать кол-во этих.. как иво.. deployment items

tar -c потом

Смарти == view из MVC, view != controller

Смарти = тулза для генерации view, а не само view. На бэкэнде View пассивно и оно есть HTTP запрос или ответ

а задача "конвертации" представления данных (из формата приложения в формат UI) ложится на контроллер

смарти в этом плане - тулза которую юзает контроллер для формирования представления данных

"презентационная логика" в контроллерах короч

Ок, перефразирую, шаблон смарти это часть view. Так лучше?

нет)

шаблон смарти это шаблон смарти

который контроллер юзает для формирования html, который уже будет частью респонса тоесть view в контексте MVC (или MVA)

Лучше бы смарти не создавали, да

Т. е. смарти не попадает в парадигму MVC?

сервер не попадает в нее

нет, не попадает.

а смарти, ну чисто в теории, можно

Т. е. смарти не попадает в парадигму MVC?

парадигма MVC (а точнее схема просто) это просто способ убрать связанность между бизнес логикой и презентационной логикой. Причем только в одном направлении (бизнес логика не должна зависеть от презентационной, но презентационная вполне себе зависит от бизнес логики)

в MVC не попадает ни роутеры, ни шаблонизаторы

это лишь средства достижения целей

у MVC намного более простая идея а уж реализация - дело другое

ну и еще были такие ребята которые MVC Model2 придумали для JSX, вот там были роутеры и прочяя шляпа

http://stackoverflow.com/a/8710953/444079

лучше забудь вообще эти три буквы и почитай про Model-View-Adapter

а лучше про separation on concerns

MVC это способ решить конкретную проблему, а не зная зачем решать проблему ты не поймешь способ

Smarty can be used as a part of View implementation of some MVC framework.

http://www.smarty.net/docsv2/de/language.function.php.tpl

концептуально я должен лучше использовать это

Одно из предназначений Smarty - это отделение логики приложения от представления. Конечно же, шаблоны могут содержать в себе логику, но лишь при условии, что эта логика необходима для правильного представления данных. Такие задачи, как подключение других шаблонов, чередующаяся окраска строчек в таблице, приведение букв к верхнему регистру, циклический проход по массиву для его отображения и т.д. - всё это примеры логики представления. Тем не менее, не следует полагать, что Smarty заставляет вас разделять прикладную логику и логику представления. Smarty не видит разницы между этими вещами, так что переносить прикладную логику в шаблоны вы можете на свой страх и риск.

из доки

Smarty can be used as a part of View implementation of some MVC framework.

на заборе тоже писано)

> Конечно же, шаблоны могут содержать в себе логику ПРЕЗЕНТАЦИОННУЮ ЛОГИКУ

я о том же

сори за капс)

тут соль в separation of concerns

грубо говоря... причина по которой ты хочешь что-то поменять

ты хочешь поменять текст лэйблы - это одна причина

ты хочешь добавить функционал - другая

ты хочешь добавить функционал который относится только к UI - третья

у тебя не должно быть такой ситуации, что ты редактируешь одну и ту же шляпу по нескольким причинам

потому и нужно разделять

ОК, а формирование списка ссылок - это какая логика- представления или чего то еще?

я это понимаю и принимаю, но вот в чем вопрос, если у человека, как он говорит, нет контроллеров, может ли он их делать в смарти и сказать что это разделение? ?

ОК, а формирование списка ссылок - это какая логика- представления или чего то еще?

презентационная

ты формируешь представление списка ссылок для пользователя

я это понимаю и принимаю, но вот в чем вопрос, если у человека, как он говорит, нет контроллеров, может ли он их делать в смарти и сказать что это разделение? ?

тогда возникает вопрос, откуда данные появляются в смарти?

Так этот список ссылок формируется в Smarty шаблоне из различных источников (таблиц БД)

если шаблон "сам" ходит в базу и забирает инфу - это не ок, потому как ты можешь захотеть поменять структуру базы по причине не относящейся к UI

а если ты даешь шаблону смарти какую-то штуку, которая инкапсулирует в себе знания куда ходить, то с определенными оговорками разделение есть

ну мол если у тебя в смарти есть метод userLinkList()

ERROR: S client not available

или функция

или хз чего, которая полностью прячет откуда данные

то это ничем не отличается от того, что бы в контроллере просто эти данные передать

а вот когда в шаблоне находится что-то вроде

ну короч какая-то логика

)

тип "слазай забери список линок, отфильтруй, отсортируй

и все это в шаблоне - это уже нарушение

ты таким образом "связал" логику работы с данными и презентационную логику

и теперь когда у тебя логика работы с данными "захочет" поменяться, у тебя будут проблемы

короч смарти - это шаблонизатор. Не надо пытаться "притянуть" сюда MVC

у шаблонизатора простая задача - дать возможность разделить "шаблоны" и "данные"

у MVC задача тоже простая - отделить UI от бизнес логики

что бы бизнес логика не зависела от UI

(но не наоборот, мол если меняется UI но не функционал, это не аффектит функционал. А если меняется функционал, это скорее всего затронет UI)

а ладно всем пофиг

)

если шаблон "сам" ходит в базу и забирает инфу - это не ок, ну скажем так, он не обращается к базе напрямую, он обращается к ней через ORM

И к другим обьектам Oxid

если шаблон "сам" ходит в базу и забирает инфу - это не ок, ну скажем так, он не обращается к базе напрямую, он обращается к ней через ORM

да, если не сам, и в шаблонах нет логики какой аля фильтрации например или проверки прав

тогда это чисто презентационная логика

"обойти массив юзеров" например

что бы сформировать список

но опять же... если говорить о "убрать контроллер"

откуда "шаблон" будет получать "модельки" изначально?

кто ему его даст?

Ух @fes0r разошелся :D

ну и потом, в классическом MVC 79-ого года задача контроллера заключалась исключительно в том, что бы обработать действия пользователей (клики, ввод с клавиатуры), и ничего о view оно не знало. Вьюшка сама себя рисовала и была активной. Сегодня почти все подходы используют пассивное view, что значит что кто-то должен быть между моделью и пассивной вьюшкой, кто-то должен "управлять" вьюшками.

MVP, MVA, MVVM - это вот туда

ого

кажется кого-то покусал Роберт Мартин

XSS в Web telegram )