-
Notifications
You must be signed in to change notification settings - Fork 0
/
notes.txt
97 lines (73 loc) · 6.39 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
----
TODO:
(earlier than 2019 - merge conflict meant I lost the date and i cannot be bothered looking it up right now)
* Pagination is hacky when using Oracle - it needs an 'order by' specified on the innermost subquery, however we don't know what columns are unique at this stage. When allowing edit capability, we might need to prompt users to specify the column with the primary key (or a unique constraint at least). Warn users if they choose to continue without specifying that as rows may be returned in random order. (Jul 2017)
Replacement variables for e.g. current region/page/app id, so we can reference them within the templates.
----
DropDown (2019-02-14):
* Now renders. Needed a 'FieldConverter' Dozer type to map the appropriate field instance types.
* (FIXED) We are missing FIELD_SOURCE for the dropdown field on page -10001
** (FIXED)Add in the FIELD_SOURCE to populate the options list, and go from there.
* 2019-02-17: now working - renders full dropdown with options and selected
* TODO: bind variables are not yet supported.
* Oracle setup SQL needs to be updated.
Edit page:
* Use PageRenderController to render form pages, e.g.: http://127.0.0.1:8080/summit/run/-10000/-10000?pageParams=code:dml_report
** I _think_ the purpose of PageEditController was to be for creating/editing summit apps, e.g. the internal pages.
** That said, the setup-backend.sql looks like an attempt to begin creating edit pages for summit itself???
Fields and postProcessed values:
Current implementation (2017-Nov):
* A field domain/dto describes the metadata of a field that should be output on page rendering.
* FieldDto is mapped as part of the page mapping
* FieldDto contains a postProcessedSource String
* This string gets populated after mapping and before formatting
* The processing is done in PageRenderingServiceImpl.processRegionsForRender and in PageFilteringServiceImpl.filterQueryOnRegion
* A ProxyFieldProcessor is called, this retrieves the FieldProcessorServiceImpl relevant for the FieldDto class.
** ^^^^^ Currently this will always retrieve the same processor, as the fields are always a FieldDto class.
** +++++ Perhaps we should store a 'PROCESSOR_CLASS' column on the FIELD domain and DTO to direct us to the appropriate processor?
* In the case of a simple field (non-KvP fields, single result) the field source is then 'processed' and stored as a string.
* In the case of a dropdown field (or KvP fields/complex multi result source processing) the child items of the field are populated, these are stored as a List<PageItem<String>>.
** With these complex fields, replacement variables handle the replacement of the values of the child items in the appropriate place in the template. This also means a template must be setup for the child items to be handled appropriately on page rendering.
Formatting - On formatting to a string for page render:
*
Ideas to sort this mess out:
* Standardise on fields having:
** Get rid of post processed source on FieldDto
** Instead use similar method to the dropdown items - that is a List<PageItem<String>> which is a very simple object that contains the processed source as a string, with replacment variable for use by the formatter instead of the formatter using 'getProcessedSource' directly.
** PROCESSOR_CLASS to direct to appropriate processor
** A template for each child page item where appropriate (check if this is OK for the simple field approach).
Limitations:
* Page parameters must populate a field on a page to be used.
* Fields can only be used as bind variables when they exist in the same region as the query using them.
** Fields can be re-used in multiple regions in a page (mitigates the parent issue)
* Bind variable scraping is done via a simple regex, that just searches SQL for a word after a ":". This will then probably cause issues for SQL that contains a ':' for something that is not a bind variable (e.g. within a search string predicate etc).
TODO:
* Conditionals on PAGE_PROCESSING must be implemented.
* Page POST processing when using 'dml_modify' as source type requires the SQL query to include CASTs, as all bind variables are treated as VARCHAR.
** Unsure how to approach a fix for this at present, perhaps we include the field types/java SQL types in the form?
* Report region HTML templates for mustache are hard coded in javascript, need to add REST call to pull this down from server.
* Exception page always prints ResourceNotFound?
* PageProcessingSourceSelect is a bit of an unusual concept - it populates fields on a page for a PageProcessing source, but does so based on their field index... maybe medium term look at other options.
(done, although may need to add more vars:)
TODO: Replacement variables for e.g. current region/page/app id, so we can reference them within the templates.
Need to be able to then use these variables in place of e.g. the region id for a report region, so we can have multiple report regions working with the mustache templating on one page.
-------------------- Old notes from pre-December 2016 -----------------------
* Render:
* Picks up wanted page by ${applicationId}/${pageId}
* Controller hands off to PageService
* PageService pulls in:
** Page Domain, linked domain objects such as Regions, RegionField, Fields.
** Linked templates
* First pass in rendering then grabs the template and puts it into an object that is manipulated.
* A pass is then done on the Fields, executing any SQL to bring in values.
* A pass is then done on Regions, inserting the post processed Fields into the Regions
* A pass is then done on the template, inserting regions into appropriate areas
* Full page is then returned to the client requesting it.
Passes should be done in the above order, to stop people inserting textual values that look like replacement region strings and them being replaced by the parser.
* Reports?
** Summit developer enters in a query
** Query should be run when saved to pull out resulting columns
** Manipulation of column names can be handled by the summit developer at SQL level, saves us needing to manipulate the columns etc after query has been produced
** Standard page produced with table containing results.
** Down the track we can look at adding virtual columns etc
Due to design, reports should be handled by the same process as standard page render. The only difference is the type of Region selected... this implies the region render service will need to have some conditional logic when a 'report type' vs a 'form type' region is selected.