[Feature/Bug fix] Added the ability to separate base/crud assets more easily

[OwenMelbz]

Have added a new default layer of separation for crud specific css/js assets.

By default users have no way of easily customising the css/js of the CRUD level features

Additionally contributors have no way to make crud specific css/js fixes/features without effecting base.

This adds a series of files list, create, edit, form, revisions, show, reorder etc into the public directory that can be modified

[tabacitu]

@OwenMelbz, I've gotten used to the idea of providing these JS and CSS files, so I'm going to merge this into 3.2

One thing that's related to this and I would have loved: getting rid of the JS that is currently in the blade files, and move it to external .js files. Just look at all the JS that ended up in list.blade.php.

The thing is, that JS is in blade files for a reason: it's intertwined with PHP, a lot. I see two options to separate this JS, but I don't like either of them:

1. Make the .css and .js files actually .blade.php files that contain <style></style> and <script></script>. This would mean we store them inside /resources/views/backpack/crud/js and /resources/views/backpack/crud/css, which... doesn't feel right...
2. Keep the PHP conditionals inside list.blade.php and all other blade files, but just store the result inside some global JS variable (var crud). Then in the .js files, check for those variables and do js operations according to them. This would work pretty ok for most operations, but there are also things like using translation strings, which are bulky. In the end, this would still mean we have JS both in the .blade.php file and in the .js file, so why bother? It would probably end up even more complicated and bring in a flood of questions.

Do you see any other option? Do you like any of the above?

Thanks!

[OwenMelbz]

Yeah I know what you mean about the inlining of js, and even css there is a lot of.

I think the most acceptable reason is also the largest rewrite, it is pretty much what is outlined -> #148

But the concept would be to handle everything via data attributes, so json encoding it and passing it to the JS component which will then handle the logic, this could also work for translations.

However it is a large change, maybe a big ol refactor for 4 :D

So for maybe now, leaving them inline is the best choice

[tabacitu]

Pff... yeah, I agree. Thank you :-)

[tabacitu]

Merged into 3.2.
Thank you!