Как я могу реализовать удобную логическую логику в GUI веб-формы?
В настоящее время у меня есть веб-приложение, где пользователь может использовать раскрывающиеся списки для создания SQL SELECT операторов, таких как:
Столбец Выберите Раскрывающийся Список / Оператор ( = != > = ) / Значение выберите раскрывающийся список
пользователь может сделать это несколько раз, и "фильтры" в настоящее время все Эд вместе.
Я хочу добавить возможность создания или утверждения. Я мог бы очень легко добавить ORs в случае, когда столбцы одинаковы, но как насчет сложные логические утверждения, такие как
((A ИЛИ B ИЛИ C) И (D ИЛИ E)) ИЛИ (F И G)?
Как я могу позволить пользователям создавать такие заявления удобным для пользователя способом?
EDIT: чтобы указать, удобный для широкой аудитории. В настоящее время я работаю с разработчиками, которые иногда вручную кодируют SQL-запросы для нетехнического клиента, которому нужна конкретная информация из нашей базы данных. Цель состоит в том, что это веб-приложение позволит устранить необходимость для нас силы-код клиента простой в использовании инструмент, чтобы сделать это сами.
EDIT2: в настоящее время приложение не используется конечными пользователями. Только данных у меня нет, а на их предыдущие запросы рукописный SQL и таким образом, система запрашивает клиент просит. Учитывая, что я мог бы упростить его (например, ограничить способность пользователей генерировать запросы к видам запросов, которые они, как правило, просят), но я хочу увидеть, есть ли у кого-нибудь опыт общения булевой логики просто и полностью в GUIs.
спасибо для вашего времени.
8 ответов
когда вам нужно работать ( (A or B) and C) or (D or E or F)
, вы работаете с древовидной структурой данных. По моему опыту, нет простого способа представить деревья решений пользователям "красивым" или "интуитивным" способом. Его вдвойне трудно в ASP.NET webforms.
однако, один испытанный и верный подход заключается в следующем: одно текстовое поле, принимающее предложение where. Поверьте мне, подход с одним входом действительно является самым простым и интуитивно понятным пользовательским интерфейсом, а также имеет преимущество* позволяет быстро вводить / изменять фильтры запросов.
* * еще одним преимуществом, с технической стороны, является возможность написать свой собственный лексер/парсер и AST. Как часто вы можете сделать это в базовом приложении crud:)*
вы уже собираетесь обучать своих пользователей, как использовать свой специальный механизм запросов, вы можете также обучить их, что набрав (account.Balance < -2000 and account.Type == 'Checking') OR (account.Number = 123456)
возвращает то, что возвращает.
Если вы идете с этим подходом, предоставьте пользователю раскрывающийся список из доступных столбцов, так что двойной щелчок по элементу вставляет элемент в текстовое поле в месте расположения курсора.
для этого есть плагин jquery, называемый QueryBuilder, который делает это интересным образом:http://mistic100.github.io/jQuery-QueryBuilder/
Apple, похоже, нашла способ разработать GUI для вложенных булевых выражений: см. принятый ответ на UX.клиент StackExchange.
Я честно не вижу бизнес-ценности в написании пользовательских" где"," выбрать"," от " или любых других прокси-серверов команд SQL. Особенно, в этом конкретном контексте (доступ к БД и пользовательский запрос на лету) клиент открывает ворота безопасности ада.
позволить " чайникам "(которые, как я предполагаю, не способны использовать обычные инструменты SQL) составить" интуитивный " запрос-это катастрофа. Я думаю, что bj's club credit card info бюст 2003 или 2004 был довольно близок к этому в дух. Я догадываюсь (и это только догадка!!!) какой-то большой босс маркетинга сказал: "Мы сохраним информацию о полосе кредитной карты, чтобы мы могли использовать эту информацию позже."Вы хотите, чтобы только общедоступная информация в одной таблице и PII статистически закреплена", - спросил разработчик..... "Нет, мы еще не знаем, как мы хотим использовать эту информацию, разработайте нам инструмент для запроса ее на заказ.....- это была первая ступенька на пути к катастрофе. :(
между тем, определенно есть места когда пользовательский интерфейс необходим для составления / анализа выражений (инструменты анализа политики безопасности, исследование булевой / переключающей алгебры и т. д.) Я считаю, что лучший пользовательский интерфейс еще не создан (всегда:)), но если бы он был создан, я бы предположил, что у него есть возможность:
- разбирать выражение (должно быть тривиальным, так как можно построить дерево разбора, когда пользователь добавляет куски выражения по частям)
- показать выражение в форме дерева синтаксического анализа (это должно быть забавным рисунком он.)
- показать таблицу true / false для BF, представленную выражением
- нарисуйте гиперкуб BF (особенно ценный для "монотонных" функций)
- создайте карту Карно с топологической связью (удачи с выражениями высокой размерности, хотя)
- динамически генерировать диаграмму Venn для выражения.
- выделите несущественные переменные или"блоки выражений".
- используйте метод Маккласки или Петрика boolean минимизация выражений.
Это трудно представить даже в приложении WinForms.
вам нужно реализовать концепцию группы условий, которая состоит из одного или нескольких операторов и условного оператора.
лучшая реализация этого, которую я видел, была от фильтрации сервера GameSpy - я просто пытался найти скриншот, но я пришел пустой (эта программа все еще существует?). Насколько я помню, они сделали что-то вроде этого:--2-->
( Condition 1 ) OPERATOR ( Condition 2 ) OPERATOR ( ( Condition 3 ) OPERATOR ( Condition 4 ) )
когда я вижу такую проблему, я не могу не думать о ее реализации в виде стека, аналогично тому, как RPN решит эту проблему.
проблема здесь в том, что это не кажется слишком интуитивным
пример пользовательского интерфейса: ([кнопка] {список}
значение : [Толчок] [И] [Или]
стек {
} (Калькуляторы 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)")
Если вы хотите добавить другие операторы, и их было не так много, вы можете просто добавить дополнительные кнопки, или сделать отдельное текстовое поле для оператора
значение: [Толкать] Оператор [Combine]
Если вы хотите поддерживать унарные операторы, вам нужно отслеживать, является ли это префиксом или постфиксным оператором, или просто предположить префикс (логический унарный оператор "не" обычно является префиксом). У троичных операторов обычно есть два указателя инфикса, поэтому их сложнее поддерживать. Некоторые двоичные (и n-ary)операторы имеют префикс, инфикс и компонент суффикса " CallMethod (A,B)", поэтому он действительно сводится к тому, насколько сложным вы хотите его сделать.
только одна идея.
Mac OS X предлагает очень хорошие виджеты GUI для выполнения именно этого типа вещей. Вы можете моделировать свой GUI после этого типа макета / взаимодействия.
другой вариант - что - то вроде SQL Server Management Studio query builder interface-несколько строк и столбцов, где строки представляют собой ANDs, а столбцы ORs (или наоборот, я не помню).
вы можете сделать обновление в реальном времени результирующего запроса, чтобы помочь пользователям (так же, как SQL Server обновляет результирующий SQL).