tl;dr - A report asset that nests a listing_engine
asset to define the contents of the report, decoupling generation from serving.
I semi-frequently find myself thinking “I’d love to provide that asset listing / search page to the users … but it’s too heavy to have them running on demand”. The Report asset types in Matrix (report_links, report_asset_statuses) already have a “generate” concept that decouples viewing the report from generating the report. This would be a useful feature to be able to leverage in custom reports.
I see the 5-minutes-consideration version looking something like a hollowed out copy of one of the built-in reports which accepts a link to another asset to define the actual data in the report.
- A new asset type, with attributes to allow users to provide
- A listing asset (Asset Listing or Search Page) which the user has already set up to produce the desired output
- All the same options as a Nest Content Container to allow passing of parameters to the “nested” listing asset
- Some kind of options to specify how frequently the report can be re-generated
- On the admin side, the details screen would be much like an existing report providing
- information on when the report was last generated
- a button to allow regeneration
- Ideally, some restriction to allow only “publishing” users (simple_edit_users?) to generate the report once per time window specified on the asset
- At generation time, the report should be able to “walk” the asset listing to get the whole thing
- e.g. I set up an Asset Listing over an area of 10,000 assets with 500 per page. The report should (optionally) fetch all 20 pages when generating, so it can serve the complete version to users. This would likely require a small new HIPO
- e.g. I set up an Asset Listing over an area of 10,000 assets with 500 per page. The report should (optionally) fetch all 20 pages when generating, so it can serve the complete version to users. This would likely require a small new HIPO
- On the frontend, the report would serve the data that it got from the listing asset at the previous generation
- would need to store
content-type
header to make sure you could use this asset to spit out HTML/JSON/XML (determined by the design set up of the listing asset, or an option on the report asset itself)
- would need to store
This would really change the scope of what we are comfortable providing to our users, allowing more complex insights by leveraging partly-existing functionality and fitting in well with the existing report concept.