json filter pattern sample code

I'd tend to agree with you about the naming of the filter parameter (you're right the f/end shouldn't care about the b/end).

I would also suggest logging an Idea ( at https://community.progress.com/community_groups/products_enhancements/i/rollbase/default.aspx ) for a more granular filter mechanism (ie specify the parts of the query individually).

Interestingly, OData filters are similar to what JSDO does, albeit in the query string: https://msdn.microsoft.com/en-us/library/hh169248%28v=nav.70%29.aspx (not to say that's right, or the best way to do things; just interesting).

-- peter

The JSDO follows the OData standard when possible so not a coincidence :-)

Shelley

This was indeed one of the options that were considered in adding the JSON Filter Pattern.  We discussed this exact alternative with the exact same model (AutoEdge | the Factory) with Peter Judge :-)

It was a difficult choice, but the feedback received wanted to air on the side of ease of use.   As you point out the metadata on 'sugbject/operation/object' list can be converted 'easily' to an ABL Filter.   But it can equally be done on the client (which was the choice we made, ultimately.)  

The complexity in particular related to complex heirarchical queries.  The simple case of an array of 'subj/oper/obj' conditions is relatively easy, but it gets more complicated with nexted AND and OR (and NOT) conditions that make the simple temp table harder to process reliably -- the array was easy, but nested arrays was complex.   This was the case that kept the choice at ablFilter.  That and the desire of many ABL programmers to keep the syntax as ABL.

We did leave the option of supporting different filter descriptor open in the future -- hence the name of the property: 'ablFilter'.

Hello Stefan,

Thank you for your feedback.

Just to add a bit more information.

As Bill Wood mentioned, we looked into this approach at the time.

Sending a generic filter, sending a the filter using a combination of expressions and operators.

For example, the filter could be done using JSON where the expressions would be objects and the operators properties of them.

However, sending a complex hierarchical query to the backend would require a processor for the query on the server.

Another case, is the handling of operators such as LIKE. Should we send LIKE or send MATCHES?

If we decide to use SQL on the client, then it means that the server needs to have a processor for the query. Either a built-in one if it supports SQL queries or we would need to provide one.

We decided to use ablFilter to indicate that the filter is in fact an ABL expression.

We could in the future support a different filter.

Thanks.

Understandable. I made a framework with aetf as starting point - it is in production for a couple of years now-, only at one occassion until now a special filter was needed. I used

create ttFilters.

assign ttFilters.TableName   = 'ttCustItem'

      ttFilters.Operator    = 'SpecialFilter'

      ttFilters.FilterValue = 'filterAvblLtSalable'.

for that, the special filter was in an abl method named  'filterAvblLtSalable'.

 But I'll see that I log the idea as suggested by Peter. For now I'm going to imitate Peter's method on the client.

--

Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager