This is true except if you need to query against related data in portals, those have to be on the query layout. There may be a scenario where you want to filter results based on a related field but you don't actually need to return that field in your response. E.g. maybe you are trying to return a list of customers that have at least one related invoice in the past year. You could query the related Invoice table's date field (visible on the "query layout"), and then return only a few fields that exist on the layout.response layout (just the data needed to display in the list UI).
The ability to query in one context and return data from a second context was provided with the PHP/XML APIs. It's good to see that the Data API is providing continuity.
I've never heard it said that you do not have to have the fields that you are querying on the initial layout. Can you point to some references for that?
Convenience is a big reason. It's fairly easy to make layouts that provide the exact fields needed for a task. They can be fields from related tables and/or portals. You can provide a standard layout for query and then return the result from the layout that corresponds to the current function.
Bandwidth is another reason to do this. In one case, we were providing search on a botanical database. There were a large number of fields and some of those contained long text. We performed the search on a layout that was equivalent to Form View. We switched to a layout that contained the primary identifiers, equivalent to List View. That allowed us to build a list for the user who could then select an item and view the detail. The weight of the list view was less than 10% of returning results from the form view.
Security. You can control the layouts that are accessible to the web user. However, you may want to extend the ability to search across fields that are accessible on those layouts. The search can run at a higher privilege set, to obtain access to a different layout, while returning data from the web accessible layouts.
So, if the user account permissions allow it, the entire table is accessible to search whether or not the fields appear on the layout. Extra fields from related tables can be added to a layout but related TOs are not accessible unless the field is placed on the layout. I had thought that a field which wasn't on the layout wasn't accessible to search.
That's very interesting. Thanks for the video. That is something that I'll take into serious consideration.