Approach to construct queries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Approach to construct queries

jtuchel
Wolfgang,


you are correct. Building a complex query in a single Block never showed this error for me.

However, I was looking for an elegant way to construct complex queries out of individual small objects that are configured in a GUI. We've been using those monster blocks for a while, like this:

query read: Invoices where: [:inv| (self gui invoiceDate = nil or: [inv invoiceDate = self gui invoiceDate]) AND: ... ].

This gets quite messy once your GUI offers mor than, say, 5 different attributes for filtering.

So that is why i wanted to do it in pieces. Only GUI filters that are relevant for the query can then contribute a query block, while the others don't. This makes the code much mor readable. I am planning to write a blog post on this, but don't expect this to happen too soon... (unfortunately).

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Approach to construct queries

Alan Knight
I'm pretty sure that at some point I made an example with a GUI doing exactly this sort of thing for VW. 



On Wed, Mar 14, 2018 at 6:13 AM jtuchel <[hidden email]> wrote:
Wolfgang,


you are correct. Building a complex query in a single Block never showed this error for me.

However, I was looking for an elegant way to construct complex queries out of individual small objects that are configured in a GUI. We've been using those monster blocks for a while, like this:

query read: Invoices where: [:inv| (self gui invoiceDate = nil or: [inv invoiceDate = self gui invoiceDate]) AND: ... ].

This gets quite messy once your GUI offers mor than, say, 5 different attributes for filtering.

So that is why i wanted to do it in pieces. Only GUI filters that are relevant for the query can then contribute a query block, while the others don't. This makes the code much mor readable. I am planning to write a blog post on this, but don't expect this to happen too soon... (unfortunately).

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
12