I’ve been working on a UI pattern that shows up a lot in business applications: filtering structured data.

Most systems solve this with visual filter builders—rows of conditions, dropdowns, nested logic, etc.

They’re flexible, but once queries get complex, they tend to become:

• slow to construct
• hard to read at a glance
• annoying to reuse or modify

So I experimented with a different approach: a lightweight query language embedded directly into the search bar.

Example:

name = 'Azure Interior' and price > 1000

Under the hood, this is parsed into a simple AST and translated into the existing backend filtering system.

Design goals

• Keep the existing UI (no replacement of filter builder)
• Add a textual DSL layer on top of structured data
• Make queries reusable and easy to share

Why not just use SQL?

Because this runs inside a constrained UI environment where end users are not expected to write full queries. It’s closer to a domain-specific mini-language than general-purpose querying.

Tradeoffs I ran into

• Text-based queries are faster and more composable
• But GUI builders are more discoverable for non-technical users

This was originally implemented inside an Odoo-based system, but the pattern itself is framework-agnostic.

Curious what others think:

• Have you seen good examples of hybrid GUI + DSL filtering systems?
• Do textual query layers actually improve UX, or just shift complexity?
• Where is the right boundary between GUI builders and query languages?

Happy to share implementation details if anyone’s interested.

I’ve been working a lot with Odoo, and one thing that kept slowing me down was advanced filters.

Once you start combining conditions, it becomes:

• too many clicks
• hard to read logic
• annoying to reuse or tweak

So I tried something different: instead of building filters, you just write a small query directly in the search bar.

Example:

name = 'Azure Interior' and price > 1000

Search with OQL

It plugs into the existing Odoo search bar—so it doesn’t replace anything, just extends it.

A few design goals:

• Use business terms instead of technical field paths
• Make complex queries easier to write and reuse
• Query history (quick reuse)
• Make queries reusable across a team (naming / sharing / management)
• State persistence (no retyping after page refresh)
• Minimal UI change (still feels native to Odoo)

Architecture-wise:

• Core engine is open source
• Web UI is open source
• Autocomplete is optional / pro

I’ve only tested it on Odoo v15 so far.

I’m curious:

• Would you actually use something like this?
• Or do you think Odoo filters are “good enough” once you get used to them?
• Is the syntax intuitive or confusing?

Happy to share more details / App Store link if people are interested.