Hi Peter Den fre. 21. dec. 2018 kl. 02.06 skrev Peter Kokot <[email protected]>: > > Hello, > > Current template system in bugs.php.net code is integrated in front > controllers (index.php...) and some separate template files. It > contains several helper functions with globals usage and mixes HTML > with PHP code logic. This makes app code a bit disorganized and less > testable.
First of, thanks a lot for your work on this. I really like the implementation of this, it's simple and very straight forward without a huge overcomplexity to it, well done! > I'd suggest to refactor this issue into a: > - separate template engine > - templates folder > - front controllers (PHP files currently residing in the www directory > - index.php...) > > The template layer for the bugs.php.net is in progress happening here: > https://github.com/php/web-bugs/pull/66 I have added a few comments inline on the PR. > This introduces two additional classes (so far): > - App\Template (main template engine with render method) > - App\Template\Context (to be able to use $this in the template directly) > - phpunit tests attached > - a quick intro how to use such template layer I like the concept of the \App\Template\Context, as it does allow us to define globals like you have for some of the site configuration variables and could greatly be expanded on. > Pros: > - still thin and simple enough to understand it quickly (very little > methods used) > - no additional caching required (performance impact is still being measured) > - integrated in the app directly so no dependencies required to > install in this aspect > > I didn't want to introduce a 3rd party template engine here because > the app can't use composer installation step when deploying to > production yet neither we might agree on using some piece of template > engine. This patch is still in progress so I just wanted to get some > feedback and opinions at this phase. Generally I think using a template engine in PHP is sort of wrong (to a certain extend), as PHP is technically a templating language in itself (due to its being embedded), however I do think that such implementations as the one you have proposed are perfectly fine as it does encapsulate variable scopes without generating too much an overhead for the same of logic separation. Using a third party engine would be way too overkill for the target of the bug tracker (as we do not really aim for it to be a re-usable project, but merely making it cater to our needs only). Off topic, but still somewhat related to the above; The MySQL bug tracker[1] is originally based on that of bugs.php.net, however I have not been able to find its source anywhere publically with a quick search. [1] http://bugs.mysql.com/ -- regards, Kalle Sommer Nielsen [email protected] -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
