steveoc64
commented
7 years ago Hi Joe, sorry bout the delay getting back to you.
Type conversion is a horror. Especially date fields !!! And nested structures with pointers to date fields !!!! Not fun, but it keeps us in work.
This lib here is aimed at fixing that whole binding issue, at least for my little subset of applications that im working on. In my case, my Go models generally end up being passed to a backend function that then talks to an SQL database, so pointer data types are used to gracefully handle NULL fields in the data.
The idea is to have this middleware worry about all the mess involved with moving data to and fro between Go structs and DOM. It covers all the cases that I need, and shouldnt be too hard to adapt to other environments.
It uses "temple" from the above to generate templates into the app.js file, and this formulate lib is sort of a replacement for the "form" pkg in go-humble (which is totally lacking in needed functions). Their router package is very nice though, so I use that heavily.
Ive added some example templates (edit-form.tmpl) for edit forms, if that helps. List forms templates are generated on the fly based on the columns defined in the list.
In the EditForm library :
Render() creates a new DOM tree for a form, and populates it data from go models based on the field definitions, using the standard go template lib, and some helper functions found in https://github.com/go-humble/humble
Bind() converts data from the DOM back into Go models, and handles the most common types including strings, ints, floats, and dates, booleans from checkboxes, etc. Go models can also include pointers to the above, and the bind function generally does the right thing with them.
Paint() is used to update the DOM field contents (after its been created) from a Go model, which is used for filling in derived fields as data changes.
The "idiomaticly correct" way to do all of the above would be to define some sort of DOM-field interface, and use separate functions for each type of thing that you might want to map to each type of DOM widget that you might want to render.
Thats tedious though, and best left for a longer term approach. For now, the above code uses a monolithic approach, which is a bit easier to digest and hack with.
PS: I currently have a working example of a "tree-form", and some decent photo upload widgets that will be migrated over into here before long.
PPS: Had to take that other repo down under private cover, as it started to include a lot of proprietary code, but I have approval now to build a training app that demonstrates how to use all these bits and pieces.
PPPS: Going to have a look at that polymer stuff later ... looks good, thanks for the link. Im also interested in doing a port of leaflet.js to gopher, as I need to start doing some heavy map mashups soon, and leaflet is a great library for that.
Hey.
What UI library are you using this with ? I am having allot of trouble with type conversion from the web world to the golang world.
Currently i am using polymer go. https://github.com/PalmStoneGames/polymer It works OK, but as i get more complexity i find myself not being very DRY.