Template engine changes to allow for structure flexibility

Note: We are moving the topics of this forum and it will be deleted at some point

Publish your own request for comments/change or patches for the next version of phpBB. Discuss the contributions and proposals of others. Upcoming releases are 3.2/Rhea and 3.3.
User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: Template engine changes to allow for structure flexibility

Post by MichaelC »

As previously stated this introduces a really powerful template inheritance system which no other option does give us. Furthermore, breaking BC such a huge amount between 2.0 and 3.0, and 3.0 and 3.1 is no reason that we should (unnessisarily) break BC hugely between 3.1 and 3.2. If anything, we should break it as little as possible given the shorter release cycle.

Also, this does allow for proper restructuring of files beyond the obvious moving component x out of a file into it's own file or renaming things to put them or putting them in directories between different styles which using hardcoded template names doesn't.

Also, it provides a very obvious fix to using different file extensions instead of having to do ugly work with trying both .html and .html.twig
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

Marshalrusty
Project Manager
Project Manager
Posts: 273
Joined: Thu Oct 27, 2005 1:45 am

Re: Template engine changes to allow for structure flexibility

Post by Marshalrusty »

PayBas wrote:I'm not sure how easily we can drop prosilver for 3.2. I think we've indicated in various places that 3.1 is the last supported version for subsilver, and 3.2 would be the last version for prosilver.
I agree. At the moment, the new style is not in a place where we can guarantee its arrival in time for 3.2. As such, prosilver will remain the default front-end all the way through 3.2 development. How and when we decide to deprecate/discontinue it doesn't change that fact.
MichaelC wrote:As previously stated this introduces a really powerful template inheritance system which no other option does give us. Furthermore, breaking BC such a huge amount between 2.0 and 3.0, and 3.0 and 3.1 is no reason that we should (unnessisarily) break BC hugely between 3.1 and 3.2. If anything, we should break it as little as possible given the shorter release cycle.
I think we have to resign ourselves to the fact that BC will take a hit at least in 3.2 and 3.3. All extensions will need to be updated to work with the new style anyway, and it seems to me that changes to the layout of the templates do not increase the degree to which BC is broken, unless you're suggesting leaving everything exactly the same as it currently is.

User avatar
PayBas
Registered User
Posts: 305
Joined: Tue Jul 29, 2008 6:08 pm
Contact:

Re: Template engine changes to allow for structure flexibility

Post by PayBas »

Another thing to think about if we don't want to use a template abstraction layer, is how far we want to go in conforming prosilver to the desired new template structure. I agree that reorganizing the prosilver templates could be done, but whether we want to split it up in components as well would determine how much work it is.

For instance, this is a list of all the hard-coded templates in the core (excluding all the UCP/MCP modules):

Code: Select all

{
	"faq_body.html" : "faq.html.twig",
	"index_body.html" : "index.html.twig",
	"report_body.html" : "report.html.twig",
	"search_body.html" : "search_form.html.twig",
	"search_results.html" : "search_results.html.twig",
	"viewforum_body.html": "viewforum.html.twig",
	"viewonline_body.html" : "viewonline.html.twig",
	"viewonline_whois.html" : "___.html.twig",
	"viewtopic_body.html" : "viewtopic.html.twig",
	"viewtopic_print.html" : "___.html.twig",

	"memberlist_body.html" : "members.html.twig",
	"memberlist_im.html" : "___.html.twig",
	"memberlist_team.html" : "team.html.twig",
	"memberlist_view.html" : "viewprofile.html.twig",
	"memberlist_email.html" : "___.html.twig",

	"mcp_front.html" : "mcp/index.html.twig",
	"mcp_move.html" : "___.html.twig",
	"mcp_approve.html" : "___.html.twig",

	"ucp_main_front.html" : "ucp/index.html.twig",
	"ucp_agreement.html" : "___.html.twig",
	"ucp_avatar_options_gravatar.html" : "___.html.twig",
	"ucp_avatar_options_local.html" : "___.html.twig",
	"ucp_avatar_options_remote.html" : "___.html.twig",
	"ucp_avatar_options_upload.html" : "___.html.twig",

	"confirm_body.html" : "___.html.twig",
	"confirm_delete_body.html" : "___.html.twig",
	"login_body.html" : "___.html.twig",
	"login_forum.html" : "___.html.twig",
	"message_body.html" : "___.html.twig",

	"posting_body.html" : "posting.html.twig",
	"bbcode.html" : "includes/bbcode.html.twig",
	"attachment.html" : "___.html.twig",
	"posting_smilies.html" : "___.html.twig",
	"posting_progress_bar.html" : "___.html.twig",

	"captcha_default.html" : "___.html.twig",
	"captcha_qa.html" : "___.html.twig",
	"captcha_recaptcha.html" : "___.html.twig",

	"auth_provider_ldap.html" : "___.html.twig",
	"auth_provider_oauth.html" : "___.html.twig",
	"login_body_oauth.html" : "___.html.twig",
	"ucp_auth_link_oauth.html" : "___.html.twig"
}
These files could indeed just be renamed in prosilver (and put in the appropriate subdirs), without necessarily being split up in components. But this would inevitably create a disparity between the prosilver structure and any new style.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: Template engine changes to allow for structure flexibility

Post by MichaelC »

Marshalrusty wrote:
MichaelC wrote:As previously stated this introduces a really powerful template inheritance system which no other option does give us. Furthermore, breaking BC such a huge amount between 2.0 and 3.0, and 3.0 and 3.1 is no reason that we should (unnessisarily) break BC hugely between 3.1 and 3.2. If anything, we should break it as little as possible given the shorter release cycle.
I think we have to resign ourselves to the fact that BC will take a hit at least in 3.2 and 3.3. All extensions will need to be updated to work with the new style anyway, and it seems to me that changes to the layout of the templates do not increase the degree to which BC is broken, unless you're suggesting leaving everything exactly the same as it currently is.
With a template abstraction layer we could do just that, leave templates where they are in prosilver and not break BC for prosilver-based styles, hugely simplifying the updating process for styles authors and hopefully therefore meaning we have lots more 3.2 styles than we would otherwise.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Template engine changes to allow for structure flexibility

Post by nickvergessen »

They still need to be updated with all the fixes and "breaking" it, just makes it more obvious that the style needs to be updated.
Also if you create such a huge list, it is just a nightmare when creating patches that need a new template file and requires a rebase when another PR added a file at a similar position of the list, which is why I'd prefer BC break over over-complicating things here.
Member of the Development-TeamNo Support via PM

User avatar
hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 968
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: Template engine changes to allow for structure flexibility

Post by hanakin »

The only real advantages I think here are
  • Multiple Inheritance - if you use inheritance
  • Custom Folder structure per style for advanced styles - if you do not use inheritance.
everything else seems moot to me. If their is a better way to allow for this than lets look into that other wise this works?
Donations welcome via Paypal Image

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Template engine changes to allow for structure flexibility

Post by nickvergessen »

The question is, do we even want multi-inheritance, from my dev perspective I'd say no. If you inherit from a stlye that does something odd, just overwrite it again. There is no need for having 2 inheritance parents.
And as for custom structure, just make a good default one? You can structure your files like you want, if you just add a file with the original name and do a <!-- INCLUDE fancy/* -->

Both do not make up the negative impact from having the huge list, for me
Member of the Development-TeamNo Support via PM

developer11
I've been banned
Posts: 17
Joined: Tue Dec 09, 2014 10:25 am

Re: Template engine changes to allow for structure flexibility

Post by developer11 »

hanakin wrote:
Arty wrote:Why would you want to do that?
I think you are completely misunderstanding. Not each and everytime. I want to rename them from what they are now for the FF files. Also as a theme/extension authour I wish to break things out by objects and as you add new objects you will need new files for those objects.
I think that its you - hanakin - who do not understand what you are saying......

its absurd especially for those whose forums are hosted with very limited disk quota/s....... new object = new file will quickly make their quotas used in 100%...... makes no sense to me.

Instead of transforming well-wrtten piece of code into sth crappy, you'd better do other way round - transform crappy permission unit into well-written one.....

User avatar
PayBas
Registered User
Posts: 305
Joined: Tue Jul 29, 2008 6:08 pm
Contact:

Re: Template engine changes to allow for structure flexibility

Post by PayBas »

developer11 wrote:I think that its you - hanakin - who do not understand what you are saying......

its absurd especially for those whose forums are hosted with very limited disk quota/s....... new object = new file will quickly make their quotas used in 100%...... makes no sense to me.

Instead of transforming well-wrtten piece of code into sth crappy, you'd better do other way round - transform crappy permission unit into well-written one.....
Sorry, but this is completely irrelevant and off-topic.

developer11
I've been banned
Posts: 17
Joined: Tue Dec 09, 2014 10:25 am

Re: Template engine changes to allow for structure flexibility

Post by developer11 »

PayBas: just the opposite - veryt much relevant and very much on topic.....

Post Reply