ayanova/devdocs/todo.txt

@@ -3,54 +3,28 @@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
 REPORTING
-
-TODO:
-	Investigate how it would work through mockups, templating engine runs how, what steps lead from render route to produced report?
-	Steps:
-		Render route hit 
-			template with content, script and style is retrieved
-				(for testing from default report in memory or whatever is easiest)
-			Datasource determined (for testing from report default)
-			render engine determined (for testing from report default)
-			locale determined (for testing from report default)
-			Render out and return
-				call render engine, provide report and data as one object I guess
-					check with jsreport source, what do they do for this?
-				return results to browser
-
-
-	Review jsreport modules for each aspect to get an idea what they dealt with for each type of op
-
-	Find c# versions of all required tools to see if going to need dependency on Node or not
-	handlebars is a big one
-
-	Code minimum effective test as proof of concept, just start with static data, static report stuff and cobbled together render
-		no database involvement during testing!!
-		no designer other than vs code statically
-
-		just hit a route to trigger a static test then expand from there doing all the trickiest stuff first as proof of concept.
-		Once it renders a report of each type we need in mock then can actually code
-
-	TODO: CODE TEST:
-		Make an initial report controller
-		Make a test render route for each type of test want to do (easier than a lot of other options)
-			this way can just hit the route and view in the browser, rest is static at server
-		Make a test render method right inside teh controller for initial testing
-			headless chrome first, chrome already installed can probably just run it
+Assume headless chrome first for rendering, if it suffices then don't bother with other renderers unless it becomes necessary.
+	it's the most modern and probably supported long term way of doing the rendering and also easiest to grok for users since they develop in chrome should look the same or closest
+		
+		
+	TODO: Template engine / javascript test - Render a report off static data
+		Check how jsreport feeds javascript to their rendering process
+		Design a simple report with static json data that exercises the template engine and javascript functions both shared and unique to the report		
+		Excercise both handlebars and custom javascript and shared javascript
+		also css needs to be in there as well, just working, not necessarily correct or beautiful, just make sure it can work
 		
 
-	TODO: SAMPLE REPORTS
-		Try all these with headless chrome first, if it suffices then don't bother with other renderers
+	TODO: BASIC CAN REPORT OFF DATA WITH TEMPLATE ENGINE WORKING TESTS	
+			
 		Make a sample report with handlebars of each kind of report
 			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
+		Go through v7 reports of all kinds and look for anything to test that I might have missed above or below
 
-	TODO: Sample reports from client end with passed in data like any of the data-table based ui pages
-	TODO: Sample reports from client with actual objects
 	
-	TODO: Confirm basics before coding
+	TODO:  Confirm basics before coding
 		Handlebars works properly
 		page breaks properly
 		Wiki renders prints
@@ -66,6 +40,20 @@ TODO:
 		Security of scripts / scrubbing or sandboxing
 			make sure can't access file system at server with a malicious report
 
+SERVER render route actual:
+			template with content, script and style is retrieved
+				(for testing from default report in memory or whatever is easiest)
+			Datasource determined (for testing from report default)
+			render engine determined (for testing from report default)
+			locale determined (for testing from report default)
+			Render out and return
+				call render engine, provide report and data as one object I guess
+					check with jsreport source, what do they do for this?
+				return results to browser
+
+CLIENT TODO HERE: Nothing at client until I get to here to save backtracking
+	TODO: Sample reports from client end with passed in data like any of the data-table based ui pages
+	TODO: Sample reports from client with actual objects
 	TODO: build the report designer at client end
 		Need to get to a point where Joyce can do testing and whip up some reports and give feedback on improving that
 		Confirm it won't load extra stuff unless user actually designs report