Nova Resource Manager Laravel Package

Getting Started

This package is a form-rendering layer for Laravel that can be embedded inside relationship UIs (BelongsTo / HasMany / ManyToMany contexts). Version 0.4.2 is a patch release: it fixes an error thrown when a form is displayed inside a relationship. There are no breaking changes, no new features, and no deprecations, so existing integrations should upgrade without code changes.

Minimal steps:

1. composer require <vendor>/<package> (or bump to ^0.4.2 if already installed) and run composer update <vendor>/<package> --with-dependencies.
2. Publish assets/config if you haven't already: php artisan vendor:publish --provider="<Vendor>\\<Package>\\<Package>ServiceProvider".
3. Define a form class (fields, validation rules, layout) and render it standalone first — a plain route or a Blade include — before wiring it into a relationship view. This isolates form-level problems from relationship-level problems.
4. First real use case: a parent resource (e.g. Order) with a related model (Customer) where the form should render inline on the parent's create/edit screen instead of on a separate page.

Where to look first: the package's relationship field/adapter class and its tests covering relationship rendering. The 0.4.2 fix lives in that area, so those tests are the best documentation of the intended contract (what the relationship context is expected to pass into the form: the parent instance, the related model, the owning key, and the field name).

Implementation Patterns

Render the same form in two contexts. Define the form once and let the package resolve context (standalone vs. relationship). Keep the form class free of assumptions about request()->route() or the presence of a parent model — read the parent from the injected context object, not from the container. This is what makes the 0.4.2 relationship path work reliably.

Pre-populate the related model before rendering. When displaying a form for a relationship, bind an actual (possibly unsaved) related model instance so field defaults, old() repopulation, and validation errors have somewhere to live. Pattern:

$parent = Order::findOrFail($id);
$child  = $parent->customer ?? $parent->customer()->make();

return view('orders.edit', [
    'order' => $parent,
    'customerForm' => CustomerForm::make()->model($child),
]);

Save through the relationship, not the form. Let the form handle validation and hydration, then persist via $parent->customer()->save($data) / associate() / sync() so foreign keys and pivot rows are set by Eloquent. Avoid mass-assigning the foreign key from form input.

Reuse for nested create flows. The common workflow is: parent edit screen → "add new related record" → form renders inline → submit creates and attaches in one request. Wrap the persist step in DB::transaction() so a validation failure or attachment error doesn't leave an orphaned child row.

Authorize at the boundary. The form knows about fields; it should not know about policies. Gate the relationship field/component ($this->authorize('update', $parent)) before rendering, and re-gate on submit — relationship forms are frequently reachable by direct request to the field's endpoint.

Conditional fields driven by parent state. Where a related field should only appear for certain parent statuses, compute that in the form's visible/rules callback from the bound parent model rather than in the Blade template, so server-side validation and client-side rendering agree.

Testing. Feature-test the relationship path explicitly: create a parent, GET the edit screen, assert the form fields render (this is the exact scenario 0.4.2 repairs), POST valid and invalid payloads, assert the related record exists and is attached. Add one test with the relationship empty and one with it populated — the display error fixed in 0.4.2 is typically one of those two branches.

Gotchas and Tips

• Upgrade to 0.4.2 opportunistically. If you render forms in relationship fields on 0.4.x, you are likely hitting this bug or are one code path away from it. Nothing in the changelog implies behavior changes, so bump the constraint and re-run your relationship feature tests rather than treating it as a risky upgrade.
• Version constraint: pin ^0.4.2 if you depend on relationship rendering; earlier 0.4.x patches will still throw. In a pre-1.0 package, keep the minor pinned (0.4.*) and read each changelog — patch releases can still contain fixes that change rendered output.
• Empty relationship is the classic failure mode. When no related record exists, there is no model to bind. Always pass an unsaved instance ($parent->relation()->make()) instead of null; a null model is the most common cause of "error when displaying form in relationship" class bugs, both in this package and in your own wrappers.
• Foreign key leakage. If the related form includes the FK column, relationship saving can overwrite it. Explicitly exclude the owning key from the form's fillable/validated fields.
• old() and error bags. Relationship forms nested in a parent page share the session error bag. Use distinct bag names / field name prefixes per relationship field, or a validation error on the child will render next to the wrong input.
• Eager loading. The form's default resolution often touches the related model's attributes. Model::with('relation') on the parent index/edit query prevents an N+1 per rendered form — easy to miss because the form, not your code, triggers the load.
• Debugging the display path: dump the resolved context (parent model, related model class, field name) from the relationship adapter before the form builds. Most rendering errors here are a wrong or missing bound model, not a view problem.
• Extension points: prefer the package's field/component extension hooks over overriding Blade views. Subclassing the relationship field and overriding the context-resolution method is the durable customization point; published-view overrides will break on the next patch.