7.1.x Scaffolding Display Constraint Expansion

[codeconsole]

Modify display constraint so that

1. it can override blacklist behavior if set. (e.g. Date dateCreated currently will always not show up.
2. Can specify display behavior (input/output)

For instance, let's say you have String password you would want display: INPUT_ONLY For Date dateCreated, perhaps ideal configuration is display: OUTPUT_ONLY

class User {
    String password
    Date dateCreated
    Date lastUpdated

    static constraints {
        dateCreated display: OUTPUT_ONLY // show/index override
        lastUpdated display: ALL //  equivalent to a display: true  override
        password display: INPUT_ONLY // create/edit
    }
}

This is backwards compatible with display: boolean

[matrei]

Looks useful!

I find the DisplayType values a bit unintuitive. Suggestion:

DisplayType.ALL -> DisplayType.ALWAYS
DisplayType.NONE -> DisplayType.NEVER
DisplayType.INPUT_ONLY -> DisplayType.WRITE_ONLY
DisplayType.OUTPUT_ONLY -> DisplayType.READ_ONLY

[codeconsole]

Looks useful!

I find the DisplayType values a bit unintuitive. Suggestion:

DisplayType.ALL -> DisplayType.ALWAYS
DisplayType.NONE -> DisplayType.NEVER
DisplayType.INPUT_ONLY -> DisplayType.WRITE_ONLY
DisplayType.OUTPUT_ONLY -> DisplayType.READ_ONLY

There already is an editable constraint that controls whether a field is read-only in forms. READ_ONLY as a display type might be confused with that concept.

"input" and "output" directly correspond to the view types:

• Input views = create/edit forms (where users input data)
• Output views = show/index pages (where data is output to users)

Using WRITE_ONLY and READ_ONLY introduces a different mental model (database operations) that doesn't quite match what's happening. The scaffolding is about display in views, not about read/write permissions to the database. A property marked OUTPUT_ONLY can still be written to programmatically - it's just not shown in input forms.

I chose NONE because it is similar to display: 'none' is a css rule which is pretty common.

ALL or ALWAYS I am indifferent on and I guess if we went with ALWAYS, NEVER would make more sense.

[matrei]

There already is an editable constraint that controls whether a field is read-only in forms. READ_ONLY as a display type might be confused with that concept.

@codeconsole Yes, that's a valid point. I'm fine with the naming as it is.

[jdaugherty]

My only remaining concern is if this is a breaking change. If it is, we need to agree as a group that this is ok for a minor release since it will force all plugins to be recompiled again.