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.

[jdaugherty]

So to date, everything has been an optional / minor breaking change. But changing constrained means that this will be a breaking change, no? @matrei what are your thoughts on this?

[codeconsole]

@jdaugherty is adding a constraint breaking?

[jdaugherty]

Adding the constraint isn't, but changing the base interface that's applied to every object I assume would be breaking. We need to test this.

[jdaugherty]

@sbglasius is going to test this change with his side project to ensure it's backwards compatible.

[matrei]

Yes, we should test this, we don't want to have to recompile/re-release plugins for 7.1 compatibility.

[jdaugherty]

The library being changed here doesn't have anything to do with scaffolding. Wouldn't it be better to introduce a constraint specific to scaffolding?

The more I think about this this seems very view-centric and it's being added to the domain layer. This just feels wrong from a separation perspective.

[codeconsole]

@jdaugherty I am just expanding on the existing constraint which currently supports true/false and actually fixing it for when true is set. it can now be a boolean or an enum value.

[jdaugherty]

The property is being used by fields, but documented as a scaffolding constraint?

[codeconsole]

@jdaugherty That's how the documentation has always read, no?

[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.