Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
В свое время думал над DSL для подобной задачи на PHP (составление запросов на выборку) и уже даже сел реализовывать — остановился, когда понял, что еще чуть-чуть, и я начну писать первую версию SQL (^_^)
А вы видели, как добавляются логические условия в google analytics? Возможно, вам не подойдет, но вдруг. Вполне по-человечески выглядит: скриншот из гугла.
>Решение оказалось довольно простым: отображать условие в виде дерева, ветви которого обозначают логическое «и» или «или», а листья – операции сравнения.
Тоже мне открытие :)
Тоже мне открытие :)
Никто не претендует на звание первооткрывателя дерева условий :). 90% юзеров, которые будут пользоваться этим «деревянным» интерфейсом далеки от информационных технологий. Такова специфика рынка сбыта. Вводить дерево для непрограммистов и нетехнарей — изрядно стремно. Основная задачка, которую надо было решить и которая еще будет долго дорабатываться — сделать понятное и доступное дерево для продавца. Продавца офлайн-фронта в первую очередь.
Да уж, немного напомнило SQL ;)
P.S. карма < 0
P.S. карма < 0
Предлагаю не придумывать новый язык, а сделать такой вариант: habrastorage.org/storage1/0f567aea/38b16281/e4ab0c77/8b44508c.png
Вот еще редактирование/добавление условия: habrastorage.org/storage1/d0cc9e3e/a004c04f/d6a35773/bee4f204.png
Уверен, что модель И + вложенные ИЛИ удовлетворяет 99.99% всех потребностей юзера.
Горизонтально расположены «или» условия, вертикально «и». Щелчок по кнопке редактирует ее параметры, а остальное, думаю, понятно.
И да, если использовать язык программирвания, почему не использовать удобочитаемый SQL: domain IN («mydomain.ru», «www.mydomain.ru') AND view_count > 100? Честно говоря, ваша хрень с запятыми малочитаема и малопонятна.
Вот еще редактирование/добавление условия: habrastorage.org/storage1/d0cc9e3e/a004c04f/d6a35773/bee4f204.png
Уверен, что модель И + вложенные ИЛИ удовлетворяет 99.99% всех потребностей юзера.
Горизонтально расположены «или» условия, вертикально «и». Щелчок по кнопке редактирует ее параметры, а остальное, думаю, понятно.
И да, если использовать язык программирвания, почему не использовать удобочитаемый SQL: domain IN («mydomain.ru», «www.mydomain.ru') AND view_count > 100? Честно говоря, ваша хрень с запятыми малочитаема и малопонятна.
Ух, а что это? Где можно посмотреть вживую?
модель И + вложенные ИЛИ удовлетворяет 99.99% всех потребностей юзера — не удовлетворяет
sql для описания деревьев подходит гораздо хуже
ну а читаемость — совсем неважна для роботов. только не говорите мне, что XML в чистом виде вы воспринимаете легко и непринужденно :)
sql для описания деревьев подходит гораздо хуже
ну а читаемость — совсем неважна для роботов. только не говорите мне, что XML в чистом виде вы воспринимаете легко и непринужденно :)
Это называется ДНФ. Позволяет описать любое логическое условие (или же любое логическое условие можно привести к ДНФ).
Вот только в виде ДНФ оно не всегда компактно выглядит, одно и то же условие приходится дублировать в нескольких ветках…
Например, A & (B | (C & D)) = A & (B | C) & (B | D) — условие B дублируется.
Например, A & (B | (C & D)) = A & (B | C) & (B | D) — условие B дублируется.
Ну там же написано:
Горизонтально расположены «или» условия, вертикально «и». Щелчок по кнопке редактирует ее параметры, а остальное, думаю, понятно.
Т.е. как раз выходит, что в строки — это дизъюнкты, а столбцы в строках — конъюнкты. Как раз ДНФ и получается :)
Мы говорим о разном.
Я согласен, что это ДНФ, в этом меня убеждать не нужно.
При этом в комментарии фокус на минусах такого представления, а не на соответствии терминологии.
Я согласен, что это ДНФ, в этом меня убеждать не нужно.
При этом в комментарии фокус на минусах такого представления, а не на соответствии терминологии.
А. С этим я согласен.
Нормальные формы редко когда бывают удобными. Хотя те же acl-ы в squid выглядят довольно таки удобочитаемыми.
Авторский вариант с деревом дизъюнктов/конъюнктов выглядит более удобным. Хотя там было бы к месту группировка или биндинг новых переменных. Что бы вместо A & (B | (C & D)) можно было написать
X = C & D,
Y = B | X,
A & Y
Нормальные формы редко когда бывают удобными. Хотя те же acl-ы в squid выглядят довольно таки удобочитаемыми.
Авторский вариант с деревом дизъюнктов/конъюнктов выглядит более удобным. Хотя там было бы к месту группировка или биндинг новых переменных. Что бы вместо A & (B | (C & D)) можно было написать
X = C & D,
Y = B | X,
A & Y
Вместо груши должен был находиться тот, кто принял такое «гуманное» «интуитивное» решение отказаться от фильтров в текстовом формате. А Миша у вас молодец.
Да, дерево здесь само напрашивается. Я, например, сделал так:
Хороший вариант
Я бы не сказал — очень уж много места отъедает.
Не говоря уже о том, что операция находится в отдельном блоке относительно аргументов, что очень сбивает с толку.
И — самое главное — семантика элементов управления не соответствует семантике условия, приходится переходить на другой уровень мышления.
Как пользователь я интуитивно формулирую выражение следующим образом:
«Хочу выбрать модели DIR-300 или DIR-320, полученные после 1.01.2011».
Соответственно, удобнее было бы формировать условие таким образом:
Следовательно:
Не говоря уже о том, что операция находится в отдельном блоке относительно аргументов, что очень сбивает с толку.
И — самое главное — семантика элементов управления не соответствует семантике условия, приходится переходить на другой уровень мышления.
Как пользователь я интуитивно формулирую выражение следующим образом:
«Хочу выбрать модели DIR-300 или DIR-320, полученные после 1.01.2011».
Соответственно, удобнее было бы формировать условие таким образом:
Дата получения | позже (не включительно) | 1.01.2011
И [
Модель | содержит | [
DIR-300
ИЛИ DIR-320
]
]
Следовательно:
- Блоки И и ИЛИ разрешены не только для всей тройки целиком, но и для частей
- И и ИЛИ используются в инфиксной форме (как в речи), а не в префиксной (функциональный стиль).
Кстати, поискал подобный подход.
В частности, подобным образом задаются условия для сортировки писем в небезызвестном почтовике The BAT!
В частности, подобным образом задаются условия для сортировки писем в небезызвестном почтовике The BAT!
а если у вас не «DIR-300» или DIR-320
а например такое: модель содержит DIR-300 или модель содержит DIR-320 или (модель содержит DIR-1642 и Имя содержит Вася) или модель содержит DIR-1654876
Конечно удобнее, когда слово ИЛИ находится между, а если операндов не 2, а больше? где его вставить?
а например такое: модель содержит DIR-300 или модель содержит DIR-320 или (модель содержит DIR-1642 и Имя содержит Вася) или модель содержит DIR-1654876
Конечно удобнее, когда слово ИЛИ находится между, а если операндов не 2, а больше? где его вставить?
Между каждыми. Пример: A или B или С
Можно и так. Т.е. при смене «или» на «и» в любом из десятка мест, менять автоматом и все остальные. Но не создаст ли это иного нагромождения? Мне кажется изрядно равнозначные варианты получаются.
И ведь вариант
Модель | содержит | [
DIR-300
ИЛИ DIR-320
]
хорошо выполняет группировку значений по одному критерию. Это частный случай. В большинстве случаев там не группа моделей, а группа разных переменных с проверкой на разные значения.
Модель | содержит | [
DIR-300
ИЛИ DIR-320
]
хорошо выполняет группировку значений по одному критерию. Это частный случай. В большинстве случаев там не группа моделей, а группа разных переменных с проверкой на разные значения.
Изивините, но это не язык программирования (во всяком случае, не Тьюринг-полный). Если не согласны — требую реализации «99 бутылок пива» :)
Это язык описания булевых формул в логике высказываний.
Это язык описания булевых формул в логике высказываний.
И чем это лучше того же выражения на SQL?
тем, что SQL — язык запросов, а не хранения деревьев
Это не лучше, это — хуже.
Ибо выражение SQL проще, понятнее и однозначно соответствует дереву.
Ибо выражение SQL проще, понятнее и однозначно соответствует дереву.
очень спорное утверждение:
SQL — привычнее, да и только
на счет однозначного соответствия дереву, появляется приоритет операций
«A AND B OR C » какому дерево соответствует? -трудозатрат больше на реализацию
интерпретация:
в SQL придется обработать все выражение (в большинстве случаев), в SCLOG можно прекратить возню сразу как только получили ложь в «И» или, соответственно, истину в «ИЛИ»
в общем спор ни о чём, можно реализовать поддержку SQL, но это не даст никаких чувствительных плюсов для нашей задачи (я же свою конкретную задачу решаю, а не абстрактную в вакууме)
SQL — привычнее, да и только
на счет однозначного соответствия дереву, появляется приоритет операций
«A AND B OR C » какому дерево соответствует? -трудозатрат больше на реализацию
интерпретация:
в SQL придется обработать все выражение (в большинстве случаев), в SCLOG можно прекратить возню сразу как только получили ложь в «И» или, соответственно, истину в «ИЛИ»
в общем спор ни о чём, можно реализовать поддержку SQL, но это не даст никаких чувствительных плюсов для нашей задачи (я же свою конкретную задачу решаю, а не абстрактную в вакууме)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SCLOG: велосипед со всеми признаками языка программирования