Ability to Extend Resource with Hooks?
I am reading through the documentation and I am trying to work out if it is possible to extend Resources with some form of Hook or Event.
For example I have one package that I want it to inject data into another package.
i.e.
Package 1 = UserResource
Package 2 = Address where we want to inject these fields into UserResource
I know how we can do it manually but was wondering if there are any Hooks built into Filament which can handle this?
10 Replies
Package 2 = Address where we want to inject these fields into UserResourceI don't understand that part.
Sorry what I mean by that is.
Currently in the old framework we are using we build everything as packages. We are looking to move to Filament but some client things change.
So for example we would have a base User Package. This has the Resource/Table/Form in it.
But Client A my want some extra data added into the User Resource/Table/Form.
As the Package is a generic one for all Clients. I was wondering if there is a way to hook into the Resource/Table/Form through Hooks/Events?
So under App I could do something like.
For Client A add geolocation fields for all Users. But Client B they will not see this field as its only done for Client A.
Sounds like feature flags to me.
Feature Flags in this instance could get quite dirty as you would put that in the User Module and we could have 50 different clients all with different needs.
In my old framework we basically used events to extend
i.e.
Event::listen('Tables.\Namespace\Folder\User', function ($columns) { $columns->push(....newcolumns...); }));
Then have that under the App directory it will extend the User package and add the new Columns.
So was more wondering if something like that is possible. If not I can always build my own approach to it.
How would an event affect the current request though. Doesn’t make sense to me.
Sorry not sure what you mean by Request.
Basically it is just a way to dynamically inject table columns/form fields from a seperate package. To extend the first packages functionality.
So we previously used events too hook into columns where we could add more columns for specific tables when rendered.
Right but events are meant for offloading functionality, not for determining the outcome of the current request.
Events don’t make sense to determine what is shown when someone requests a view with a table.
The columns show on the table shouldn’t depend on an event / listener lifecycle
I could just be misunderstanding the use case though.
Events is just how it was done in a framework that is 10+ years old and would not be the approach I would go for now.
Basically the simplest example that happens quite a lot is.
1. We have a User package that lists Users where you can edit/created. (This is a vendor package)
2. Client A would like to have a new field injected into the User Package called company. (This is under App)
3. Is there a way to somehow inject a new column or do you kind of need to move the UsersResource/Table/Form into App to add this additional field.
The reason I ask is that usually we use 99% of a package functionality but in some cases a client wants to have a slightly different feature.
Contact Forms are another big one. All clients may slightly want to change the fields in a Contact form to ask additional data.
I could easily enough build this into the system myself but more wondering if there is any first part approach on how to extend current Resources.
I would say that if it’s a package then you should use any leverage they give you, ie extending the model class etc. but if that is not possible then you need to make a decision to work within their restrictions or go your own way.
Why not move the schema to a static method
getFormSchema() and then you can do: