Why not extend? about stringbladecompiler HOT 6 CLOSED

Thanks for the suggestion.

I think it was just easier to mirror the factory class instead of extending the view\factory because of how laravel references function variables.

Extending the Illuminate\View\Factory causes these errors to pop up,

Declaration of Wpb\String_Blade_Compiler\Factory::callComposer() should be compatible with Illuminate\View\Factory::callComposer(Illuminate\View\View $view)

or

Declaration of Wpb\String_Blade_Compiler\Factory::setFinder() should be compatible with Illuminate\View\Factory::setFinder(Illuminate\View\ViewFinderInterface $finder)

This is almost endless, and I was not able to find a way to prevent it. So the solution was to clone the base factory classes and update the class 'expectations'.

I do admit there are several functions in the factory that are exact mirrors to the parent factory class, and it is a great idea to remove them, since they are not really needed. The other base classes could also likely the same duplication.

I think it is a great idea to remove the extra functions, so I'm currently testing how many can be removed. On my local copy I've reduced the Wpb\String_Blade_Compiler\Factory class from 890 lines to 386, not a bad improvement, but I want to test it thoroughly and make sure nothing decided to break.

Thanks for the push, it is something that will make the package code more lean.

from stringbladecompiler.

Hi,

Declaration of Wpb\String_Blade_Compiler\Factory::callComposer() should be compatible with Illuminate\View\Factory::callComposer(Illuminate\View\View $view)

Yes I hear what you're saying. What Taylor should have done (I've pointed this out a few times and will now start raising bug tickets because it's really poor coding style) is to declare an interface with the methods of Illuminate\View\View and then have the function take a parameter of that interface, then you can redeclare the function taking a parameter of that interface without any issues.

The easy workaround, in this case, is to have your callComposer function take a parameter of type Illuminate\View\View just like the parent function and have it called by your code (extending the factory code) with an object of class Wpb\String_Blade_Compiler\View. That will work because Wpb\String_Blade_Compiler\View is a subclass of Illuminate\View\View.

My quick look at the rest of the functions in Wpb\String_Blade_Compiler\Factory seems to indicate that you could do that for most of the functions you extend. Of course that's just a quick look, I'm not 100% certain it will work without diving in and hacking the code and it sounds like you're part way through that already so it would just cause a bunch of merge conflicts if I tried the same thing.

What I will continue with is making an extension of the necessary classes in Wpb\String_Blade_Compiler so that I can have a make() function that fetches a database object rather than an on-disk file. I think I can do that with just a few subclasses although, as always, the proof of the pudding is in the eating.

Thanks anyway for a head start. As I mentioned in my comments in the README file for viewpages, the lack of this functionality basically prevents anyone building a CMS on top of Laravel. CMSes don't typically store their page contents or templates in the programmer-access-only area of the web site, they typically run everything out of a database, cache, or similar.

from stringbladecompiler.

Well believe it or not, it actually worked.

https://github.com/delatbabel/viewpages

I managed it with only minimal extensions of your classes -- declaring child classes only when I needed to and extending in all cases -- using the functions you provided for everything that I didn't need to extend.

I have it working in a test app here but I don't have phpunit tests yet.

from stringbladecompiler.

Awesome! That is a nice small package (small being a good thing). I can see where it can be useful.

I agree with you on this, "..declare an interface with the methods of Illuminate\View\View and then have the function take a parameter of that interface, then you can redeclare the function taking a parameter of that interface without any issues..", it makes extending the base Laravel package a pain in the ....

On a slightly negative note, I've given up posting bug/suggestions to the Laravel project. I don't have the time to make a pull-request just perfect for the "project guard", just to have the "master" closed without any reason, just arbitrarily closed. I get everyone is busy but that just flips my dont-waste-my-time switch, grrr. Yep, still I think I'm still very jaded about how that went down.

On this project the code got a bit messy. I had it working when calling the view as a string, but when shifting to make sure the file template loaded, it started complaining about functions not being the same as the parent. So I'm starting over on that, I'll try to work in some more time later this week to really dig in to it.

Great work on your extension package, I really can see a valid use for it.

from stringbladecompiler.

OK well I might try doing a refactor on the 3.0 branch (because Laravel 5.1 is what I'm using) so that the package extends the Laravel classes rather than overwrites the functionality. That should make it portable up to new versions of Laravel a bit easier.

My other interest is integrating the functionality of something like this https://github.com/rcrowe/TwigBridge which would require being able to load a different blade compiler.

from stringbladecompiler.

Merged the submitted code modifications, so that closes this issue.

from stringbladecompiler.