CRUDGEON continues to get updates as I work on side things.

CRUDGEON is very reusable software. And very general. I mean, it has a specific case of “define a data model and generate code around that model”. But I made it very general. So I'm finding all kinds of uses for it.

However, it needed some clean up and a bit of an extension, some new features, and basically more abstract thinking to think how else I can use this.

A while ago, I thought about making a bootstrapping app that could take the same set of inputs that CRUDGEON did, but generate everything needed to get a basic site running. I would name it appbuilder or something generic. It turns out, I have an app for that, and it's called CRUDGEON.

The power of CRUDGEON comes in the fact that I don't hard code any behavior. As I label it in the github repo, “Behavior Driven, Multi-output CRUD generator.” Which is drives what is available to a generation when it generates. Like if I only want key fields for a delete stored procedure, it will only give it key fields. And the system, in the Object.Fields property, will only contain the key fields. So that same range statement, like range .Object.Fields, is good in every file.

But another thing I have in there is a condition flag. Very general, very demure. In order for a generation to process, it needs to match the condition. Just that is enough to build a whole app generator! I kid. But it is very helpful in getting there.

The thing about going from CRUD, which is what it was made for (generate the code so that it can read/write between a data source, usually a database), to an app builder, is that some object definitions for a database don't generally match exactly the same thing that needs to travel between a web browser and the server in order to save it.

So I have a new generation, defined as such

        { "file": "tmpl\\formhtml.txt", "ext": "jtml", "filenameTemplate": "_{{.NameLower}}", "folder": "./svc/jtml/forms","namespace":"","flags":"+collections,+fields,+keys","objdir":false,"oneFile": false, "conditionFlag": "+form"}

And only objects defined with the “form” tag are used to generate it. So I can have a completely different object, say, for a “to do” item, vs. the “to do” item that will get stored in the database. I was trying to make it be the same object but I think it'll get a little messy.

Messy because CRUDGEON, in its infinite reusability, also has a concept of custom flags. I could just add a flag like so:  

//+fdalfjdsaf fdsaf,-foo bar

And that's valid! And I have go template funcs defined that can access that. Like to check if it's a “+” or a “-”

{{ bitflag “fdalfjdsaf” }}

or if it's on a field

{{ if fldbitflag $fld “foo” }}

or get the value “fdsaf”

{{ stringflag “fdalfjdsaf” }}

So for form generation, basically I'll be using a new data type with a whole bunch of custom tags, and those tags will only be used in the form generation template. Also some fields will need to be present on form POSTs that might not make it into the database, like a user token. So, putting all of that in one file would be messy. There will be some code needed to take from the post object and map to the data object. But that's fine. I'm going to have to write application code, there's no way around it :)

So, after just a few small updates to CRUDGEON, and a bit more expansion of brain power, I can use it to get me like 80% there. I am still writing the templates that will run for generating an HTML form, and tying it together, completing the last 20%. But it would be unreasonable to assume you could just define a data type and generate a fully functioning app. But generate the boring parts? Yeah :)

Happy coding!