In the page context I would like to pass some data (collections, arrays, single values) from one block to an other block. It seems that $data “lives” only in the scope/context of a single block. On the other hand I was not able to add new attributes (from within a first block) to the $page object in order to make available the data assigned to those new/additional attributes to the other blocks in the same page.
I am implementing a block that accesses a sqlite db to show db records as a list. The same block type can be placed in the same page (based on LayoutBuilder) to show from the same db collection different “views”.
For example the first block shows the most recent 10 db entries (from the collection) and the following analogous block shows basically from the same collection (as the basis is the same db query) all returned db entries or filtered db entries from the collection.
Thus as the returned base db collection is the same, I wanted to “avoid” on the second or following blocks to re-query the sqlite db. If I can pass the base db collection between the analogue blocks and only work/filter on the collection already in “memory”, I assume there will be some speed up and I do not have to re-specify for each block the (very same) db query.
For this reason I would like to assign the base db collection in an associative array with an key that represents a specific search_id/query_id. If the search_id/query_id is already set as key, re-querying the sqlite db is not necessary.
As I am using a third party theme and only working on custom LayoutBuilder blocks to be embedded, I do not see how I could implement a appropriate controller.
I wonder if it would make more sense to define a collection that you can access from anywhere, or use a site controller or a page controller. Third party theme doesn’t mean that you cannot use controllers.
The concept of “global” collections is very useful and elegant.
“Unfortunately” it does not match my use case for the block I am implementing. The db access block is versatile in the sense that the content manager can define in the block panel its own sql-query statement (and also how it should be rendered). By a virtual “query-id”, also optionally definable in a field in the block panel, the content manager could “signal” that she wants to reuse a identical collection that is potentially already present in an analogue block on the same page as the rendered page is the only location in which an already present collection is only “living” (as php is stateless).
For this reason, I would like to “save” from within a block in the page context a collection in order to be shared by other analogue blocks on the same page. But actually I have no idea how to implement that, thus how/where to save the collection in the page context. I could use global variables, but that seems not very elegant (?).
On the app instance level it seems that $kirby is mutable, but that could be only my false interpretation of the note:
in any situation, you can define a $kirby object using the kirby() helper:
Maybe store them in a custom cache with the query-id as key, then in other blocks, check if the cache already exists and use the cached data. You would need some logic to invalidate the cache when the query with that key is changed.
The advantage of using the cache is that not only do subsequent blocks not have to reload the data, but also all other users accessing that page.
If you don’t want to cache anything and only need the data at runtime, you could use a page model in which you define a property as array (e.g. $data) with setter and getter. Then in the relevant block snippet, you check if $page->getData() contains the given key (if present) and use the value, or if not, you make the query and then store the result in the $data array.
Both approaches require that the user provides the same key if they use the same query.
Wondering if it wouldn’t be better to store such queries in a central place as key/value pairs and then just select a query by id in a block.
Many thanks again for your both detailed considerations (even on Saturday morning).
The cache approach could be a valuable hint. In our case data from db is read-only, db data does not often update - even I chose to use sqlite db to bee accessed from Kirby as copy of a recurring (every 10 min) export from mariadb in order to have the possibility to develop the block offline (as there is no way in Kirby to tunnel db connection to mariadb over ssh to the server).
I will also evaluate your second approach. In fact the collection data (for the same query) is only needed at runtime.