NEW: DBField arguments, Enum, Composite support

[unclecheese]

Resolves

• GraphQL 4: DBMoney probably doesn't work #286
• GraphQL 4: DB Enums should implicitly become GraphQL enums #280
• GraphQL 4: DBField default args #275

Summary

This pull request adds three new plugins to better support DBField types.

Example

query ReadPage {
  readOnePage {
    content(format: FIRST_PARAGRAPH)
    introText(format: LIMIT_SENTENCES, limit: 5)
    lastEdited(format: NICE)
    publishDate(format: CUSTOM, customFormat: "YYYY")
  }
}

DBFieldArgsPlugin

• Adds a new format argument to DBField types that have formatting methods, e.g. FirstParagraph. (content(format: FIRST_PARAGRAPH) )
• When appropriate, a limit argument is added, e.g. content(format: LIMIT_SENTENCES, limit: 5)
• New format argument for date / time fields, e.g. lastEdited(format: DAY_OF_WEEK)
• All up, there are nine of these adapters (Text, Decimal, and Date ancestries)

DBFieldTypes plugin

• DBEnum creates a proper Enum type in the schema, and gets assigned to the field
• Composite fields, e.g. DBFile create proper object types in the schema and get assigned to the field

ScalarDBField plugin

• Ensure DBFields are always returned as scalars (no longer done in the default DataObject resolver. see below)

New low-level stuff

• Default DataObject resolver no longer normalises to scalars: The above changes required changing the default DataObject resolver to no longer return $dbField->getValue() (scalar) and rather leave the instance in tact so the other resolvers could act upon it (e.g. $obj->FirstParagraph()). There is now a plugin that runs at the end of the resolver stack that ensures if the object is DBField, it will run ->forTemplate() on it to extract its scalar value

• ModelField now accepts a metadata property. This may be a bit overkill, but we needed a place to store state on how the field was created, e.g. from introspection of a DBField. (->getMetadata()->get('dataClass')). As yet there are no other uses for this storage, but it's conceivable that other plugins or future features will want to add arbitrary state to fields.

• Schema config now has a parseShortcodes property as a global setting for DBHTMLText fields. (false in admin, true in default). This can also be set per field in myHTMLField(parseShortcodes: false)

• Type DBFile no longer exists. It's created by the DBFieldTypes plugin automatically as DBFileComposite

Docs

silverstripe/silverstripe-framework#10039

Relevant, but not necessarily dependent

• MINOR: Add parseShortcodes: false silverstripe-admin#1242 (adds shortcodes: false... won't break anything if merged ahead)

[unclecheese]

Failed build is due to a branch pushed to origin that was later deleted.

[emteknetnz]

Looking good

I don't have enough context to really challenge the approach taken here, so I'll just assume it's a great idea :-)

Allowing php formatting to be specified via a graphql query is certainly interesting. It does seem slightly wrong since usually that's supposed to happen client side, though I personally think it's a good convenience and it facilitates code reuse.

I've left some comments around some opportunities to tidy up the code