QueryLayout Object

[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).

Currently

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

[Jaymer]

From March 2020 - The State of Grids

[hpl123]

1+ for something like this.