ponzu gen content with JSON file

[joshdstockdale]

Have you thought about generating the content from a provided json schema?
ponzu gen content -f song.json

And the schema in the song.json would validate against the intended output of the API. For instance, this schema:
{ "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "properties": { "data":{ "type":"array", "items":[{ "type":"object", "properties":{ "uuid": {"type":"string"}, "id": {"type":"integer"}, "slug": {"type":"string"}, "timestamp": {"type":"string", "format":"datetime"}, "updated": {"type":"string", "format":"datetime"}, "title": {"type":"string"}, "artist": {"type":"string"}, "opinion": {"type":"string"}, "img_url": {"type":"string", "format":"url"}, }, "required":["title","artist","img_url"] }] } } }
Would generate the backend form and content type. Then when data is loaded into that content type, it would output json from the api like:
{ "data": [ { "uuid": "3d3e4b20-939c-4663-b7d0-f3fa6b172b4a", "id": 1, "slug": "song-3d3e4b20-939c-4663-b7d0-f3fa6b172b4a", "timestamp": "2018-09-08T02:23:02Z", "updated": "2018-09-08T02:23:02Z", "title": "Song 1", "artist": "Thomas Thomas", "rating": 1, "opinion": "Good, but redundant", "img_url": "http://zoohoo.dallaszoo.com/wp-content/uploads/2016/10/IMG_4093-Jax-Mandrill-CS.jpg" } ] }

Which validates against the above schema. And there could be additional fields added to the schema that would handle things like :richtext

[nilslice]

Hi @joshdstockdale - there has been some discussion (though quite a while ago) where something similar to your example schema was suggested. See this ticket for some more context:
https://github.com/ponzu-cms/ponzu/projects/2

I haven't done much thinking about this, but I agree that it could be a useful feature. One question I have about this approach is if I don't use a -f file as input, but rather generate code from the CLI in the current manner, do you think there should be a generated song.json file output somewhere to disk? If so, what is the expectation for how this json file is maintained? Users tend to generate the code once, and may manually add a field and a form editor input without re-generating, so I can foresee this getting a little messy.

I'm glad to see more people thinking about this -- and would be happy to consider a spec for how it would work in order to get it in as a feature.

[junnotantra]

Hi guys,

This feature to (re)generate content from a file is something that I think would be very useful. I've read this and previous discussion also. I think the most simple format is this one, but I made some tweak to the structure. So I try to write it myself and here is the PR #327

Let me tell you how it works

Now the CLI to generate content accept 2 new optional flags --source and --output
When provided the --source flag, ponzu will try to load a JSON file from content folder with the same file name as the content name.

Example:

$ ponzu gen content review --source

Will try to load content/review.json and generate the content/review.go based on the JSON file content.

On the other side --output will write the fields definition to JSON file

Example:

$ ponzu gen content review title:"string" body:"string":richtext rating:"int" --output

will write to content/review.json something like this

{ "body": "string:richtext", "rating": "int", "title": "string" }

limitation

This feature still have a lot of rooms for improvements, this is some of them that I can think of:

• The order of the fileds on the generated json template file are random, so when you regenerate from file you might get different order on admin interface also
• The generated json template file is not pretty printed yet
• Maybe need a feature to regenerate all content types instead of one-by-one. Something like ponzu gen content --source would be great
• Ofc if you modify the code, it doesn't sync with the json template file. Not sure how we should handle this, or maybe just let it be.

Let me know what you guys think 🥂

[olliephillips]

@junnotantra you're in the zone my friend :)

This looks excellent thank you for furthering it. Again, I'm really time poor at moment, but someone will get to this as soon as possible.

Two observations after only (admittedly) scanning the above, apologies if I missed:

1. If no --source specified what is the default behaviour does the cli api remain the same as is now the case?

2. re the --source do you think the an optional path could be added so that the json file could be elsewhere in the filesystem, but still usable? I'm thinking same directory or absolute path to the target might be useful.

Will look further ASAP. Maybe @ponzu-cms/team or @joshdstockdale may want to input.

[junnotantra]

Hi @olliephillips ,

If no --source specified what is the default behaviour does the cli api remain the same as is now the case?

yes, it just works like usual

re the --source do you think the an optional path could be added so that the json file could be elsewhere in the filesystem, but still usable? I'm thinking same directory or absolute path to the target might be useful.

This also crossed my mind when I'm making the changes. Not sure if it's worth it, I think to just use the content directory to centralize everything. But this sure can be an improvement.

If anyone else think this is a must have feature for now, just let me know.

[nilslice]

@junnotantra @olliephillips -

Just two observations / comments:

Maybe need a feature to regenerate all content types instead of one-by-one. Something like ponzu gen content --source would be great

I think the use of multiple .json files (one per type) is going to be too verbose. Using one global content.json or similar would be my preference. I've worked on Ponzu projects with 20+ content types, and I'd have been quite weighed down bouncing between all of those. Just my 2 cents.. happy to learn more about your proposal to split them up!

Ofc if you modify the code, it doesn't sync with the json template file. Not sure how we should handle this, or maybe just let it be.

In order to make this as elegant as possible, if the --source flag is passed, 2 things should be done.

1. Ponzu should generate a comment at the first line of the content/X.go file:

// This file was generated by the Ponzu CLI using `--source` input. DO NOT EDIT.

2. the content/X.go file should be saved as content/X_gen.go (appending the _gen.go prefix). This makes it very clear that this file was generated.

This way, users can add content/X_custom.go files next to the generated ones to "extend" their functionality. It isn't perfect, since the MarshalEditor would be generated at first, but if modified, need to move out of the _gen.go file and into a custom one. I think the JSON source schema would need to have an indicator of some default code gen output that should be skipped. So the user can define "generate_edtior": false on future invocations and not see conflicting implementations of their methods if they had previously moved a generated one into a custom file.

Does that make sense? Happy to clarify.

Thanks,
Steve

[junnotantra]

Hi @nilslice

I think the use of multiple .json files (one per type) is going to be too verbose. Using one global content.json or similar would be my preference. I've worked on Ponzu projects with 20+ content types, and I'd have been quite weighed down bouncing between all of those. Just my 2 cents.. happy to learn more about your proposal to split them up!

Currently I only a few contents in my projects, so I haven't feel weighed down yet. But using one global json file sounds better. Will work on it.

In order to make this as elegant as possible, if the --source flag is passed, 2 things should be done.
Ponzu should generate a comment at the first line of the content/X.go file:
the content/X.go file should be saved as content/X_gen.go (appending the _gen.go prefix). This makes it very clear that this file was generated.

Adding comment at first line is OK for me.

But not sure if it's necessary to differentiate file name when we generate using --source flag or not. It needs extra logic for file checking, should we check for both X.go and X_gen.go when user generating content?

IMO it might confuse the user as well if there are two different file can be generated.

Maybe anyone else have another thought about this @olliephillips @joshdstockdale