Кто знает, как мне с модели передать переменную о предупреждении например "Нет данной статьи"
Не нужно это передать из модели.
Нужно опираться на результат которую вернет модель.
К примеру если метод модели вернул false, значит записей нет и плясать дальше от этого.
juramaj пишет:
сё что возвращает метод модели в контроллере складывается в $data
Передайте эту $data во view. А при выводе можно уже сделать приблизительно такую весч:
Структуру читал, сделал как многие советуют. Но дальше не пойму что делать
Где читали? Я не знаю, как Вам советовали многие и не имею представления что у Вас есть а чего нет.
bekpasov пишет:
мне нужно, чтобы при нажатии чекбокса вылезло небольшое сообщение (к примеру, "Найдено 5 -> Выбрать")
Значит нужно сделать запрос на COUNT записей с учетом использованных фильтров и показать результат пользователю.
bekpasov пишет:
Потом, если пользователь выбрал еще чекбокс, то его прибавить в запрос.
Если опции лежат в разных таблицах, то можно джойнить соответствующие таблицы по условию + добавить условие фильтрации для набора выбранных чекбоксов. Что то типа
Вы бы эту самую структуру привели, что бы народ знал на что опираться когда будет помогать(возможно).
bekpasov пишет:
Осталось выполнить запрос
Какой запрос? В какие таблицы? Без структуры Вам вряд ли чем то помогут.
bekpasov пишет:
Насколько понимаю нужен ajax
Неверно понимаете. ajax не имеет никакого отношения к фильтру ИМ. Почитайте, что это такое.
Да и глупо было бы использовать ajax при фильтрации продуктов. В таком случае пользователь не сможет дать ссылку другу на заранее отфильтрованный набор товаров.
И вот ещё что замечу, задача сложная и не для новичка, особенно если фильтр должен быть достаточно умным.
Если практикуетесь - пока оставьте эу задачу и попробуйте что нибудь проще.
Без создания экземпляра не выделяется дополнительная память.
Хм тогда проще писать в процедурном стиле )) Как по мне - то лучше в целом пусть отожрется на 2 метра больше за то в угоду удобства и гибкости
DeepVarvar пишет:
Почему редиректить должен контроллер? По мне так он должен отработать свою логику, и если ему надо, позвать Request::redirect()
Так реквест же это не редиректор какой нить. Реквест, запрос. Завтра тебе понадобится сделать редирект по имени роута его тоже в реквест оформишь или пойдешь переписывать все двигло где ты вызывал Request::redirect() ? Или нет, дай угадаю, редирект оставишь в реквесте а для роут-редиректа придумаешь что то ещё))
DeepVarvar пишет:
Это должен решать роутер?
А у тебя есть такой роут? Думаю нет... там же пользователь и получит заветный Not found
А зачем столько статики? В чем ты видишь плюс такого подхода?
DeepVarvar пишет:
это конечный автомат устанавливающий некоторые внутренние состояния.
И это плохо. Есть куча зависимостей. Я не смогу скопировать к себе в проект этот класс не изменив его код. Связи должны быть как можно слабыми. В идеале должна быть возможность скопипастить твой реквест в другой проект и чтоб совсем без правок.
DeepVarvar пишет:
Ну, ради трехстрочного метода создавать еще один класс, как-то не то. Пусть в реквесте пока лежит.
А чего сразу класс если нужно по простому - опиши в базовом контроллере метод редирект и все дела
DeepVarvar пишет:
Проверь-ка это в CLI режиме ))
А можно подумать на форум через CLI будут ходить
DeepVarvar пишет:
Request это конечный автомат устанавливающий некоторые внутренние состояния.
Ключевое слово "внутренние". Опять же зависимости что не есть гуд.
DeepVarvar пишет:
Есть ли смысл работать дальше, если запрос клиента невалиден?
Пробежался по классу Request и вот что не понравилось
1. Экземпляр класса Request на мой взгляд должен предоставлять доступ к данным которые пришли с запросом пользователя/бота(пофиг).
2. public static function init() - Соответственно Request не должен ничего инициализировать. Если нужно что то проинициализировать - это надо описать вне этого класса + не понравился доступ к объекту через публичное свойство в методе init(лучше методом-геттером а свойство - приватным).
3. public static function redirect($destination) редиректить Реквест тоже никого не должен. Это скорее плагин контроллера чем часть реквеста
4. public static function isPost() тут у тебя есть такая штука isset($_POST) и зря. $_POST всегда isset, даже когда ты сделал запрос методом GET.
5. private static function _storeClientInfo() тоже фтопку. Реквест ничего сторить не должен
6. _preValidateRequest и валидировать тоже. Все таки это не валидатор а реквест(см пункт 1)
Остальное пока не смотрел. Времени совсем нету...
P.S: смотрел достаточно бегло, возможно упустил что то ещё.
просто надо не потерять события и данные для конкретного элемента.
Значит нужно иметь возможность идентифицировать элемент по уникальному признаку.
Если парсишь через xPath то например можешь ориентироваться по позициям если они не будут меняться
Можно по атрибутам(так помоему проще). Если штатные атрибуты могут меняться как ты говорил - тогда подойдут кастомные которые кроме как идентефикации элемента никакой смысловой нагрузки в себе нести не будут
DeepVarvar пишет:
я получу ссылку на тот элемент который был найден ранее и увижу там кастомное св-во
Какой элемент запросишь такой и получишь Т.е если блоку с id="vasya" присвоишь кастомный атрибут то при повторной выборке получишь ссылку на тот же узел но уже с кастомным атрибутом
Есть текст, в котором имеются идентичные вставки вида {1|2}.
Нужно первые две вставки заменить на левую часть этой вставки {1|2} (т.е на единицу в данном случае), а все остальные вставки заменить на правую часть (двойку), я правильно понимаю? Если да, то должно быть все нормально.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1465
