blueprint
                                
                                 blueprint copied to clipboard
                                
                                    blueprint copied to clipboard
                            
                            
                            
                        Nested Resources
Synopsis:
The ability to generate nested resources for other models/controllers. For example:
A job can have many comments, but a course could also have many comments, and they would use a Comment model, with a commentable morph (which we can do already), now to comment on a job with Laravel you can do:
web.php
Route::resource('job.comment', JobCommentController::class);
JobCommentController.php
class JobCommentController extends Controller
{
    /**
     * Store a newly created resource in storage.
     *
     * @param \Illuminate\Http\Request $request
     * @param \App\Models\Job $job
     * @param \App\Models\Comment $comment
     * @return \Illuminate\Http\Response
     */
    public function store(CommentRequest $request, Job $job, Comment $comment)
    {
        $comment = $job->comments()->create(array_merge([
            'owner_type' => 'user',
            'owner_id' => Auth::user()->id
        ], $request->validated()));
        return Redirect::back()->withSuccess('You have added a comment to this job');
    }
}
Currently we don't have a way to do this. Would this be something you're open to?
Proposed Syntax:
    # Job Comment Controller
    Job/JobComment:
        resource: store, destroy
        model: job
        nested: comment
        validation: comment/comment
So, the model is the resource model It is nested for, and nested is the model it uses to store/delete data, the validation is the file It generates for validation. Because the comment is used for multiple resources, it doesn't make sense to add that under the Requests/Job/ folder but the nested model's own folder, so you could use CommentStoreValidation for both Jobs and courses or whatever other model can be commented on.
Would this syntax be less clutter? We could still derive the JobCommentController name and we can treat each segment as a model without the user having to specify the model and nested properties since the / should already indicate the nesting.
Job/Comment:
  resource: store, destroy
  validation: comment/comment
I'm not following this very closely. However, I agree we could infer some things by default. But we should allow the proposed syntax in the event they are not following conventions.
Also, the model, nested, and validation should be meta properties. Only resource and meta should be top level.
@jasonmccreary I experimented with this in https://github.com/faustbrian/blueprint/commit/047c0a8fa6281c9da1888830ead9e823373e757e. The main challenge is statement generation, as most classes rely on the controller name. For nested controllers, we need to adjust the return values of Controller::name and Controller::prefix to avoid issues.
For instance, variables should be named $comment instead of $jobComment. However, these are deeply integrated into the system, making it a significant change. One solution could be creating ResourceControllerGenerator and NestedResourceControllerGenerator classes, with ControllerGenerator invoking them based on the controller name. This would minimize surface-level changes and accommodate differences between resource and nested resource controllers.
However, statement generation would still have some challenges, such as modifying independent classes like EloquentStatement to generate statements like $job->comments()->create(...) instead of Comment::create(...). A possible workaround could be using a boolean flag for requesting nested statements.