Open johnpuddephatt opened 1 year ago
That definitely sounds a lot cleaner than what we have now. I would definitely be interested in a PR.
Cool I'll create a PR when I get chance, then you can take a proper look!
I did the same thing as well. Though, mine has a bit more logic with a structure having a contract and an abstract.
Contract preview:
interface SettingsPage
{
public function name(): string;
public function options(): array;
public function casts(): array;
public function fields(): array;
public function defaultValues(): array;
public function guarded(): array;
public function slug(): string;
public function authorize(Request $request): bool;
}
Also, it has support for whitecube flexible package and feature to sync the settings with the environment file by implementing a contract SyncWithEnv
.
@johnpuddephatt if you want to, we could do a merge and pick only the best features from each?
These additions do sound sweet. I'll be waiting for a PR. :)
This isn't a problem, more of a suggestion, but talked through rather than jumping to the answer because I don't have the confidence to know if what I'm proposing is good!
I've noticed that having a lot of settings (fields and/or pages) results in a messy NovaServiceProvider file.
Currently in my projects I'm doing the following:
This works well enough, but I wonder if there could/should be a new method added to NovaSettings, perhaps "addSettingsPages()" to simplify the above to:
The new method would be pretty simple, e.g.
This would certainly keep NovaServiceProvider a lot tidier. But I then started thinking that maybe we don't need to call addSettingsPages manually? Couldn't our pages be passed to the Tool directly when it's being instantiated? e.g.
To make this work just requires a constructor on NovaSettings:
Happy to create a PR if this sounds of interest, but if you have feedback or suggestions for a better approach let me know.