QueryLayout Object

If you have questions or if you want to share your opinion about Aware IM post your message on this forum
Post Reply
Posts: 1457
Joined: Tue Jan 24, 2017 5:51 am
Location: 'Stralya

QueryLayout Object

Post by PointsWell »

Would anyone else find a QueryLayout Object useful?

What is this?

At the moment a query consists of two parts combined into one - FIND and then a UI Layout

Because this is encapsulated into a single object then minor modifications of that Query require completely new Queries

For example

Code: Select all

FIND Car WHERE Car.Doors=4
FIND Car WHERE Car.Doors=4 AND Car.Wheels="Alloy" (* see below for disclaimer)
If both of these queries show a grid that contains

Code: Select all

Panel Header Text
Car.Make, Car.Model, Car.Colour, Car.Doors, Car.Wheels | Operation on Record1, Operation Record2
Footer {Count Cars}
Then you decide that the order has to change and you want a new Panel Operation, then there are multiple touch points that have to be made. You can either copy the FIND statement modify one of the Grids and then copy the Query and then replace the FIND (which has to be done in a very specific order to prevent AIM correctly renaming things that reference the query) or manually touch every grid. This was covered in this discussion thread three years ago

In terms of effort the building of the FIND statement is the least time consuming (as in you will spend more time fine tuning the query UI and are going to come back and touch this more frequently following user interaction).

If the QueryLayout existed as an entity that instead of a FIND text box had a Displays Business Object value, you could then use DISPLAY Account WHERE Account.State = 'OPEN' ORDER BY Account.Balance and follow it with USING QUERYLAYOUT

This would completely eliminate the need to duplicate the effort of building the UI for the query where it wasn't required (due to you having already defined it for another query).


Code: Select all

DISPLAY Account WHERE Account.State = 'OPEN' ORDER BY Account.Balance
is entirely useless because it offers zero control and will display the Account attributes in an arbitrary layout and more egregiously add an EDIT operation by default. Being able to use it to then force a QueryLayout would make it useful (as it would using the PICK operation which is useless unless it is used to PICK FROM QueryName, which again develops redundancy as the Query has only one FIND string that can be run per query - you can't dynamically manipulate the statement to have multiple subqueries if you've only anticipated one subquery, so you end up with multiple versions of the query where there is one subquery, two subqueries, three subqueries).

Specific benefits of this would be
  • QueryLayouts are reusable for multiple different finds (via the DISPLAY action) where the find has a minor change but has to be shown in the same format which would make subsequent modifications easier where a column has to be added or an operation with records added etc (See https://awareim.com/forum/viewtopic.php ... 34&p=54324, as per comments there are multiple requirements for the ability to easily modify query layouts, this fixes that by decoupling the finding of BOs from their display)
  • Dynamic FINDs (again via the DISPLAY action) fixes my issue of a dynamic query text where I may not know how many times I have to run subqueries
  • Makes the DISPLAY BO action useful - at the moment

    Code: Select all

    DISPLAY Account WHERE Account.State = 'OPEN' ORDER BY Account.Balance
    is pretty useless as it presents columns in an arbitrary format and includes the EDIT operation. The only time that this might be useful is if you are returning a BO that only has one column - and even then you are unlikely to want the end user to be able to edit these instances.
  • Could also be applied to PICK and PICK ONE OR MORE - where the inputs to the pick query might be only very slight changes whereas the layout that you want to show is the same across more than one version of the PICK query, again

    Code: Select all

    PICK FROM Account WHERE Account.State = 'OPEN' ORDER BY Account.Balance
    is pretty useless as there is no control over the column layout and so it can only be used with PICK FROM QueryName
  • The FIND statement is the fastest element of a query to develop, the UI is the thing that takes time tweaking and modifying - it becomes a pain when the finely tuned layout turns out to need modification after you’ve created 4 version of it.
  • Consistent extension of the the AIM language structure e.g. when interacting with BOs that have different FORMS (VIEW BO USING FormName), how processes are interacted with when they have BO inputs (ProcessName USING BOName).
You could just write one query and send everything out to a stored procedure, but
  • that is undermining the low code ethos,
  • this route requires that the system is completely stable because once you publish the first time any SP is then uncontrolled (i.e. if you change the BO or attribute names then the SP does not get updated, and the SP can be edited outside of the control of AIM)
  • the number of inputs for the SP is not dynamic
*These are super simple examples to demonstrate a specific point whether it is the right way to show this specific data is not the point. The problem that I am trying to attack is significantly more complicated and describing it would be distracting.

This is badly described in this FR
Last edited by PointsWell on Fri Aug 25, 2023 4:37 am, edited 2 times in total.
Posts: 2443
Joined: Tue Jan 13, 2015 10:58 am
Location: Tampa, FL

Re: QueryLayout Object

Post by Jaymer »

From March 2020 - The State of Grids
Click Here to see a collection of my tips & hacks on this forum. Or search for "JaymerTip" in the search bar at the top.

Aware Programming & Consulting - Tampa FL
Posts: 2588
Joined: Fri Feb 01, 2013 1:13 pm
Location: Scandinavia

Re: QueryLayout Object

Post by hpl123 »

1+ for something like this.
Henrik (V8 Developer Ed. - Windows)
Post Reply