Feature #58557
Define Namespaces in Configuration File
| Status: | Rejected | Start date: | 2014-05-06 | |
|---|---|---|---|---|
| Priority: | Won't have this time | Due date: | ||
| Assigned To: | Bastian Waidelich | % Done: | 0% |
|
| Category: | Core | |||
| Target version: | TYPO3 Flow Base Distribution - 2.x | |||
| Has patch: | No |
Description
It would be nice if one could define the namespaces via configuration file, additionally to the existing way inside the fluid file.
This way you could move the f: namespace definition out of TYPO3\Fluid\Core\Parser\TemplateParser::$namespaces into the yaml file.
- cleaner fluid templates
- simple (re-)configuration across a package
- convention over configuration (e.g. when multiple frontend developers create multiple fluid templates)
- reconfiguration of the f: namespace
Related issues
History
#1 Updated by Bastian Waidelich about 1 year ago
- Category set to Core
- Status changed from New to Needs Feedback
Aimo Künkel wrote:
Hi Aimo,
this topic comes up from time to time but we didn't make namespace prefixes configurable by intention (see #35766)
- cleaner fluid templates
Debatable, but I don't think that some namespace declarations make a template less clean
- convention over configuration (e.g. when multiple frontend developers create multiple fluid templates)
For this I'd suggest to come up with a naming convention in the respective project (e.g. lower cased package key or its initials)
- reconfiguration of the f: namespace
That would break a lot of templates
But most importantly: It's a very important fact that Fluid templates (and partials and layouts) are self-contained. That makes them easier to comprehend (without having to check certain configuration options) and reusable.
If you agree to our points I'd like to close this issue as duplicate
#2 Updated by Bastian Waidelich about 1 year ago
- Assigned To set to Bastian Waidelich
#3 Updated by Adrian Föder about 1 year ago
Hi Bastian,
I understand your (and Sebastians) arguments; but for the sake of consistency, the f: namespace should also not be available "magically" then.
On the other hand, a proprietary project's namespace is surely as "important" as the Fluid Core, so I think an "f" and a "acme" namespace for example can and should live and be treated equally.
BTW; I personally didn't and don't want to include namespaces globally, but in that case I would go so far and would say that also Fluid's namespace should be included explicitly then.
#4 Updated by Aimo Künkel about 1 year ago
Thanks for your update, i can understand your point with the advantages of fluid templates being self-contained.
Still, i think enabling this doesn't necessarily have to break things here:
From my point of view, it's just adding items to an existing list of preconfigured namespaces, even if it currently just contains one item (f:)
- put the fluid namespace into a separate property
- respect it in TYPO3\Fluid\Core\Parser\TemplateParser::reset()
- make flow change it via Objects.yaml, Views.yaml with an additional setting, or something else...
Somehow I'm not totally convinced yet since this change feels backwards compatible.
#5 Updated by Jacob Floyd about 1 year ago
I like the idea of namespaces specified in configuration.
#6 Updated by Bastian Waidelich about 1 year ago
Ok, I added the topic to the agenda of our upcoming technical meeting (see http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings#Introduce_configurable_namespace_aliases_to_Fluid.3F and feel free to join on the 13th)
#7 Updated by Bastian Waidelich about 1 year ago
Hi guys,
as promised, we discussed that topic in our "Technical Meeting" today (see http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings).
I brought it up and tried to "leave out" my personal opinion as much as possible but we're still skeptikal of introducing a global configuration option for following reasons:
- It's very handy that Fluid files are "self-contained", so that it is comprehensible even if no other configuration is known (even thought the f-prefix is predefined, that's no contradiction in our opinion, just another convention)
- If every package can register global namespace mappings, conflicts would be very likely - using Views.yaml for that would not solve this
- It defeats the "convention > configuration" approach
Instead of a new configuration option, we suggest to introduce a new convention:
The package keys of all packages that contain ViewHelpers are pre-registered (lower-cased).
With this you could directly use 3rd party ViewHelpers without having to register the namespace:
<typo3.neos:helper foo="bar" />
{typo3.neos:helper(foo: 'bar')}
Apart from that we should get http://forge.typo3.org/issues/53059 in asap independently of the result of the above discussion.
#8 Updated by Aimo Künkel about 1 year ago
Hi Bastian,
Thanks for your thoughts and update about your technical discussion.
{typo3.neos:helper(foo: 'bar')} feels quite handy and i'd like to see it in the fluid core!
This way we could easily drop the re-mapping to other names or letters in most cases, which kinda feels like the "cleanup" i was missing.
looking forward to it,
Aimo Künkel
#9 Updated by Bastian Waidelich about 1 year ago
- Status changed from Needs Feedback to Rejected
- Priority changed from Should have to Won't have this time
Aimo Künkel wrote:
{typo3.neos:helper(foo: 'bar')} feels quite handy and i'd like to see it in the fluid core!
This way we could easily drop the re-mapping to other names or letters in most cases, which kinda feels like the "cleanup" i was missing.
I agree and close this one in favor of #58829 (watch that one for updates).
Thank again for your feedback!