V4 Roadmap

[ragboyjr]

This going to be a list of features/changes I want to make for version 4.0.

• [x] Naming strategies
• [x] Revisit Extensions
• [x] Revisit Template Data
• [x] Re-architect sections
• [x] Slim feature set, Focus on extensions to provide features
• [x] Peridot for Tests (maybe)
• [x] Components (similar to laravel blade components)
  • Pass output buffered content as variable into sub template.
• [ ] come up with any more features...
• [ ] BC
• [ ] Integration Tests
• [ ] Unit Tests

Architecture Goals

• Every component should be able to replaced with a custom one
• Plates should do the simple case well, everything extra should be an extension.
• Keep the core as simple as possible, yet flexible to handle any abstraction
• Template files should be BC with 3.x. The Engine should also be BC for 3.x as much as possible. It might contain methods that are deprecated and only exist for BC reasons, we can remove in 4.1

[ragboyjr]

I'm open to any other suggestions as well. I'll update this list if anyone has any good ideas.

[ragboyjr]

Started v4 rewrite

• Need to finish hydration of template content/context
• Need to create a template context/builder object to manage the creation of the template objects

[ragboyjr]

Looks like i'm just about done with architecture for v4. I currently have an example in the example/v4 directory in the v4-dev branch showing what it currently supports.

I'm pretty happy with the architecture at this point, not sure if i'll need to make any major tweaks, but will just keep adding features.

[ipranjal]

We should be more inclined towards 7.0 support though we can add 5.6 to supported list all the other version have ended support an year ago , 7.0 is really fast in compared to other hence is is widely accepted

I have attached a graph to support my statement. This graph is based on logs from packagist, the heart of composer

[ragboyjr]

@physcocode check #160, we've already had this discussion in there.

[ragboyjr]

V4 is finally nearing completion. I think i've finally settled on the repo structure and will just be adding features/fixing bugs, but not much will change from here on out unless we discover something major.

I'd appreciate some feedback from the community about how the current feature set and the extension system works.

The current architecture is pretty simple; there are only a few key concepts: Templates, TemplateRefs, Extensions, RenderTemplates, and Composers.

Templates are now immutable value objects which is what allowed me to streamline the whole the repo because it made adding features very simple since most components can just work on templates. Templates only have a name, data, and attributes. Attributes are just an array of data for extending the data stored in a template.

Templates also now contain a reference to a parent template which enable parent child relationship trees which enable another set of awesome features.

Immutable templates however cause an issue when working with templates with relationships like the parent one because any updates to the parent template won't show up in the child template because the child has a reference to an old version of parent. To remedy this issue, I created the TemplateReference which is just an object that holds a template. Every template holds it's own reference, and every time a new version of the template is created, the reference is updated with new template. So all versions of a template share the same reference, and the reference always points to the latest version of a template.

RenderTemplate is the main interface for taking a template and returning rendered string content from that template. This interface is simple which allows for decoration and recursive rendering (see the LayoutRenderTemplate for an example). The top most RenderTemplate ComposeRenderTemplate enables composers which are just functions that take a template and return a template. This functions enable a wide host of extensions and features performed on templates. Most of the features like resolving the path, global data, merging parent data, Sections, RenderContext/Funcs are implemented via composers.

I haven't added much documentation except for code comments here and there, but the core code base is pretty small, and then each extension has some comments and is hopefully self-explanatory.

[ragboyjr]

I guess another core piece to this is the Container. Plates comes bundled with a small IoC container which allows the users and extension developers to customize any component they want and add rich extensions. This hopefully should be a familiar concept when building extensions because it works similar to how Laravel Service Providers or Symfony Bundles work.

[ragboyjr]

Now that alpha has been tagged for some time, if anyone has the opportunity to give v4-alpha for a spin, let me know how it goes or if anything is confusing etc..

[lkraav]

I know @justintadlock is working with it for the next starter theme project.

[lkraav]

@ragboyjr hi! 10 months later, what feedback have you received? Things seem a bit quiet, so either everything works much perfectly with 4.0.0-alpha or everybody is somewhere else?

[ragboyjr]

Not much! No one seems to be complaining or maybe just not using it lol. From my personal experience, the design made a lot of sense to me while I was in it and using it everyday, but when coming back to it after a few months of not using plates v4 (due to work and the types of projects i've been on), i think I want to do a bit of refactoring still yet and reduce the number of different parts to learn and maybe remove the Container dependency and just provide integrations with Laravel's and Symfony's DI systems.

Other than that, I think it works pretty great.

[ragboyjr]

I'm pulling the plug on V4. I don't think these improvements are really worth the indirection they add, and they also require a ton of implicit/indirect coding practices that make it difficult to have type safety and IDE help.

One thing that did come out of V4 was the desire for function components, that I think I've been able to figure out a general path forward for those. I'm going to be just implementing that system those into v3.