This commit is contained in:
@@ -9,7 +9,29 @@ REPORTING
|
||||
Useful links:
|
||||
https://handlebarsjs.com/
|
||||
Report templates pre-designed and open source: https://github.com/wildbit/postmark-templates
|
||||
|
||||
Example jsreport designer: https://playground.jsreport.net/w/admin/dI2_fUqZ
|
||||
|
||||
TODO: Where is the data coming from for the reports?
|
||||
Can report off single object or DataList, but then datalist isn't all the fields of the object.
|
||||
Was thinking it gets sent by the client back to the server but that's bandwidth wasteful
|
||||
in v7 reports are basically designed arounda single object but accomodate multiple and it's same fields?
|
||||
There is really no concept of a single report vs a list report is there?
|
||||
Only "summary" vs "detailed" which in essence means flat vs hiearchical for wo and less vs more fields for flat objects
|
||||
I'm thinking a report is for an object type, i.e. "Widget"
|
||||
reporter gets a list of id's if it's one then it's one, if it's a list then it fills out the data from the list
|
||||
if user is reporting off a datalist that is filtered then the id's are all that's needed to report off that, if it's a single then just pass the id
|
||||
This way server does the work of fetching the data and this will even work client-less
|
||||
Server must populate an alternate version of the object because the Client consumes a widget differently than a report would
|
||||
Report needs all data fetched and populated even if it's an id reference to another object
|
||||
Can use name display format
|
||||
When a report gets a widget it's getting something different than if the client gets a widget
|
||||
|
||||
|
||||
TODO: Enough UI to get started testing reporting and seeing what features need to be added and where
|
||||
Render route, pass data, design report
|
||||
replicate the jsreport designer as much as necessary for our purposes but don't get ahead of things, do it incrementally
|
||||
|
||||
|
||||
|
||||
TODO: BASIC CAN REPORT OFF DATA WITH TEMPLATE ENGINE WORKING TESTS
|
||||
|
||||
@@ -17,7 +39,7 @@ Useful links:
|
||||
Report off a single widget with handlebars
|
||||
Report off a filtered widget list with handlebars
|
||||
Report off a list with custom javascript functions for totals and subtotals
|
||||
Report with logo
|
||||
_Report with logo
|
||||
Go through v7 reports of all kinds and look for anything to test that I might have missed above or below
|
||||
|
||||
|
||||
@@ -25,8 +47,8 @@ Useful links:
|
||||
_Handlebars works properly
|
||||
page breaks properly
|
||||
I guess when it starts a new record in a big list of data or something i.e. in a list of widgets it starts a new page on a new widget
|
||||
Wiki / Markdown renders prints
|
||||
logo / graphics
|
||||
_Wiki / Markdown renders prints
|
||||
_logo / graphics
|
||||
_custom javascript functions
|
||||
Shared javascript libs
|
||||
Localization
|
||||
@@ -101,16 +123,20 @@ REPORT TEMPLATE FORMAT
|
||||
content - the html markup for the report
|
||||
css - css style to apply to report
|
||||
script - javascript methods to use with report
|
||||
Helpers for handlebars vs pre-process data before render?
|
||||
no need for shared, can just copy or be predefined ones we provide for most situations
|
||||
defaultlocale - default locale to render from
|
||||
defaultDataAyType - default object type for this report when it's intended to report directly off an object
|
||||
i.e. Widget type so all the report requires is an ID to render and it will fetch that and report it
|
||||
defaultDataList - default dataListOptions values (saved datalist?)
|
||||
can be subbed at runtime by giving alternate or this will just be the default
|
||||
defaultData - static data saved with report like a json fragment or something
|
||||
Present when:
|
||||
What if, a report is designed for a widget object and handles list of widget objects
|
||||
Then, the id's are passed in order to the server if it's a list and it in turn just fetches each widget and adds it to the report data based on id's
|
||||
Reason being that a datalist may not have all the fields so either we include all in report mode (but then it's not coming from client as that would be wasteful if not displaying)
|
||||
defaultDataAyType - default object type for this report when it's intended to report directly off an object
|
||||
i.e. Widget type so all the report requires is an ID to render and it will fetch that and report it
|
||||
defaultDataList - default dataListOptions values (saved datalist?)
|
||||
can be subbed at runtime by giving alternate or this will just be the default
|
||||
defaultData - static data saved with report like a json fragment or something
|
||||
renderAsType - renderType (pdf, text, csv, etc this way the report is designed specifically for that type and if they want more than one they need to copy and modify)
|
||||
How to include libs like labels etc?
|
||||
I guess we have a curated set we include and for security and if they want something else they can just use a CDN script link
|
||||
Need to vet those I guess
|
||||
|
||||
|
||||
|
||||
Data
|
||||
|
||||
Reference in New Issue
Block a user