What would you like to put in a twig file that interferes with how a twig function currently looks like?
Btw. Understanding the conversation and identifying you would require less brain power from me if your username here was consistent with the one in the issue tracker.
Twig Function Semantic Naming
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Re: Twig Function Semantic Naming
Not sure why it matters? my user name is the same in both places, and so is my avatar. Neither of which have not changed ever! Jira uses full name and not username for display which is a fault with jira out of my control.
Everything is contained in this topic so ignore the tracker. Just read the topic from the beginning and you might understand the proposal reasoning and justification.
Everything is contained in this topic so ignore the tracker. Just read the topic from the beginning and you might understand the proposal reasoning and justification.
Re: Twig Function Semantic Naming
I just happen to find here only vague motivations. So naturally I go look elsewhere to see what's behind all this.
So let's start where it started:
I think this function is doing too much. Unfortunately, like many other functions in phpBB.
If it was split up in smaller parts or concerns it would be more flexible, better maintainable, more clear,explicit and reusable.
This function:
It would be more clear if we would just define a (PHP)
Then link this PHP method with a Twig extension, so we can use it also as a function in the template. The twig function is like an allowed gate to the PHP world where the data retrieval takes place.
Then construct with all the Twig tools available whatever you like with this forum array, be it a "jumpbox" or what else You would get the links with another Twig function, (of which I don't know the name right now).
And the PHP function
I just think that there should be careful thought spent on what the optimal borders of concerns are, not that I'm laying out a final design or anything.
You could also pass the (cached) visible forum array on every page load and not use a function to retrieve it, which is maybe not unreasonable.
So let's start where it started:
Code: Select all
{{ JumpBox() }}
If it was split up in smaller parts or concerns it would be more flexible, better maintainable, more clear,explicit and reusable.
This function:
- Retrieves the array of forums from the database and filters the ones out that are not visible to the user.
- Also adds a link to each forum.
- Renders this array with the template file
jumpbox.html
.
jumpbox.html
,is knowledge you can't get from the context, right? You need to look into the twig extension definition in order to get that. It would be more clear if we would just define a (PHP)
get_forums()
of get_visible_forums()
method that is only concerned with returning the visible forums array. Then link this PHP method with a Twig extension, so we can use it also as a function in the template. The twig function is like an allowed gate to the PHP world where the data retrieval takes place.
Then construct with all the Twig tools available whatever you like with this forum array, be it a "jumpbox" or what else You would get the links with another Twig function, (of which I don't know the name right now).
And the PHP function
make_jumpbox()
can be thrown away. It didn't belong in the PHP world anyway. It's name expressed something belonging to the view layer. I just think that there should be careful thought spent on what the optimal borders of concerns are, not that I'm laying out a final design or anything.
You could also pass the (cached) visible forum array on every page load and not use a function to retrieve it, which is maybe not unreasonable.
Re: Twig Function Semantic Naming
And I forgot to mention still another thing that this function does:
Namely, it triggers a PHP event.
Now, isn't that a design flaw and crossing the borders of concern that we can trigger a PHP event from our template?
Code: Select all
{{ JumbBox() }}
Now, isn't that a design flaw and crossing the borders of concern that we can trigger a PHP event from our template?
Re: Twig Function Semantic Naming
None of this is on topic we are not diss using what a function does that’s another topic. We are discussing the intent that something used in a template is a twig render function rather than any other sort of content that can be contained in a template! Html, css objects, css components, js, Lang vars, template vars, includes, macros, etc...
Re: Twig Function Semantic Naming
Uhm? I hope not to find any js or css in there? We use the template engine to construct html, no?
Re: Twig Function Semantic Naming
A good thing to do I think will be to prefix template functions that come from phpBB extensions like
That shows immediately "where it comes from" and what's responsible for it. and hints "what it does"
The same namespacing pattern everywhere contributes to the readability (PHP phpBB events, database table names, service names, template events, etc.)
ext_vendorname_extensionname_
or just vendorname_extensionname_
That shows immediately "where it comes from" and what's responsible for it. and hints "what it does"
The same namespacing pattern everywhere contributes to the readability (PHP phpBB events, database table names, service names, template events, etc.)
Re: Twig Function Semantic Naming
But won't they be within the extension's files anyway so it will be obvious where they come frommartti wrote: Tue Apr 28, 2020 3:30 pm A good thing to do I think will be to prefix template functions that come from phpBB extensions like ext_vendorname_extensionname_ or just vendorname_extensionname_
That shows immediately "where it comes from"
David
Remember: You only know what you know -
and you do not know what you do not know!
Remember: You only know what you know -
and you do not know what you do not know!
Re: Twig Function Semantic Naming
We are not there yet with chameleons development , but I am considering e for ext classes ie if you add css via an ext then it should add its classes using the e_component_class convention...but again that’s a mother topic for discussion.
Re: Twig Function Semantic Naming
So I agree with the others, keep it
a_function_in_twig()
because there's no confict. There is no php, css or js in .html.twig
files. And if there is, then that's the real issue. There is already a convention in phpBB And most of the rest of the world outside this littlle phpBB corner uses the same as it is Twig's own convention of naming functions.