Bashing my head against using morphTo in a RelationManager. HELP!
Hi everyone,
I am writing an app to automate the setup and configuration of websites, and I am trying to make it technology agnostic, so I am creating a lot of base classes to represent the core concept (e.g Repository), and then classes that inherit from them to represent the actual technology in use, e.g. Repository_Github or Repository_Bitbucket
To represent these relationships, I am using a morphTo on the Repository, and a morphOne on Repository_Github. Bar Eloquent offering real inheritance, this model seems ok for now.
The problem comes when I try and use a RepositoryRelationManager on the parent Project page. I have been fighting against it for an entire week, the RM just DOES NOT WANT to create / edit / resolve / basically anything with a morphTo relationship without serious hacking to get it to work.
This has actually been a really good introduction to Filament for me, because I've gotten so deep into the guts trying to get this stuff to work, I feel like I'm getting fairly adept at it, but I have also realised, if I am bashing my head against it this hard, I am clearly doing something fundamentally wrong.
So, can anyone help? What should I be doing other than using morphTo / RMs? Have I just chosen the wrong architecture? I don't need this inheritance model, but I do want the flexibility for a user to e.g create a Repository from a single form, and have all sorts of different fields and underlying methods based on the type of repo involved. It just feels like the app is pushing me towards dumping it all in a single table, and that feels really bad to me.
3 Replies
Does it work outside of an RM? Like, can you build a Repository resource, and list / edit / create on that?
If I create completely custom scaffolding for all of it, then yes - the issue of course is that you can't create a Repository until you've created the Repository_Github record (because you need the ID for the Github to store in the Repository record), so the Create, Edit and List actions all need customising, and no doubt I am going to run into other issues as well down the line, with search / sorting / etc.
This is why I'm asking the broader question, which is whether the architecture I'm using is even appropriate. Are there better relationships I should be using? Should I dump relationships entirely, use Traits for inheritance, and just write custom queries for everything? I guess what I'm trying to do here is to work WITH the framework - I got more done yesterday by just writing an InfoList and some big dumb Actions that just brute force what I want them to than I did in almost a week of fighting against RMs.
As an aside, I found this blog post: https://flareapp.io/blog/67-building-a-flexible-yet-abstract-external-integrations-structure - it's scary how much it is actually talking about exactly the type of model I'm trying to create. Definitely some really useful stuff to work with in here, but it is only really talking about the model, and not the Forms and Tables used to actually access this stuff, which is where I am struggling so much with RMs.
Flare
Building a flexible yet abstract external integrations Structure - ...
We created a new structure for external integrations like GitHub and Jira which allows us to add these kinds of integrations a lot quicker.
I got really excited when i saw MorphToSelect - it wouldn't have been a perfect solution, the UX isn't exactly ideal, but it would have allowed the user to add a new record right there and then, and it would all be linked and the relationship would work magically! Until I discovered that the MorphToSelect doesn't support the Create functionality :(((((