github.com/d0sbit/gocode@v0.0.0-20211001144653-a968ce917518/README.md (about) 1 # gocode Code Generator (wip) 2 3 Easily generate Go code following common patterns: 4 5 * SQL CRUD operations (`sqlcrud`) 6 * MongoDB CRUD operations (`mongocrud`) 7 * REST HTTP handlers (`resthttp`) 8 9 Generate code quickly and easily. Customize the output to suite your project. 10 11 ## Installation 12 13 TODO 14 15 put something here about making sure ~/go/bin is in your PATH, and instructions of how to fix 16 17 ## Usage 18 19 ### Primary Keys 20 21 While GoCode tries to infer as much information as possible without requiring explicit configuration, 22 the case of composite primary keys (more than one field acting as the unique identifier for a database record) 23 needs explicit configuration. GoCode will identify primary keys (single fields or composite) using the following rules, 24 checked in sequence: 25 26 - If one or more fields have struct tags with `gocode:"pk"`, then those fields together form the composite primary key (or it is also okay if just one field tagged like this) 27 - If a field is named after the struct and followed by ID (e.g. type Xyz struct { XyzID string } ) it is chosen as the PK. 28 - If a field is named "ID" it is chosen as the PK. 29 30 Note that GoCode tries to avoid emitting field names where it can be avoided, for easier maintenance (instead reads them at runtime via reflect). But this may not be possible with primary keys, meaning if you change the primary key for a type you may need to regenerate or update methods emitted by GoCode by hand. 31 32 ## How it Works 33 34 `gocode` operates by invoking a separate tool which performs analysis on existing Go code (usually a single package), and then uses one or more templates to generate the desired output. The result is either written to a file, or merged into an existing file, according to the particular logic of the tool in question. 35 36 Each tool includes a set of built-in templates that it needs, and also supports reading template files from your project in order to accommodate project-specific tweaks. 37 38 <!-- 39 ## Notes 40 41 TODO: 42 * add to a list somewhere: 43 - punchlist 44 - try a few command line commands and make sure the basic stuff works 45 - implement helpers in mongocrud (maybe move to backlog) 46 - idAssign 47 - createTimeTouch 48 - updateTimeTouch 49 - storeValidate 50 - mongo Count() needs sort also just like SQL so it can determine the index (move to backlog) 51 - backlog: break up the tests so they track with which methods are included, and add the options too (-create, -read, etc.) 52 * Handlers 53 - get it building 54 - Fill out the other CRUD methods 55 - on testing decide if we are using an interface with stub stuff, or if we are doing the whole docker test stuff or what: maybe we need the equivalent of the "make me a test store" function that can be used by other test packages 56 - NOTES: 57 - see if we can express permissions with a super simple interface abstraction, e.g. CanRead(interface{}) bool, etc. 58 it should be optional, but could let us have perms from the get-go without 59 - both PUT and PATCH support 60 - querying should default to "normal" way but have a few lines of commented code to switch to cursor 61 - we can probably incorporate the key aspects of werr as helper methods - probably too simple to introduce a dependency 62 - probably we should support the wrapped return value approach but also a simple helper method or two for outputting 63 errors with a public message (since the controller usually handles that anyway), this way the only interface thing 64 we need is the HTTP status code 65 - or maybe not even bother with the wrapped error approach, as long as the helper methods are clear and simple 66 - decide what to do with the other options: ID, location info 67 - longer version, still good: if err != nil { w.WriteStatus(statusCode(err)); w.Write(logErr(err)); return } 68 - maybe a bit more compact: if err != nil { writeErrf(w, 0, err, "something went wrong: %d", n) } 69 - should there also be a writeErr(w, 0, err), what about writeErr(w, 0, err, "public message") 70 - 0 means extract status from err or 500 71 - writeErr can itself have the file:line and ID stuff in there, maybe file:line commented out by default 72 - maybe we don't need wrap function at all 73 - writeErrf(w http.ResponseWriter, status int, err error, responseFormat string, args ...interface{}) 74 - if status is 0 detect from err or 500 75 - if err is nil then don't log 76 - if responseFormat is "" then don't write to output 77 * Implement "gocode" 78 - See if we can obviate the need for the UI entirely by making the commands just target the file name, and use the folders (as well as settings) to infer which tools and the various settings. 79 - If we need to have some interactive stuff in there too that could be okay also (Did you mean X as the folder for ABC? [Y/n]) 80 * Decide what we want to do about main program, need at least something for that 81 * Implement custom template support - ideally an option would write the default template (files) to a well-known location and it could be edited frmo there. 82 * Add to backlog: 83 - HTTPStatusCode should probably go away and instead just check for things like sql.ErrNoRows, etc. in writeErr 84 - fix -dry-run on all programs so -dry-run doesn't accept args, use -dry-run-html if neeeded 85 * UI (if still needed) 86 - common flags approach so we can communicate to the UI what each program needs 87 - diff'ed (dry-run) output 88 * Clean up main README and make some decent exampels of how to use 89 * Anything we can do about API doc? Maybe something to generate what Swagger needs? 90 91 --- 92 93 * we should add Vugu UI generation! 94 95 * multiple templates - so either when you install or just in general you can select from multiple sets of templates, e.g. the sqlcrud generator can be sqlx, dbr, etc. 96 97 * maybe there's a dryrun mode where the input can be the os filesystem but the output can be something in memory, and so 98 allow us to create a full preview of the various changes 99 100 * gocode is the command 101 * gocode mongo-crud would invoke gocode-mongo-crud or similar 102 * the specific tool analyzes the code (usually a package) and performs some actions based on templates 103 * templates can be built-in or customized per project by putting template files in .gocode (should be a command to install them) 104 ( gocode ui - should launch a browser and give command examples for each of the various things - could it produce a preview? that'd be really cool, also examples, also auto completion 105 * need to standardize on a help system and ui system that gocode can use to glean info from, or use json or something 106 * provide plugins and templates for: sqlstore crud, mongodb crud, http handler crud 107 * tests for templates would be really useful as well - it's very easy to mess up a template and then not know it until you have to generate your next thing. Verifying that the result at least compiles would be useful 108 * interactive prompts might be nice, but decide if this is more useful than having a UI or even just decent documentation with lots of examples 109 110 Example command lines: 111 112 gocode mongodbcrud -struct Workspace -file workspace.go -package ./mstore -create -read -list -update -delete -all 113 114 gocode mongodbcrud -install-templates 115 116 -->