Как я могу реализовать удобную логическую логику в графическом интерфейсе веб-формы?

В настоящее время у меня есть веб-приложение, в котором пользователь может использовать выпадающие списки для генерации операторов SQL SELECT, например:

Выбор столбца Dropdown | Выпадающее окно оператора (=! = > <= lt; = > =) | Выделение выпадающего списка

Пользователь может делать это несколько раз, а в "фильтрах" в настоящее время все ANDed вместе.

Я хочу добавить возможность создания OR-операторов. Я мог бы легко добавить ORs в случае, когда столбцы одинаковы, но что же касается сложных логических операторов вроде

((A ИЛИ B ИЛИ C) И (D ИЛИ E)) ИЛИ (F И G)?

Как я могу позволить пользователям создавать такие заявления удобным для пользователя способом?

РЕДАКТИРОВАТЬ: указать, удобство для пользователя. В настоящее время я работаю с разработчиками, которые иногда обрабатывают SQL-запросы для нетехнического клиента, который нуждается в конкретной информации из нашей базы данных. Цель состоит в том, что это веб-приложение избавит нас от необходимости вручную их кодировать, предоставив клиенту простой в использовании инструмент, чтобы сделать это самостоятельно.

EDIT2: В настоящее время приложение не используется конечными пользователями. Единственными имеющимися у меня данными являются предыдущие рукописные SQL-запросы и, следовательно, такие запросы, которые запрашивает клиент. Учитывая, что я мог бы упростить его (например, ограничить способность пользователей генерировать запросы к типам запросов, которые они, как правило, запрашивают), но я хочу посмотреть, есть ли у кого-нибудь опыт простой и полной связи логической логики в графических интерфейсах.

Спасибо за ваше время.

Ответ 1

Когда вам нужно обрабатывать ( (A or B) and C) or (D or E or F), вы работаете с древовидной структурой данных. По моему опыту, нет простого способа представления деревьев решений для пользователей "красивым" или "интуитивным" способом. Это вдвойне сложно в веб-форматах ASP.NET.

Однако один проверенный и понятный подход заключен в следующем: одиночный текстовый ящик, принимающий предложение where. Поверьте мне, подход с одним входом действительно является самым простым и интуитивно понятным пользовательским интерфейсом, а также имеет преимущество * обеспечения быстрого ввода/модификации фильтров запросов.

** Еще одно преимущество - с технической стороны - писать собственный лексер/парсер и AST. Как часто вы это делаете в базовом приложении crud:) *

Вы уже собираетесь обучать своих пользователей использованию вашего механизма запросов ad hoc, вы можете также обучить их тому, что ввод (account.Balance < -2000 and account.Type == 'Checking') OR (account.Number = 123456) возвращает именно то, что, по его словам, возвращает.

Если вы перейдете к этому подходу, предоставите пользователю раскрывающийся список доступных столбцов, чтобы двойной щелчок по элементу вставлял элемент в текстовое поле в месте расположения курсора.

Ответ 2

Для этого есть плагин jquery, называемый QueryBuilder, который делает это интересным способом: http://mistic100.github.io/jQuery-QueryBuilder/

Ответ 3

Apple, похоже, нашла способ разработать GUI для вложенных булевых выражений: см. принятый ответ на UX.stackexchange.

Ответ 4

Я честно не вижу деловой ценности при написании пользовательских "where", "выбрать", "от" или любых других прокси-команд SQL-команд. В частности, в этом конкретном контексте (доступ к БД и пользовательский запрос "на лету" ) клиент открывает защитные ворота ада.

Предоставление "манекенов" (которые, как я полагаю, неспособны использовать обычные инструменты SQL), составят "интуитивный" запрос - это ожидание. Я предполагаю, что BJ-клуб с информацией о кредитных картах 2003 или 2004 года был довольно близок к этому по духу. Я предполагаю (и это всего лишь предположение!!!), какой-то крупный босс-маркетинг сказал: "Мы сохраним информацию о кредитной карте, чтобы мы могли использовать эту информацию позже". "Вы хотите, чтобы только общедоступная информация в одной таблице и PII статистически ведра", - спросил разработчик..... "Нет, мы еще не знаем, как мы хотим использовать эту информацию, разработать инструмент для запроса ПОСТОЯННЫЙ ПУТЬ....." был первым шагом на пути к катастрофе.: (

Между тем, определенно есть места, когда пользовательский интерфейс необходим для составления/разбора выражений (инструменты анализа политики безопасности, исследования логической/коммутационной алгебры и т.д.) Я считаю, что лучший пользовательский интерфейс еще не создан (всегда:)), но если бы он был создан, я бы предположил, что он имеет возможность:

Проанализируйте выражение (должно быть тривиально, поскольку можно построить дерево синтаксического анализа, поскольку пользователь добавляет фрагменты выражения по частям)
Показать выражение в форме дерева синтаксического анализа (это должно быть забавно рисовать его).
Показать таблицу true/false для BF, представленную выражением
Нарисуйте гиперкуб BF (особенно ценный для "монотонных" функций)
Создайте карту Карно с топологическим связыванием (удачи с высоким размерным выражением)
Динамически генерировать диаграмму Венна для выражения.
Выделите несущественные переменные или "куски выражения".
Используйте метод McCluskey или Petrick для минимизации булевых выражений.

Ответ 5

Mac OS X предлагает очень приятные виджеты GUI для выполнения такого рода вещей. Вы можете смоделировать свой графический интерфейс после этого типа макета/взаимодействия.

Ответ 6

Это трудно представить даже в приложении WinForms.

Что вам нужно сделать, так это реализовать концепцию группы условий, которая состоит из одного или нескольких операторов и условного оператора.

Лучшая реализация этого я видел от фильтрации сервера GameSpy - я просто попытался найти скриншот, но я пришел пустым (эта программа все еще существует?). Из того, что я помню, они сделали что-то вроде этого:

(
    Condition 1
) OPERATOR
(
    Condition 2
) OPERATOR
(
    (
        Condition 3
    ) OPERATOR
    (
        Condition 4
    )
)

Ответ 7

Когда я вижу такую проблему, я не могу не думать о ее реализации как стек, подобно тому, как RPN решит эту проблему.

Проблема здесь в том, что она не кажется слишком интуитивной

Пример UI: ([Кнопка] < текстовое поле для ввода пользователя > {list}

Значение: < > [Push] [И] [Или]

Stack {

} (Калькуляторы HP RPN кладут стек выше области редактирования)

Итак, если бы я хотел написать выражение ((A и B) или (C и D)), я бы сделал следующее: A [push] (стек будет содержать "A" ) B [push] (стек будет содержать "B", "A" ) [и] (стек будет содержать "(A и B)" ) C [push] (стек будет содержать "C", "(A и B)" ) D [push] (стек будет содержать "D", "C", "(A и B)" ) [и] (стек будет содержать "(C и D)", "(A и B)" ) [или] (стек будет содержать "((A и B) или (C и D)" )

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

Значение: < > [От себя] Оператор < > [Комбинирование]

Если вы хотите поддерживать унарные операторы, вам нужно будет отслеживать, является ли он префиксным или постфиксным оператором, или просто принять префикс (булевский унарный оператор "не" обычно является префиксом). Тернарные операторы обычно имеют два указателя infix, поэтому есть большая сложность, если вы хотите их поддерживать. Некоторые бинарные (и n-арные) операторы имеют префикс, инфикс и суффикс-компонент "CallMethod (A, B)". Так что все зависит от того, насколько сложным вы его хотите.

Только одна идея.

Ответ 8

Другой вариант - это что-то вроде интерфейса построителя запросов SQL Server Management Studio - несколько строк и столбцов, где строки представляют ANDs и столбцы ORs (или наоборот, я не помню).

Вы можете в реальном времени обновить полученный запрос, чтобы помочь пользователям (так же, как SQL Server обновляет полученный SQL).