Feature #58557

Define Namespaces in Configuration File

Added by Aimo Künkel about 8 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Won't have this time
Category:
Core
Start date:
2014-05-06
Due date:
% Done:

0%

Estimated time:
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.

Advantages would be:
  • 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

Related to TYPO3.Fluid - Feature #53059: Throw exception for unresolved namespacesClosedBastian Waidelich2013-10-23

Actions
Related to TYPO3.Fluid - Feature #58829: Register package namespaces automaticallyClosedMarc Neuhaus2014-05-15

Actions
Is duplicate of TYPO3.Fluid - Feature #35766: add custom namespaces in settings.yamlRejected2012-04-07

Actions
#1

Updated by Bastian Waidelich about 8 years 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 8 years ago

  • Assignee set to Bastian Waidelich
#3

Updated by Adrian Föder about 8 years 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 8 years 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:)

If you don't want to make fluid itself learn this thing we could maybe just
  1. put the fluid namespace into a separate property
  2. respect it in TYPO3\Fluid\Core\Parser\TemplateParser::reset()
  3. 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 8 years ago

I like the idea of namespaces specified in configuration.

#6

Updated by Bastian Waidelich about 8 years 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 8 years 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 8 years 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 8 years 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!

Also available in: Atom PDF