Addons: They need a Design time interface so they can support getting involved in the generation of the Content Types.

[joeblew99]

Please let me know if i am misunderstanding something here.

I played with this example:
https://github.com/nilslice/gotv-example

From this examples, we can see that the content types need to know about each other, and so thats why the Reference Addon exists.
But you cant generate it yet , because the code requires they know about each other at Generate / Design time.

The main thing is to add the ability for Addons to support GenerateTime interface i feel.

What do you think ?

[nilslice]

Hi @joeblew99 -

I definitely see the use-case, and think it is an interesting idea. I'd love to see a very basic example of what you think the code would look like within an Addon, and where it would need to be accessed from the content generator.

With the Reference addon in mind, the generate-aware aspect would need to make some decisions about how to tie the two content types together. For example, would the GenerateTime interface have the ability to set the tmplString param in a reference.Select? I'm not sure how we'd define the process used to make that decision.

If it doesn't make those decisions, would it just output code that is meant to be deleted and replaced?

There have been some other points brought up about code gen in Ponzu, and we have added one to the roadmap, which you can see here: https://github.com/ponzu-cms/ponzu/projects/2#card-1540549

Maybe there is a way to integrate your idea into that feature?

[joeblew99]

@nilslice

Thanks for adding the card. i think that sums it up well.
i dont really want to add more to that card for fear of scope creep. Just being able to do that is a good stepping stone and useful to me and others i think already.

Regarding the problem of the "Reference Select" at runtime. I am not sure myself and this is a common problem with code generators. First we would need to establish that its up to the developer to override that function. In golang we can use embedding (https://golang.org/doc/effective_go.html#embedding). The developer then just has to reference a new type that does the "Reference Select". I feel confident that this woudl also set things up for extensibility. Also this embedding approach is what goa uses, which makes me more confident it would work. We could use a IOC pattern (aka dependency injection) but i feel thats a bad pattern because it leads to compile time checking not being robust and more complexity for the developer cognitively.

Regarding your request for example code. I think its more useful to talk about how it could work because there are many options.
Basically, you need to knwo what types in already present, so that you can reference them.
At Design time, nothing is running, so the best way i think is to use AST, and parse the types already there as code itself. I like this approach because its flexible and is a design by contract pattern.

Once that base is in it opens up many extensibility aspects. One that i see is that in the future, a developer may want to use ponzu to act as a CMS on top of larger systems. One example of this is 3 micro services with a gateway fronting them written in golang. With ponzu, you can reference types expressed in the gateway. This is super cool because its gives you the ability to use Ponzu as a content inspector and editor of bigger systems. Many projects could benefit from this.

Ponzu's core principle is that its a design time tool, not runtime like other CMS systems. My above design explanation stays close to that principle. I feel its important to point this out.

[olliephillips]

Closing this issue. There has been no activity in some time. Please reopen if need to.