mattstauffer / Torch

Examples of using each Illuminate component in non-Laravel applications
MIT License
1.84k stars 211 forks source link

Inherit Torch #142

Closed str closed 3 years ago

str commented 4 years ago

First of all, THANK YOU! I'm really impressed with your work. In the README you exactly described me

The imagined end user is a developer [...] copying the route closure directly into a project

And I was that imaginated user. I ended copy&pasting your code to be able to use Laravel in very old projects, that were build without any framework. I do a lot of code maintenance and migrating code to Eloquent, Blade, etc was only possible with Torch.

But copy&paste is not that great. So, instead of copy&pasting everything inside my MiratingTo\View::render(), I think it would be better to do something like

namespace MigratingTo;

// this way i can inherit all the code without copy&pasting it
class View extends \Torch\View
{
    protected function setPaths() 
    {
        $this->pathsToTemplates = ['my/views/'];
        $this->pathToCompiledTemplates = 'tmp/my/views/';
    }
}

// and in my legacy code I can just
$view = new \MigratingTo\View();
$view->render('some.view',['hello' => 'world]);

That way, if I install torch via composer, it will keep my code up to date with the latest changes, instead getting out of sync.

Again, thank you.

mattstauffer commented 4 years ago

That's a super interesting idea!

It seems to me you would need as many configuration options there as there are lines of code in the "newing up" code samples in Torch, and it would likely defeat the purpose.

However, maybe it's not about how easy it is in each application, but instead in each instance of an application?

I imagine that what you would do is run that pathsToTemplates code, etc. in your bootstrap of your application once, and then you could still use each instance as simply as you described there, right>?

str commented 4 years ago

It seems to me you would need as many configuration options there as there are lines of code in the "newing up" code samples in Torch, and it would likely defeat the purpose.

I haven't got through all the Torch packages, but I don't think you have to have a lot of setters. Also, in my implementation/subclass, I would just overwrite the setters that need to match my code. Step by step, I would try to adapt my code to match Torch defaults (see next paragraph)

it's not about how easy it is in each application, but instead in each instance of an application?

Exactly. I see the (abstract?) \Torch\View class defining the paths, probably matching Laravel's default paths, but you will always need to define your own class implementation to overwrite with your own paths. Then I will easily just instantiate my own implementation class in my legacy code.

The ultimate goal would be to migrate the legacy code to Torch, and then just to git mv my/views resources/views and finally just use plain Laravel. BUT until I get there, I'll have to use Torch.