- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Мало что понял, но наверное нужен "конечный автомат", т.е. примерно то, чем занимается консольная программа, когда читает свои параметры запуска.
Эммм, ну не настолько круто, конечно :)
Ох уж эта опасная и сладостная магия eval() :D
Коллеги, а как на счёт if (assert($x)) ?
Чем не вариант?
Условий каждый контент-менеджер может нагенерировать сколько ему позволит фантазия, переменных в каждом условии от 1, до N, проще всего их сразу хранить именно в виде строки "$var > 1 && $var = 2 && $var = \'string\'"
ну во-первых условий не не ограничено в принципе
<
>
=
<=
<>
>=
ну и еще немного..
И следуя парадигме - "Самое узкое место в автоматизации - человек", нужно все-таки проверять чтобы условия не противоречили друг другу, иначе получите 0
Напишите более жизненный пример и попробуем придумать более элегантное решение, а то каша из знаков совсем не информативна.
насколько я понял у каждого условия фильтра(если я правильно понял что пишете фильтр) у вас есть 3 сущности
1 переменная - давайте ее назовем "признак данных"
2 параметр сравнения
3 значение признака
вот с этим и работайте
у вас есть набор признаков (группируем по ним наши условия)
потом обрабатываем параметры сравнения и значения, исключаем излишние пересечения и оставляем только те значения которые нам дадут стройный набор признаков
В таком случае пошагового разбора набора нам даст более пластный код, пригодный для дальнейшего наращивания функционала
ну во-первых условий не не ограничено в принципе
<
>
=
<=
<>
>=
В моём случае - ограничено всего тремя состояниями - больше, меньше и равно. Для потребностей, под которые пишется скриптик - этого полностью достаточно. В форме пользователь не вводит, а выбирает выпадашкой, ну и плюс проверка на всякий случай.
Откровенно невозможные взаимоисключающие условия, конечно же, будут проверяться и фильтроваться, например "$price > 10 && $price < 5" - не пройдёт валидацию и не попадёт в набор условий ещё на стадии создания.
Пустой результат не критичен, мало того - это один из нормальных результатов проверки, мне как раз и надо проверить на 0 или не 0.
Реальный пример:
В базе есть некий объект, условно - карточка товара. По смыслу ОЧЕНЬ похоже. С кучей характеристик, которые хранятся в своих ячейках таблицы.
У контентщика есть возможность заранее определить шаблонные языковые переменные, заполнив формочку с кучей полей.
Форма достаточно гибкая, поля в ней натыкиваются аджакасом как угодно, но на выходе получаем вот такое условие
$цвет = красный, $цена > 10, $страна производства = 'Турция', то %наша_переменная% имеет "вот такое значение".
После чего в описании товарной карточки все красные турецкие труселя дороже 10 рублей добавляется заранее предустановленная фраза. Ура, имеем генератор описаний товарных карточек по шаблону.
Шаблонных переменных можно нагенерировать сколько угодно, условий в них - тоже, проще всего хранить именно в таком виде "$var > 1 && $var = 2 && $var = \'string\'"
Соответственно в базе имеем таблицу:
ID
Юзер_ID
%Шаблон%
Условие
Замена
На пальцах:
%lowprice% = ($price < 10) ? 'недорогие'
%hiprice% = ($price > 10) ? 'премиальные'
Строим одну единственную конструкцию "Это отличные %lowprice%%hiprice% труселя!
Если новые труселя в нашем магазине дороже 10 рублей, мы автоматом получаем в описании строку "Это отличные премиальные труселя!", если дешевле - "Это отличные недорогие труселя!"
А если вдруг $price == 10, то тогда просто "Это отличные труселя!
Ну это прям мегаупрощённый пример, естественно.
Значит любая переменная может в момент генерации описания может иметь 2 состояния - 'пусто' и 'замена согласно условию', чтобы определить это состояние, мне нужно проверить набор характеристик конкретно взятого товара на условие
цвет = красный, $цена > 10, $страна производства = 'Турция'
Соответственно в базе имеем таблицу:
возвращаясь к стартпосту уже забыл зачем условие подставлять в IF? условие для фильтрации обычно вставляется в запрос к БД, а это обычный текст по сути)
Вы про какую фильтрацию? Где и что фильтруется?
Долго пытался понять чего вы хотите, возможно так и не понял, но если понял то я бы сделал так:
if($price<10) $titleprice="недорогие";
elseif($price>10) $titleprice="премиальные";
else $titleprice="";
С кучей характеристик, которые хранятся в своих ячейках таблицы.
т.е. каждая в своей ячейке?
тогда я вообще не понимаю проблемы...(((
Долго пытался понять чего вы хотите, возможно так и не понял, но если понял то я бы сделал так:
if($price<10) $titleprice="недорогие";
elseif($price>10) $titleprice="премиальные";
else $titleprice="";
Вы подстроились под буквальное, упрощённое условие из примера. Конечно, если просто взять условие с $price из примера, то предложенный вами способ - прост и очевиден.
тогда я вообще не понимаю проблемы...(((
Окей, давайте я попробую переформулировать ещё раз...
Есть товар - "Труселя, артикул 123456", его набор характеристик:
$price =12;
$coutry = 'Китай';
$size = '7xl';
$color = 'красный';
$material = 'шёлк';
$quantity = 12;
Переменная, которую определил контентщик:
%premium% = "Шикарные труселя из нежнейшего шёлка, сотканного лучшими восточными мастерами, тысячелетиями хранящими и передающими свои секреты.".
%limited% = "Премиальная коллекция, лимитированная серия."
Условия переменной:
%premium% - ($coutry == 'Китай' && $price > 10 && $material == 'шёлк')
%limited% - ($price > 10 && $quantity < 10)
-------------------------------
Формула:
Рады представить вам новую коллецию! %premium% Трусы разработаны лучшими немецкими инженерами, обладают эффектом памяти и учитывают индивидуальные особенности владельца. %limited% Страна производства - <?=$country?>
-------------------------------
Если условие для %premium% = true, в описании трусов появляется заданная строка.
%limited% с имеющимся набором характеристик - false, поэтому в примере не подставляется.
-------------------------------
Получаем на выходе:
Рады представить вам новую коллецию! Шикарные труселя из нежнейшего шёлка, сотканного лучшими восточными мастерами, тысячелетиями хранящими и передающими свои секреты. Трусы разработаны лучшими немецкими инженерами, обладают эффектом памяти и учитывают индивидуальные особенности владельца. Страна производства - Китай.
-------------------------------
проблема не в характеристиках, а в том, как хранить условия для подстановок. В примере это:
А если в условии переменных не 2-3, а десяток? Это офигенно громоздкий цикл с if-else получается.
Выше предложили рабочее решение с eval, но eval тут реально не оправданно избыточен.
Но ведь можно же использовать assert($x), где $x - это прям строка условия?