ayanova/devdocs/todo.txt

@@ -72,42 +72,7 @@ CURRENT TODOs
 CURRENT ITEM:
 	BIZ OBJECT STUBBING FOR EXPORT TESTING OF HUGE ATTACHMENTS AND WIKI AND ATTACHED DOCS
 
-Workorder routes
-	Workorder is a "heavy" object so need to be careful how this is split out
-		Avoid full transfer of wo where possible but don't avoid it when it's the best solution
-		Don't make the client do too much work, the server has a lot of stuff it can do
-		Task oriented routes are important for the wo beyond the basic crud ops there are a lot of other tasks at hand not involving moving data (i.e. set all parts closed etc)
 
-	One workorder route for entire graph of workorder object (i.e. not a woitem route or a woitempart route etc)
-	GET/id - gets the whole workorder and all descendents in a full graph
-	PUT - Put's the whole wo and all descendents in a full graph
-	DELETE - this one is different, can specify all wo or a descendent
-		is basically a request and may return broken rule error but if it works then it returns no-content
-	MISC ROUTES for exact tasks, such as closing or whatever the UI needs to do
-	When it doesn't need to return teh whole workorder it will endeavour to avoid it but not shy away from it where necessary
-	don't want the client to have to do too much work
-	Routes that won't affect the workorder as a whole don't need to return the whole workorder, maybe just the "delta" of the descendent or object in question
-		i.e. if you add a new woitem there's no need to return all teh workorder if nothing has changed, just acknowledge it and return the id for the new row
-
-
-	Has routes for delete / add descdendents, returns whole wo object after they are executed
-		- When Add or Delete descendent is called at client, the whole wo is saved first if dirty, then after it's updated a delete / add route is triggered which returns whole wo again
-			this seems like a lot but, due to business rules and automaticicty of certain ops it needs to process the whole thing at the server 
-
-		- NOTE: not a seperate route for each type, instead, a single route that takes a type and id and parent wo id and handles deletion and returning updated wo
-			- client updates entire wo locally when it gets back the wo result of the delete
-
-		- This is important because we need a way to deal with delete add descdendents as rules need to be applied and also applied to header / totals etc
-		- e.g. workorderitem, in v7 you called delete on the woitems collection which in turn marked a woitem for deletion, but only the db update actually deleted it
-		- since v8 is disconnected need a route to do that so call delete on an item 
-	still split in db just using proper linking and stuff to work
-	start with wo->woitem and move outwards from there as that structure is basically all that's required to do the rest once figured out
-	workorder descendant types are still their own biz objects because of searching and in some cases attachments too.
-		- Not sure how deep to support attaching and custom fields, it's going to impact the UI a lot if I get too crazy with it, but maybe keep it as an idea
-			- Add CUSTOM FIELDS to top level as the new thing (previously only woitem in v7)?
-			- Add wiki and attachments to woITEM level (new thing, previously only header)?
-		- going to need a lot more aytypes for the full graph of each type of workorder basically or whatever it supports
-	
 
 Modify v8 export to export everything (at least teh wikiable and attachable and custom fieldable)
 	Uniquify NAMES: go through all and check which ones need to be uniquified by checking db schema of v7 or biz rules maybe
@@ -789,7 +754,48 @@ todo: workorder UI layout stuff (TTM!!  Don't re-invent the wheel!)
 		On a PC people will want and expect it to look as much like v7 workorder as possible, maybe that's still a valid layout
 			just tweaked to work better as a web app a bit but theoretically I could almost duplicate that layout with the tools I have
 		
+WORKORDER BACKEND THOUGHTS
+=-=-=-=-
+Workorder routes
+	Workorder is a "heavy" object so need to be careful how this is split out
+		Avoid full transfer of wo where possible but don't avoid it when it's the best solution
+		Don't make the client do too much work, the server has a lot of stuff it can do
+		Task oriented routes are important for the wo beyond the basic crud ops there are a lot of other tasks at hand not involving moving data (i.e. set all parts closed etc)
+	Shadow properties
+		- will need shadow properties not persisted but that tell teh UI stuff like "canDelete" for a workorderitem etc
+		- this will save a lot of business rule checking at the client end
 
+		
+	One workorder route for entire graph of workorder object (i.e. not a woitem route or a woitempart route etc)
+	GET/id - gets the whole workorder and all descendents in a full graph
+	PUT - Put's the whole wo and all descendents in a full graph
+	DELETE - this one is different, can specify all wo or a descendent
+		is basically a request and may return broken rule error but if it works then it returns no-content
+	MISC ROUTES for exact tasks, such as closing or whatever the UI needs to do
+	When it doesn't need to return teh whole workorder it will endeavour to avoid it but not shy away from it where necessary
+	don't want the client to have to do too much work
+	Routes that won't affect the workorder as a whole don't need to return the whole workorder, maybe just the "delta" of the descendent or object in question
+		i.e. if you add a new woitem there's no need to return all teh workorder if nothing has changed, just acknowledge it and return the id for the new row
+
+
+	Has routes for delete / add descdendents, returns whole wo object after they are executed
+		- When Add or Delete descendent is called at client, the whole wo is saved first if dirty, then after it's updated a delete / add route is triggered which returns whole wo again
+			this seems like a lot but, due to business rules and automaticicty of certain ops it needs to process the whole thing at the server 
+
+		- NOTE: not a seperate route for each type, instead, a single route that takes a type and id and parent wo id and handles deletion and returning updated wo
+			- client updates entire wo locally when it gets back the wo result of the delete
+
+		- This is important because we need a way to deal with delete add descdendents as rules need to be applied and also applied to header / totals etc
+		- e.g. workorderitem, in v7 you called delete on the woitems collection which in turn marked a woitem for deletion, but only the db update actually deleted it
+		- since v8 is disconnected need a route to do that so call delete on an item 
+	still split in db just using proper linking and stuff to work
+	start with wo->woitem and move outwards from there as that structure is basically all that's required to do the rest once figured out
+	workorder descendant types are still their own biz objects because of searching and in some cases attachments too.
+		- Not sure how deep to support attaching and custom fields, it's going to impact the UI a lot if I get too crazy with it, but maybe keep it as an idea
+			- Add CUSTOM FIELDS to top level as the new thing (previously only woitem in v7)?
+			- Add wiki and attachments to woITEM level (new thing, previously only header)?
+		- going to need a lot more aytypes for the full graph of each type of workorder basically or whatever it supports
+	=-=-=-=-=-
 
 todo: Documentation
 	Need to think this through carefully