Having worked with this, mostly from @smutek’s examples, for a couple weeks now, it seems to me that the best use of Blade’s additional functionality is to provide context for templates.
The rabbit hole goes as deep as you want, since it’s just php, but the goal (in my mind) should be to remove complexity rather than to add it in all cases.
So for instance, with Sage 9’s implementation of Blade, let’s say you use the thumbnail size featured image on your archive template, but the medium size on your single. With the right directive you could call the_post_thumbnail($AllTheRightArguments) on both templates and let your directive set up the context based on which template is being used. This simplifies the template file itself and centralizes the context creation so it can be updated easily.
This is a round about way of saying that the test should be “does this simplify things, or am I inventing complexity?”. I fail this test two out of three times but I’m trying to get better
This is very neat. Where are you guys putting your controller.php file? With the specific template file as outlined in the filter name? Are using one controller for each page or one controller to rule all pages?
Also doesn’t the PSR-4 spec recommend \<NamespaceName>(\<SubNamespaceNames>)*\<ClassName> format? I’m still learning PSR-4 so I was just curious to why you weren’t approaching it that way rather than stay valid with the spec requirements.
I plan on pulling the data from my theme options panel so the above is just an example. I don’t plan on actually hardcoding the values there such as my array of steps.
As far as the namespaces, I was a little curious about that too. I’m just sticking with App for now to make it uniform with how the rest of Sage is setup. Maybe one of the devs can chime in and clear that up.
These were done very quickly as an example and I’m sure could be improved on for real world usage.
Looking forward to seeing if anyone comes up with some other nice directives. I created an issue on the tracker about them at some point but the Sage dev’s wanted to keep their side of the things as clean as possible, but that doesn’t mean a plugin isn’t out of the question with adding some clean, well written directives to help make views even more pleasant.
By default, Sage is equipped with the @asset() directive to help link to various assets within’ your views. This is specifically useful for when using yarn run build:production as it will add cache busting to all of your filenames, so simply hardlinking them will cause them to break.
I’m sure this subject will be touched on significantly as Sage 9 gets out of beta and proper documentation is released.
Regarding the PSR-4 spec, I’m not entirely sure how the guts of this work but I think that this is being handled by the Laravel components. Note that the files in sage\src\lib\Sage all use fully qualified namespaces.
The “meat” of your application lives in the app directory. By default, this directory is namespaced under App and is autoloaded by Composer using the PSR-4 autoloading standard.
@Log1x - Hey, these directives are great . Thanks for sharing them! I’d tried putting some together a couple weeks back but wasn’t making much progress.
In their examples, simply replace Blade::directive with sage('blade')->compiler()->directive.
Also, I mentioned it in another thread, but thought I’d also include here that you can also share variables such as $GLOBALS to all of your blade views so you don’t have to call them manually.
and just like that, $options and $shortcodes are now available in your views.
<ul>
@foreach (array_keys($shortcodes) as $shortcode)
<li>[{{ $shortcode }}]</li>
@endforeach
</ul>
I found this especially useful when using an options framework such as Redux and them having all of the data stored in a global variable. It was obnoxious to have to global the variable every time I needed to use it. This is much more convenient.
This is really cool and like @Twansparant I’m seriously thinking of dumping Timber for a pure Blade setup in combination with directives and a data controller.
Is there a way to move the directives to a separate PHP file? I’m not sure how to reference the Sage compiler using the sage function in helpers.php. When adding directives.php to the array_map function in functions.php a fatal error occurs as Illuminate cannot find the sage.blade class. For some reason this isn’t the problem when adding the directives to setup.php.
I’m using the namespace and using it without the namespace (so \App\sage('blade')) throws the same error unfortunately. This is what my directives.php looks like currently.
The error is an uncaught ReflectionException: Uncaught exception 'ReflectionException' with message 'Class sage.blade does not exist' in /Path/to/web/app/themes/sage/vendor/illuminate/container/Container.php:749
I was messing with those imports as well (copy pasted the Blade ones from setup.php). Adding the following (or just the two you mentioned) doesn’t help, unfortunately:
use Roots\Sage\Config;
use Roots\Sage\Template\Blade;
use Roots\Sage\Template\BladeProvider;
Thanks for the help, it’s working now! I feel rather stupid, because after reviewing setup.php more closely I noticed that Blade is also referenced in the after_setup_theme action using the sage('blade') function.