Revisit how extensions work in Plates #134

Open
reinink opened this Issue Dec 24, 2016 · 5 comments

Projects

None yet

2 participants

@reinink
Member
reinink commented Dec 24, 2016 edited

Are they currently too limiting? Is there a better way to do this? For example, would macros (like what Laravel offers) be better here? They could be applied to both the engine and the template object.

@reinink reinink self-assigned this Dec 24, 2016
@reinink reinink added this to the 4.0 milestone Dec 24, 2016
@reinink reinink added the enhancement label Dec 24, 2016
@reinink
Member
reinink commented Dec 24, 2016

The macro approach would look like this:

Template::macro('uppercase', function ($string) {
    return strtoupper($var);
});

Since this closure would be scoped to the actual Template instance, it would have full access to all template variables, which includes the Engine. This gives a lot more flexibility while also keep things way simpler.

@ragboyjr
Contributor

@reinink how would they go about invoking the macro in the template?

@ragboyjr
Contributor

Another thing to possible consider along with this is...What if extensions worked similar to Symfony Bundles. Symfony is framework of tools wrapped around the HttpKernel, which can register bundles, and the Symfony Framework itself is just another bundle.

So, the engine holds the necessary interfaces for implementing the Plates system, A template renderer, a list of funcs/macros to be used within the template itself, maybe a naming strategy, group of folders and maybe a bit more. But by default, the engine can't do any of those things, and the extensions are used to define all of those specific parts. We'd then have a standard extension which would add/define the ability plates has right now. Then at this point, other extensions can be built to extend any core feature of the plates engine.

Another thing is that it would allow for easier testing/comparisons because you can have to extensions that implement the same feature but in a different way.

I think the smaller we keep the API, the easier the package will be to maintain, but if we can create a design that allows for very powerful extensions, then we can always just add another extension. It would allow some users who don't need a lot of features to have a slimmed down Templating system, and it would allow some users to have a very complex Templating system.

I have some more ideas on this, but just curious on how you feel about this design goal? No worries if it doesn't sound good to you :), just throwing it out there.

@reinink
Member
reinink commented Dec 26, 2016

@reinink how would they go about invoking the macro in the template?

Just like any other method on the Template object:

<?=$this->uppercase($title)?>

This is what's so awesome about macros. They give developers the ability to basically monkey patch an existing class without having to extend that class.

Your ideas around creating a bundling system for extensions is very much what I was going for with the existing design of extensions. However, I'm honestly not sure that we need such a sophisticated system. There are only so many things that a template engine needs to do. I think we can actually include many of these things baked in. Then for anything else, devs can easily add this new functionality with macros.

I think what I'll do next is create a "macro" branch to R&D this idea out. That will help us determine if this is a good idea or not. :feelsgood:

@ragboyjr
Contributor

Fair enough. So macros would be replacing the Func object correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment