Feature: Handler priority
MGatner opened this issue · 4 comments
There should be some meaningful way to specify handler priority, aside from "whichever comes first in Settings Config". Probably the way to do this is add a priority field to the handler arrays - this way if a module uses a Registrar to tack on a handler it can make it the "preferred" version.
Addendum: it might be good to allow some way of specifying a handler(s) to use for a single call.
I think for now this is a solution looking for a need. At least in the way I picture it being used, it's kind of a set-and-forget thing when you're building the app. If it needs to change, a change to the app is in order. I don't think this is going to be something used all that dynamically. I might be wrong, but if so I'd like to hear from users that they have a need before adding this bit of complexity.
So, honestly, the idea of a pipeline that is very simply ordered by the list of handlers and doesn't need another setting appeals to me. I'll be happy to revisit in the future, but don't think it's needed for a 1.0 release.
Honestly, this is a personal request. I'm not interested in maintaining Tatter\Settings alongside an official version with 90% overlap. The 10% is mostly "per-user settings", which I don't think is in the scope of this library but probably accounts for the majority of my library's use.
When I was thinking about how I would extend this library to accomplish that, I decided the best way would be a User Handler that is injected via Registrar. The only catch being that it would need priority over the regular Database Handler, hence the request.
If that doesn't change your opinion then I'm sure there are other ways I could accomplish this.
Actually - it works fine for per user settings since the config class doesn't have to exist for it to work, just requires some creative naming for keys, like adding the user id to the setting key.
But if that doesn't work, I'm ok with this being added. Like I said - I personally didn't see a use at the time, but now see that it could help. If you want to add that - go for it.
I think this would still be worth it. I will think of other ways around, but the workflow otherwise fits this library nicely. Example:
Your project has multiple themes and users can change their theme. app/Config/Project.php includes $theme (which will be the "default") and the layout includes something like <link href="public/assets/<?= setting('Project.theme') ?>">. Obviously our User Account controller cannot just setting('Project.theme', $selectedTheme) or this will change it for everyone.
The UserSpecificHandler needs to do the same thing as DatabaseHandler but reference a different table with a user_id field, then fall through to the regular handler, then finally use the Config value. I hope that makes more sense.