Pull to refresh

Comments 39

В свое время думал над DSL для подобной задачи на PHP (составление запросов на выборку) и уже даже сел реализовывать — остановился, когда понял, что еще чуть-чуть, и я начну писать первую версию SQL (^_^)
у нас тоже чуть и не получилось — вовремя остановились :)
А вы видели, как добавляются логические условия в google analytics? Возможно, вам не подойдет, но вдруг. Вполне по-человечески выглядит: скриншот из гугла.
само собой видели, гугл-аналитикс один из самых главных инструментов :)
исключительно имхо, но у Гугла интерфейсы все очень тяжелые — слишком много всего
к тому же при такой организации: оно не сильно отличается от просто записанных в строках условий :-/
>Решение оказалось довольно простым: отображать условие в виде дерева, ветви которого обозначают логическое «и» или «или», а листья – операции сравнения.

Тоже мне открытие :)
Никто не претендует на звание первооткрывателя дерева условий :). 90% юзеров, которые будут пользоваться этим «деревянным» интерфейсом далеки от информационных технологий. Такова специфика рынка сбыта. Вводить дерево для непрограммистов и нетехнарей — изрядно стремно. Основная задачка, которую надо было решить и которая еще будет долго дорабатываться — сделать понятное и доступное дерево для продавца. Продавца офлайн-фронта в первую очередь.
Просто представление выражения в виде дерева — общеизвестная вещь. Но графическое представление мне понравилось. Здорово.
Предлагаю не придумывать новый язык, а сделать такой вариант: 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? Честно говоря, ваша хрень с запятыми малочитаема и малопонятна.
Ух, а что это? Где можно посмотреть вживую?
Это картинка, которую я нарисовал в фотошопе, так что желающим посмотреть вживую предлагается открыть их любимый редактор кода и реализовать в яваскрипте :) И, возможно, потом поделиться с другими желающими.
модель И + вложенные ИЛИ удовлетворяет 99.99% всех потребностей юзера — не удовлетворяет
sql для описания деревьев подходит гораздо хуже
ну а читаемость — совсем неважна для роботов. только не говорите мне, что XML в чистом виде вы воспринимаете легко и непринужденно :)
Читаемость важна для человека. Еле прочел ваш комментарий. )
трудно вам живется :)
видимо вам никто докладные от руки написанные не приносил ;)
показалось мне так
перекрещусь :-D
Это называется ДНФ. Позволяет описать любое логическое условие (или же любое логическое условие можно привести к ДНФ).
Вот только в виде ДНФ оно не всегда компактно выглядит, одно и то же условие приходится дублировать в нескольких ветках…

Например, A & (B | (C & D)) = A & (B | C) & (B | D) — условие B дублируется.
Горизонтально расположены «или» условия, вертикально «и». Щелчок по кнопке редактирует ее параметры, а остальное, думаю, понятно.

Т.е. как раз выходит, что в строки — это дизъюнкты, а столбцы в строках — конъюнкты. Как раз ДНФ и получается :)
Мы говорим о разном.
Я согласен, что это ДНФ, в этом меня убеждать не нужно.

При этом в комментарии фокус на минусах такого представления, а не на соответствии терминологии.
А. С этим я согласен.
Нормальные формы редко когда бывают удобными. Хотя те же acl-ы в squid выглядят довольно таки удобочитаемыми.

Авторский вариант с деревом дизъюнктов/конъюнктов выглядит более удобным. Хотя там было бы к месту группировка или биндинг новых переменных. Что бы вместо A & (B | (C & D)) можно было написать
X = C & D,
Y = B | X,
A & Y
Вместо груши должен был находиться тот, кто принял такое «гуманное» «интуитивное» решение отказаться от фильтров в текстовом формате. А Миша у вас молодец.
В текстовом формате (а ля аутлук) хорошо, когда условия не сильно ветвятся. В нашем же случае могут вырасти нереальные монстры в рамках одного фильтра.
Да, дерево здесь само напрашивается. Я, например, сделал так:


Я бы не сказал — очень уж много места отъедает.
Не говоря уже о том, что операция находится в отдельном блоке относительно аргументов, что очень сбивает с толку.
И — самое главное — семантика элементов управления не соответствует семантике условия, приходится переходить на другой уровень мышления.

Как пользователь я интуитивно формулирую выражение следующим образом:
«Хочу выбрать модели DIR-300 или DIR-320, полученные после 1.01.2011».
Соответственно, удобнее было бы формировать условие таким образом:

Дата получения | позже (не включительно) | 1.01.2011
И [
        Модель | содержит | [
                        DIR-300
                        ИЛИ DIR-320
                        ]
]


Следовательно:
  • Блоки И и ИЛИ разрешены не только для всей тройки целиком, но и для частей
  • И и ИЛИ используются в инфиксной форме (как в речи), а не в префиксной (функциональный стиль).
Кстати, поискал подобный подход.
В частности, подобным образом задаются условия для сортировки писем в небезызвестном почтовике The BAT!
а если у вас не «DIR-300» или DIR-320
а например такое: модель содержит DIR-300 или модель содержит DIR-320 или (модель содержит DIR-1642 и Имя содержит Вася) или модель содержит DIR-1654876

Конечно удобнее, когда слово ИЛИ находится между, а если операндов не 2, а больше? где его вставить?
Между каждыми. Пример: A или B или С
Можно и так. Т.е. при смене «или» на «и» в любом из десятка мест, менять автоматом и все остальные. Но не создаст ли это иного нагромождения? Мне кажется изрядно равнозначные варианты получаются.
И ведь вариант

Модель | содержит | [
DIR-300
ИЛИ DIR-320
]

хорошо выполняет группировку значений по одному критерию. Это частный случай. В большинстве случаев там не группа моделей, а группа разных переменных с проверкой на разные значения.
ну не все сразу :)
будет
может быть…
наверно :)
тем, что SQL — язык запросов, а не хранения деревьев
Это не лучше, это — хуже.
Ибо выражение SQL проще, понятнее и однозначно соответствует дереву.
очень спорное утверждение:
SQL — привычнее, да и только

на счет однозначного соответствия дереву, появляется приоритет операций
«A AND B OR C » какому дерево соответствует? -трудозатрат больше на реализацию

интерпретация:
в SQL придется обработать все выражение (в большинстве случаев), в SCLOG можно прекратить возню сразу как только получили ложь в «И» или, соответственно, истину в «ИЛИ»

в общем спор ни о чём, можно реализовать поддержку SQL, но это не даст никаких чувствительных плюсов для нашей задачи (я же свою конкретную задачу решаю, а не абстрактную в вакууме)
Only those users with full accounts are able to leave comments. Log in, please.