refactor: extract HasResourceNavigation trait from BuildoraResource (refs #135)#173
Merged
ginkelsoft-development merged 1 commit intoMay 12, 2026
Conversation
This was referenced May 12, 2026
Second decomposition step for #135, following the HasResourceActions trait. This one moves the four hooks that decide how a resource identifies itself and surfaces in navigation/global search: - title() — display label (defaults to model basename) - searchResultConfig() — global search label + columns - showInNavigation() — whether to render in the admin nav - slug() — URL slug and permission prefix All four were stand-alone overridable hooks on BuildoraResource: a consumer's CouponBuildora customises title() or searchResultConfig() without touching the rest of the resource surface. Pulling them into their own trait keeps that contract intact while taking ~25 lines out of the resource class. Behaviour is byte-identical: - title() still defaults to class_basename($this->modelClass) - searchResultConfig() returns the same default Dutch labels (kept on purpose — this is the package's built-in UserBuildora default, not a behaviour change to make here) - showInNavigation() still defaults to true - slug() still strips 'buildora' from the lowercased class basename Tests (7) cover both behaviour and structure: - title() derives from the model basename - showInNavigation() defaults true; subclass can opt out to false - slug() strips 'buildora' and lowercases (regression: route prefix and permission strings depend on this exact format) - searchResultConfig() shape is preserved (label + columns keys) - BuildoraResource uses the trait (reflection) - Source grep on both files: methods present in the trait, absent from BuildoraResource.php (re-inlining fails this test) Refs #135
ginkelsoft-development
force-pushed
the
refactor/extract-resource-navigation-trait
branch
from
May 12, 2026 13:13
ff52f86 to
8f18627
Compare
ginkelsoft-development
deleted the
refactor/extract-resource-navigation-trait
branch
May 12, 2026 13:13
ginkelsoft-development
added a commit
that referenced
this pull request
May 12, 2026
Fourth and final decomposition step for #135. After this, every overridable resource hook lives in a dedicated trait under Resources\Concerns and the BuildoraResource class itself shrinks from ~355 lines to ~150 — covering only constructor, state declarations, model resolution, panel relations, detail-view configuration and the abstract defineFields() contract. This PR moves four methods covering field state management into Resources\Concerns\HasResourceFields: - fill(Model) — populate every field's value/displayValue from a model - setFields(array) — replace the field collection with type validation - getFields() — read the field collection with the same defensive Field-type check - resolveFields($model) — re-prepare the fields for a specific model via FieldManager::prepare The abstract defineFields(): array contract stays on BuildoraResource. Abstract hooks declared via a trait are harder to discover (PHPStorm doesn't surface them as 'implement me' candidates when you extend the class), and the subclass-implementation contract is the resource's defining feature — it belongs on the resource itself. State access: the trait reads/writes $this->fields and $this->parentModel, both protected properties declared on BuildoraResource. PHP allows that without re-declaration in the trait. Tests (7): - getFields() returns the declared fields - fill() sets the value on the field from the model attribute - setFields() throws BuildoraException on non-Field entries - setFields() accepts a valid Field[] array - resolveFields($model) re-prepares fields for that model - BuildoraResource uses the trait (reflection) - Source-grep both files: methods present in the trait, absent from BuildoraResource.php. defineFields stays on the resource (abstract). After #172, #173, #174 and this PR are merged, #135 is closed. Refs #135
ginkelsoft-development
added a commit
that referenced
this pull request
May 12, 2026
Fourth and final decomposition step for #135. After this, every overridable resource hook lives in a dedicated trait under Resources\Concerns and the BuildoraResource class itself shrinks from ~355 lines to ~150 — covering only constructor, state declarations, model resolution, panel relations, detail-view configuration and the abstract defineFields() contract. This PR moves four methods covering field state management into Resources\Concerns\HasResourceFields: - fill(Model) — populate every field's value/displayValue from a model - setFields(array) — replace the field collection with type validation - getFields() — read the field collection with the same defensive Field-type check - resolveFields($model) — re-prepare the fields for a specific model via FieldManager::prepare The abstract defineFields(): array contract stays on BuildoraResource. Abstract hooks declared via a trait are harder to discover (PHPStorm doesn't surface them as 'implement me' candidates when you extend the class), and the subclass-implementation contract is the resource's defining feature — it belongs on the resource itself. State access: the trait reads/writes $this->fields and $this->parentModel, both protected properties declared on BuildoraResource. PHP allows that without re-declaration in the trait. Tests (7): - getFields() returns the declared fields - fill() sets the value on the field from the model attribute - setFields() throws BuildoraException on non-Field entries - setFields() accepts a valid Field[] array - resolveFields($model) re-prepares fields for that model - BuildoraResource uses the trait (reflection) - Source-grep both files: methods present in the trait, absent from BuildoraResource.php. defineFields stays on the resource (abstract). After #172, #173, #174 and this PR are merged, #135 is closed. Refs #135
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tweede decomposition stap voor #135
Volgt op PR #172 (HasResourceActions). Zelfde patroon: één geïsoleerde concern per PR, behoud subclass-override contract via traits.
Wijziging
src/Resources/Concerns/HasResourceNavigation.php(nieuw) bevat 4 methods:title()searchResultConfig()showInNavigation()slug()BuildoraResourcegebruikt nuuse HasResourceNavigation;. Ongeveer 25 regels weg uit de god-class.Behaviour is byte-identical:
title()blijftclass_basename(\$this->modelClass)searchResultConfig()blijft de Dutch UserBuildora-style defaults (bewust — niet een gedragsverandering nu)showInNavigation()blijfttrueslug()blijftstr_replace('buildora', '', strtolower(class_basename(static::class)))Tests — 7 tests, 17 asserties
Behavioural (5)
title()derives van model basenameshowInNavigation()defaultstruereturn falseslug()strips'buildora'correct (regression-belangrijk: routes en permissions hangen van dit format af)searchResultConfig()shape preserved (label + columns keys)Structural lock-in (2)
BuildoraResourceuses de trait (reflection)Voortgang #135
Na alle 4 PRs:
BuildoraResourcevan 355 regels naar ~150, met elke concern in eigen trait + dedicated tests.Refs #135