Screen question - getting data in actions vs forms

Is there a difference in either of these approaches to retrieve data for screen rendering? There are plenty of examples of both. If we look at find screens specifically, FindParty uses elastic and a service call is made in <actions>. FindOrder by contrast uses an <entity-find> within the <form-list>. Regardless of search method (elastic or entity engine), does it matter if the search is in actions or within the form?

1 Like

If the two approaches you are talking about are loading data from the database and from elasticsearch / opensearch yes there’s a significant difference. Loading data from the database hits the database directly for read and write operations. When installations reach a large size (usually a cluster of Moqui servers hitting one database), the amount of hits to the database exceeds the capacity of a single machine running a database. However, the read (and maybe someday write) operations can be moved to an search cluster which has built in data sharding and clustering potential built in so that the read operations can be distributed to multiple machines pulling data from the database with DataDocuments. Right now most of Moqui hits the database directly for read operations, however it makes sense to have new features / code be written to pull data from search. Doing this requires some knowledge of how search works, but makes sense in most scenarios.

Thanks Michael. I am clear on the advantages of using elastic for search. My question was more oriented toward whether to retrieve the data (regardless of how) in actions vs within the form tags. I should not have mixed the topics.
So let’s just focus on entity-find. You can put this in the actions section of a screen, or as is the case in many find screens it is within a form-list. Does it matter?

1 Like

The main reason to put an entity-find inside a nested actions tag in the ui widgets rather than an actions tag at the screen level is because some data is needed to perform an action that isn’t available in the context at a screen or transition level.

If an actions tag can go in at the screen level I’d say the convention is to put it there, otherwise a transition, and as a last resort in a the ui widgets like a form-list.

So, to answer your question, no it doesn’t really matter, but it’s common practice to put it in an actions tag before other places like a form-list.

It sounds like the main thing you’re wondering about is the entity-find element under the form-list element. That behaves mostly the same as entity-find within actions, but while it uses the same element definition in the XSD it is treated somewhat differently.

The main difference is for each entity (or view-entity) field in the entity-find that matches the name of a form-list field, that entity field will only be selected if the form-list field with a corresponding name is visible using the column selection dialog.

The idea behind this is to enable flexible reports where different “group by” fields can be shown or hidden (and in different orders, combined in columns, etc) to get effectively different reports. For example on an Invoice Item based report you might show a Product field and get results by Product, or you might show the Customer field and get results by Customer… or show both to get results by Product and Customer (all combinations of the 2 with data).

1 Like