Project

General

Profile

Actions

Task #73046

closed

Suggested rule breaking alias AbstractNode -> ViewHelperNode for backwards compatibility

Added by Claus Due over 8 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2016-01-31
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
easy
Sprint Focus:

Description

This suggested change breaks good practice but could be judged important enough to implement regardless; if nothing else then as a temporary measure and inform users of the deprecation and how to migrate.

Problem:

ViewHelperInterface::compile() in standalone Fluid now requires an actual ViewHelperNode instead of AbstractNode as it was before. The reason for changing this should be fairly obvious.

Implication:

This signature change means that ViewHelpers which implement a custom compile() method must update their signature (dot not apply to ViewHelpers implementing only renderStatic). Two ViewHelpers in TYPO3 CMS Fluid were migrated as part of the standalone Fluid merge - but third-party ViewHelpers would require either migration or an alias.

Rule break:

The alias would have to be created so that TYPO3\CMS\Fluid\Core\Parser\SyntaxTree\AbstractNode becomes an alias of TYPO3Fluid\Fluid\Core\Parser\SyntaxTree\ViewHelperNode. This is obvious less than ideal but solves the problem immediately and prioritises not breaking the public API by somewhat breaking the non-public API.

Consequences:

Implementing such an alias would impact two things, both of which would be considered internal API:

  • Overridden TemplateParsers (before standalone Fluid merge) might not function, depending on the nature of overrides (conditions checking class names may fail)
  • Custom Nodes (implemented via an overridden TemplateParser, before standalone Fluid) would break either in function or form (incompatible constructor signatures on php7 at least)

Both of which are definitely considered edge cases, of which I personally only know a single implementation - the template analyzer/validator of EXT:builder.

I suggest implementing this alias despite the rule breaking it implies. The benefits (non-breaking public API during template compiling) should far outweigh the breaks caused to internal API as described in the two edge cases above.

The change should be fitted with a breaking changes RST and inform about how to migrate (switch AbstractNode to ViewHelperNode in compile() method signature of third-party ViewHelpers).

Actions

Also available in: Atom PDF