search

igaster / laravel-theme

Theme support for Laravel
MIT License
520 stars 113 forks source link

Anyone get this working with view composers for each theme? (overlapping view names) #128

Open michaelsoutherton opened 4 years ago

michaelsoutherton commented 4 years ago

We're trying to use multiple view composers along with this package to help clean up our controllers. The problem is that we can't figure out how to conditionally load only the view composer we want when some of our view names are exactly the same.

Here's a couple different homepages for platforms that each need very different data:

/resources/themes/platform-one-theme/pages/index.blade.php /resources/themes/platform-two-theme/pages/index.blade.php

The view name for each of those homepages is 'pages.index'

So in our ComposerServiceProvider.php, we have:

View::composer(['pages.index'], 'App\Http\ViewComposers\Platform-One-ViewComposer');
View::composer(['pages.index'], 'App\Http\ViewComposers\Platform-Two-ViewComposer');

...and our problem is that both of those will both be loaded. How can we conditionally apply only the view composer for our theme? It looks like we don't have access to request within ComposerServiceProvider, and it doesn't seem to work with middleware.

sebsobseb commented 3 years ago

@michaelsoutherton did you found anything? I'm having the same 'problem'..

michaelsoutherton commented 3 years ago

@michaelsoutherton did you found anything? I'm having the same 'problem'..

Not really. One of our workarounds is currently to append the platform name in the view file, e.g. pages.index-platform1 and pages.index-platform2 and then just create a separate view composers for each index view.

Those examples are homepage views for our different platforms, but a different example would be a 'news' page (similar to a blog archive page). All three of our platforms have a 'news' view. And as you can imagine, they share a lot of the same data (get all the news posts), but they also have their own unique data specific to their platform. What we ended up doing here was using the same view name pages.news.index, adding data for this view in a generic view composer, and then passing $platform (which is based on a key in our route array) along with it and determining what data to add to it in a switch($platform) statement.

Not sure if there's a better way, but that's what we're doing.