Would it be of interest to support multiple associations of single files to different models?
This library seems great for doing 1:1 associations but there are many cases where this might be not enough. For example, if you run a separate media library in your CMS and want your users to be able to associate those media assets to different models.
Currently the files get deleted when the model or the media association gets deleted.
Is there something on the roadmap to support multiple associations or is it of interest of anybody to implement it? If not I'll probably have a look at it - if you think it's a useful and wanted addition to the library.
+1
In this case I'd create an application specific media model, add the HasMedia trait to it, and ensure that only one file is associated with it. That model can then be in a one/many-to-many relationship with your applications models.
It sounds slightly hacky, but I think it would keep this library's code鈥攁nd more importantly api鈥攚ay cleaner achieving the same result.
Interested in hearing thoughts on what would be limiting / suboptimal about this solution.
@sebastiandedeyne Thanks, I'll try that.
+1 on the original question....
The solution suggested probably works fine, but we loose all the benefits of collections (simplicity of use, specific conversions, etc..)
However, I understand such feature would require a quite big refactoring of the package..
Can you(or someone else) elaborate on your solution @sebastiandedeyne? I'm struggling to find something that works.
Thanks! 馃檹
I'd be interested in having the ability to have a file in multiple collections. Basically giving the user the ability to "tag" a file.
+1 we love this library and it would be great to have this feature too
+1 馃憤
Most helpful comment
In this case I'd create an application specific media model, add the
HasMediatrait to it, and ensure that only one file is associated with it. That model can then be in a one/many-to-many relationship with your applications models.It sounds slightly hacky, but I think it would keep this library's code鈥攁nd more importantly api鈥攚ay cleaner achieving the same result.
Interested in hearing thoughts on what would be limiting / suboptimal about this solution.