feat: Models picker dialogs classes

[distantnative]

Description

#7522 for seeing the larger context how they should be used.

Merge first

• fix: ::pickerData() for models #7510

Changelog

🎉 Features

• New Kirby\Panel\Controller\Dialog\ModelsPickerDialogController classes (Kirby\Panel\Controller\Dialog\PagesPickerDialogController, Kirby\Panel\Controller\Dialog\FilesPickerDialogController, Kirby\Panel\Controller\Dialog\UsersPickerDialogController)

For review team

• Add changes & docs to release notes draft in Notion

[bastianallgeier]

I really like the refactoring. The props in the constructor make me wonder though if this is something that we should do for other controllers as well, where we often go directly through request params instead.

[distantnative]

@bastianallgeier I can't quite follow your thought - what is it what you are suggesting? 😅

[bastianallgeier]

@distantnative 😆 sorry for the confusion. Let's take the PageChangeTitleDialogController. It maybe not be the best example, but the first one I found where we use the request in the load method to get the 'preselect' prop. We normally mostly just pass the Model to the constructor and search for the model in the factory method of the controller. Additional options are then coming from the request object. Would it be better to set those options properties in the constructor as well and then hand them over from the request in the factory method instead?

[bastianallgeier]

But this discussion is basically not something that we have to decide for this PR. It's more a general conceptual decision that we can still leave open or change later.

[distantnative]

Now understood you. Yes, maybe in the long term they should already be passed to the constructor - I think we need to test out what works best for the most cases once we have done a bit more refactoring (e.g. #7466).