I try to find a way to add some generic functionalities AND the corresponding fields to existing models in different plugins.
So, here’re some examples:
I have some kind of “featured” functionality which I would like to add to multiple models as a behaviour. But with this behaviour, I would also need several new fields in the table of the model.
I also have build up a certain tag fuctionality which is used on several models. So basically all the basic tag functions are the same, just depending on the model, some additional fields are added.
So I wonder:
I watched the serious about extending the user plugin, but with this method, I extend ONE certain table of ONE other plugin. My behaviour should work for multiple plugins / models.
Then I had a closer look at behaviours which seemed to fit a lot better for my kind of functionality, but I didnt find a good way to implement the migration.
An even better way would to build up a “generic” model in some kind of utils plugin for the tags, and when I would like to use this, I extend the generic model to my tag model.
I hope to get a few ideas for a raw concept of how I can achieve this best.
I guess it’ll be a behaviour and in some way I have to add the migration file to the behaviour.
Or is there a better way?
Thanks for your help ^^
I think this is a case for a morph relations and a plugin, that can store those relations, so you won’t have to do migrations on “foreign” models.
Imho, most of the difficulty depends on what you want to do with the “additional fields depending on the model”.
You should look into the TranslatableModel behavior of Rainlabs Translate Plugin as a source for inspiration. The additional fields per model could be a “simple” JSON field with key-value data, which can be edited with a nestedform or a custom field widget. But this depends on what you want to do with those fields later on.
1 Like
Thanks for this first idea!
I had a closer look into morph relations and the Translateable plugin. Indeed that approach would work for the the models, but since I also do some queries on some of those additional fields, it wouldnt be a good idea to store them in one json.
A second problem is, that I would store all the data in one table. Since it’s quite a large website, I would prefer to seperate this multiple tables instead of having the data for multiple models mixed in one table.
I thought of adding this stuff through behaviour but adding the fields directly in the model. Might not be a 100% save way, since I might forgot to add the fields in my models migration file, but since this wont be public anyways only I have to ensure this.
So, further ideas still welcome, I appreciate all of them. Thanks a lot ^^
Thanks for the feedback!
I’m also toying around with something like that (basically an unknown amount and unknown types of fields, that should be available for the standard OCMS processes like exporting etc.) and another thing that I’ve had in mind, was using Rainlabs Plugin Builder to add fields to models and everything.
And yet another approach I thought about, was identifying exactly what I would need to do with those fields, prepare everything with events and create some kind of “RegisterField” class, that takes some form of yaml configuration and listens to the various events (like form extension events, import/export events etc.) and injects the fields and it’s data.
And then yet another approach i keep in mind is some kind of git tomfoolery with source control forks or branches. Mostly because I have a similar set up like you: internal plugins, that have highly custom fields, but the fields won’t be changed much after the initial setup. But I’d rather deal with lot’s of coding than git woes 
I would be interested to know with what approach you’ll go ahead.
2 Likes