DomTemplate
DomTemplate copied to clipboard
PhpGt
A more complex example of usage
Hi,
DomTemplate seems like the perfect match for a project I have in mind, but I couldn't find a more complex example to follow – which would really help me decide if I should follow the vanilla DOMDocument path or not.
For example, how would the DomTemplate approach be compared in practice to the one used in this CSS Tricks article, where all HTML markup was created using createElement or setAttribute?
I understand that we would completely separate all HTML markup in its own file and change the output using DomTemplate's methods, but it would be useful to see how it would be done with real code. Thank you.
Hey @pagelab ,
Firstly, thank you for the message. It's great to hear that there's some interest in the repository.
I've gone ahead and written some more detail to the README. Please check it out, I hope it helps you understand usage a bit better. I will be writing full documentation soon, but hopefully this will help in the meantime. If you would like me to make an example that's more inline with the CSS Tricks article, I'll try and get something together for you, but hopefully the current simple examples will allow you to explore the functionality.
For a bit of context, and the reason why the documentation is sparse at the moment, this concept was originally built as part of an in-house framework but has been split into the separate repositories over the last couple of years. The framework is getting ready for its v4 release which marks the point where all of the separate areas of concern, like DomTemplate, are all truly separate, and is being made fit for public consumption (rather than just in-house - lots of documentation to write!).
I would really like to get this repository, and the others within PHP.Gt, easy to understand and pick up. At the moment, most repositories are only useful to people who already know how to use it, which mainly includes people who I personally work with. It would mean so much to me if I could keep in contact with you while I write the documentation and build the website for these repositories so I can learn what questions and needs you have, and even if the repository isn't right for you, it might help others in the future pick it up.
Let me know what you think about the first few examples I've added to the readme, and if you'd like to see anything more specific I'll add these to the documentation planning.
Thanks again, Greg.
Thanks for the new examples, @g105b, they cleared up some things I didn't understand at first.
If you would like me to make an example that's more inline with the CSS Tricks article, I'll try and get something together for you.
It would be really useful, thank you for being available.
That CSS Tricks article is exactly my use case (getting data from an API and use a template to generate dynamic output with it). It's probably a common use case in general.
There are some peculiarities of that approach that weren't directly addressed in your new examples, so I can post them here after exploring a bit more.
It would mean so much to me if I could keep in contact with you while I write the documentation and build the website for these repositories so I can learn what questions and needs you have.
Sure thing! I'm currently building something that I believe will greatly benefit from this template-based approach, so I will certainly have real questions about its usage.
I'm planning to add DomTemplate to my project using Composer to explore it further starting this week. I will post my practical questions right here.
In any case, feel free to contact me at any time about the documentation you are preparing. I'll be glad to be of help.
That's great. I'm actually away until next weekend, but if you post any questions you have here I'll make sure I address them directly when I get back. I hope this doesn't hold you up too much.
Speak soon!
No worries, enjoy your leave. I'll keep posting questions here.
One thing that already comes to mind after reviewing the CSS Tricks article, is how to conditionally display parts of the template. I could conditionally load multiple markup files, but that's not very flexible.
I realized that DomTemplate demands PHP 8, but I'm limited to version 7.4. I assume there are (rightly so) no plans to make the project compatible with older versions of PHP.
My project is a WordPress plugin for public distribution, and the absolute majority of WP installs are – unfortunately – still not using PHP 8. Only 1.49% are using it. With such a low usage, bumping the PHP to version 8 in my project will certainly be a support nightmare.
That was unexpected, but I guess I'll have to wait for a better PHP 8 usage on WordPress to be able to use DomTemplate in my project. Until then, I need to use the DOMDocument approach for better compatibility.
My apologies for not being able to do a more comprehensive test for you right now, @g105b. The DomTemplate approach is obviously the right one, and I look forward to using it when the time comes. Thank you again!
Hi @pagelab ,
That statistic is quite surprising actually. As I've finished splitting all PHP.Gt repositories into their own this year, and after moving DOM implementation to a Facade pattern to improve W3C compliance, I thought the new release should take advantage of the latest features. If you look at what of PHP 8 is used by Dom and DomTemplate, there isn't that much: the Bind and BindGetter attributes are the main feature to utilise PHP 8, along with a few usages of the null-safe operator here and there.
The question is, do you think there would be much benefit to making the libraries compatible with 7.4? I'm assuming you're not the only one who uses Wordpress and are looking for DOM functionality?
I wonder if this is something I should take a look at once I've released WebEngine v4?
The question is, do you think there would be much benefit to making the libraries compatible with 7.4?
For bespoke projects (using WordPress or otherwise) in which the developer has control of the server, not so much, but for projects intended for public distribution, it is essential.
I'm assuming you're not the only one who uses Wordpress and are looking for DOM functionality?
Probably I'm not the only one. As you may know, WordPress right now is all about the block editor, which is mostly developed using Javascript/React.
But a lot of PHP developers haven't caught up on the necessary skills and prefer to use helper libraries like ACF, Carbon Fields, Metabox (or others) to create blocks using familiar PHP tooling.
These make block development much, much easier/fast and are a natural path for projects on a small budget or for people who can't/won’t learn the ins and outs of modern Javascript development yet.
All of these libraries adopt the same technical approach: they use a callback function to define the HTML template of a block, which is rendered in both the block editor and the front-end, using data from the block's UI controls and settings.
So, I would say that there is a practical use for DOM tooling in this context, because that specific part of the block development is usually done mixing logic and presentation, as you can see in this example.
And this is just one of the real use cases for DOM manipulation on WordPress. As a hugely popular project that is used for many diverse things, I'm pretty sure there are other scenarios.
Very interesting, thanks for your answer.
I'm going to put 7.4 compatibility on the to-do list, so I'm not excluding Wordpress. I'm sure there's not too much I'd need to change across the libraries, and they're really well unit tested so it should be obvious if the changes have any negative consequences.
My priority at the moment is to release WebEngine to a stable v4, but after that I'll see if I can get 7.4 DOM Compatibility. If you don't mind, I'll give you a ping when I get round to it?
Greg.
I'm going to put 7.4 compatibility on the to-do list, so I'm not excluding Wordpress.
Great, it's a sensible decision.
If you don't mind, I'll give you a ping when I get round to it?
Yes, I'm fine with that.