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  -->