Few ideas

[crackcomm]

I've got few ideas, I'm not sure I will be able to work on them but I'll write them here.

• Slug fields (eq. artist + title)
• Super-types (eq. URL), definable in addons
• Field validators (eq. email, URL), definable in addons
  • Go to JS (in browser validation)
• Admin table fields (eq. --table-fields title,artist)
• Admin search fields (eq. --search-fields title,artist)
• Admin hidden fields
• Swappable database backend
• Model descriptors
• GraphQL endpoint (dreams)
• Users management with ACL (eq. hydra, dex)

I would love to hear your opinions on them, especially the last one.

[nilslice]

Hi @crackcomm - I have not had a lot of time to go through all of these with much thought yet, but fully intend to. Thanks for the ideas!

[nilslice]

@crackcomm - I think some of these might already be in Ponzu, but undocumented.. others I'm not sure I fully understand and need some more information. Let me know what you think.

Slug fields (eq. artist + title)

I could be mistaken about what you refer to as a 'slug', but there is an interface in the system/item package called Sluggable which lets you override how the URL slug is set. It's better to implement the Stringer interface on your content to do this though as it will lead to more reliable and consistent results. See https://godoc.org/github.com/ponzu-cms/ponzu/system/item#Sluggable

Super-types (eq. URL), definable in addons

Would this be used as a editor.Field like the ones in http://github.com/bosssauce/reference?

Field validators (eq. email, URL), definable in addons

I agree that there should be a good validation package made for Ponzu that would allow you to do something like the following in your content type, which would implement an interface with a Validate method so I could add the Validate() call before all possible DB saves:

func (a *Applicant) Validate(res http.ResponseWriter, req *http.Request) error {
	requires := map[string]string{
		"username":    "exists|unique",
		"email":       "exists|unique|email",
		"password":    "exists|minLength:8",
		"age":         "exists|int|gte:18",
		"birth_month": "exists|int|in:0-11",
	}

	return validator.Check(req, requires)
}

Go to JS (in browser validation)

Using the interface-based approach above, I think this could be accomplished with another generator. Good idea. Would expand on my roadmap to write generators for API clients in JS, Obj-C/Swift, Java, PHP, etc..

Admin table fields (eq. --table-fields title,artist)

Sorry, I'm not sure what this one means

Admin search fields (eq. --search-fields title,artist)

Admin search is already present, but its limited to exact-matching text per content type. There is some discussion happening in #51, which would be great to get more ideas going.. maybe I don't fully understand what you mean though.

Admin hidden fields

I have an item.Omittable interface in a local branch which I will push shortly. It works just like item.Pushable which expects a []string containing the fields to push, except in this case it omits those fields from Content API responses.

Swappable database backend

This is also something folks have been discussing a bit in the Gopher's #ponzu slack channel.. I wouldn't be the right person to accomplish this, but I agree it could be a nice feature.

Model descriptors

Sorry, I'm not sure what this one means

GraphQL endpoint (dreams)

I have some thoughts on this, and why we don't need it with HTTP/2 and PUSH_PROMISE frames... I think GraphQL is awesome, but when HTTP calls are even cheaper and keep the same TCP connection open, I think the need for fetching data in the GraphQL way is going to be obsolete, unless you are forced to use a SQL database and can't leverage HTTP/2 as much.

Users management with ACL (eq. hydra, dex)

Totally unfamiliar with these, but would like to know how you want to use them.

[stereobooster]

I have some thoughts on this, and why we don't need it with HTTP/2 and PUSH_PROMISE frames... I think GraphQL is awesome, but when HTTP calls are even cheaper and keep the same TCP connection open, I think the need for fetching data in the GraphQL way is going to be obsolete, unless you are forced to use a SQL database and can't leverage HTTP/2 as much.

It is not just economy on http requests. This is the small part of what GraphQL about.

• This is also a scheme of a data and functions - think of it as grpc scheme.
• Plus it has declarative language to read data - think of it like SQL.
• It is agnostic to encoding - so you can switch from JSON to msgpack.
• There are tons of frontend libraries that support graphql and will help to build based on it, like relay, apollo etc.

There is also this DB https://docs.dgraph.io/query-language/ which support GraphQL-like syntax out of the box. And this example of what nice tools you get out of the box with GraphQL https://github.com/graphql/graphiql. And more to come https://dev-blog.apollodata.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07

[olliephillips]

Closing this issue. No activity and old. Please reopen if need to.