Feature #1907

Default values for view helpers based on context

Added by Sebastian Kurfuerst almost 7 years ago. Updated over 1 year ago.

Status:New Start date:2008-10-29
Priority:Could have Due date:
Assigned To:- % Done:

0%

Category:Core
Target version:-
Has patch:

Description

We should supply a mechanism in the "ViewHelperNode" which will merge the given parameters with certain default parameters.

The default parameters should be context dependent (However, we don't know yet how this might look like).

This would be helpful for numerous cases:

  • <f3:uri.linkTo> -> "action", "controller", and "package" arguments could be supplied if no other parameter given
  • Link parameters - we could realize something like "keepPIVars" with this feature
  • <f3:image> tag - supplying default parameters for maxWidth, maxHeight, ...

Related issues

related to TYPO3.Fluid - Feature #3717: "Designators" for Form view helper Resolved 2009-06-22

History

#1 Updated by Bastian Waidelich over 6 years ago

while writing some view helpers i realized again: we need a "private" context that is available in the view helpers.
instead of an array this could be a class with getters for current view, global settings, default arguments...
default arguments could be an array like:
array(
array('\F3\Fluid\ViewHelpers\Format\DateViewHelper' => array(
'format' => 'Y-m-d'
),
array('\F3\Fluid\ViewHelpers\LinkViewHelper' => array(
'package' => 'foo',
'controller' => 'bar',
...

In prepareArguments() of the abstract view helpers, the default arguments could be taken into account.

#2 Updated by Sebastian Kurfuerst over 6 years ago

I don't really know anymore the intention of this... We need to discuss this as soon as I am back (e.g. next tuesday) - Greets Sebastian :-)

#3 Updated by Bastian Waidelich over 6 years ago

I don't really know anymore the intention of this

I still remember - it's a very neat feature. And it will be especially useful for TYPO3:
Then you can eg. specify via TypoScript that currencyViewHelper has a default format of '##,## €' in the german branch and '##.## $' in the American..
In conjunction with this I thought of following: {object} could internally call some kind of "defaultViewHelper" which has an argument "escapeHtml".. So you could enable htmlspecialchars for html templates and disable it for special setups.
Well, just a very rough idea..

#4 Updated by Sebastian Kurfuerst about 6 years ago

  • Category set to 444
  • Target version set to 1.0.0 alpha 1

#5 Updated by Sebastian Kurfuerst about 6 years ago

  • Target version changed from 1.0.0 alpha 1 to 1.0
  • Branch set to v4 + v5

#6 Updated by Robert Lemke about 6 years ago

  • Target version deleted (1.0)

#7 Updated by Sebastian Kurfuerst over 5 years ago

  • Status changed from New to Needs Feedback
  • Priority changed from Should have to Could have

#8 Updated by Bastian Waidelich over 5 years ago

What kind of feedback do you want? ;)

#9 Updated by Franz Koch over 4 years ago

Bastian Waidelich wrote:

I don't really know anymore the intention of this

I still remember - it's a very neat feature. And it will be especially useful for TYPO3:
Then you can eg. specify via TypoScript that currencyViewHelper has a default format of '##,## €' in the german branch and '##.## $' in the American..
In conjunction with this I thought of following: {object} could internally call some kind of "defaultViewHelper" which has an argument "escapeHtml".. So you could enable htmlspecialchars for html templates and disable it for special setups.
Well, just a very rough idea..

I like that idea - especially the escape part, as I'm currently trying to render a plaintext mail content with Fluid and everything is rendered through HSC :(. But default viewHelper arguments like format options should get injected differently then the escaping stuff. Escaping should depend on the renderingContext, whereas the other options could be defined via TS (in v4 maybe via tx_fluid.viewHelper.[packageKey].format.date.defaultArguments.format = d.m.Y).
This feature might especially be needed for widgets, which of course should be globally configurable, otherwise they don't make much sense IMO.

#10 Updated by Bastian Waidelich over 4 years ago

  • Tracker changed from Feature to Major Feature

#11 Updated by Sebastian Kurfuerst about 4 years ago

  • Category set to Core
  • Status changed from Needs Feedback to New

#12 Updated by Sebastian Kurfuerst about 4 years ago

  • Tracker changed from Major Feature to Story

#13 Updated by Sebastian Kurfuerst about 4 years ago

  • Tracker changed from Story to Feature

Also available in: Atom PDF