Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Allow defining arguments for f:render with f:argument #429

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

NamelessCoder
Copy link
Member

@NamelessCoder NamelessCoder commented Feb 14, 2019

This patch allows you to define arguments that get passed to
f:render by using f:argument in the tag contents.

<f:render partial="Something">
   <f:argument name="arg1">Special value for arg1 variable</f:argument>
   <f:argument name="arg2">Special value for arg2 variable</f:argument>
</f:render>

Any argument specified with f:argument this way will override
the argument of the same name if it was passed in the “arguments”
array as well. The combined result will be used as variables for the
sub-rendering call.

References: #427

@NamelessCoder NamelessCoder force-pushed the feature/slots branch 2 times, most recently from 50a5a30 to 30721a5 Compare February 14, 2019 18:31
@coveralls
Copy link

coveralls commented Feb 14, 2019

Coverage Status

Coverage decreased (-1.0%) to 96.449% when pulling 0435601 on NamelessCoder:feature/slots into e3533d0 on TYPO3:master.

examples/Resources/Private/Singles/Variables.html Outdated Show resolved Hide resolved
src/Core/ViewHelper/ViewHelperVariableContainer.php Outdated Show resolved Hide resolved
src/Core/ViewHelper/ViewHelperVariableContainer.php Outdated Show resolved Hide resolved
src/Core/ViewHelper/ViewHelperVariableContainer.php Outdated Show resolved Hide resolved
src/ViewHelpers/VariableViewHelper.php Outdated Show resolved Hide resolved
This patch allows you to define arguments that get passed to
f:render by using f:argument inside the tag contents.

```xml
<f:render partial="Something">
   <f:argument name="arg1">Special value for arg1 variable</f:argument>
   <f:argument name="arg2">Special value for arg2 variable</f:argument>
</f:render>
```

Any argument specified with f:variable this way will override
the argument of the same name if it was passed in the “arguments”
array as well. The combined result will be used as variables for the
sub-rendering call.

References: TYPO3#427
@NamelessCoder
Copy link
Member Author

As a result of discussion:

  • Feature changed so that f:argument is used to declare such arguments.
  • Made the stack ViewHelper-class-agnostic so it will allow any VH to receive arguments this way as long as it fits the use case (works by evaluating tag content and then doing some output, not vice versa).
  • Fixed various CGL and documenting comments.

@NamelessCoder NamelessCoder changed the title [FEATURE] Allow defining arguments for f:render with f:variable [FEATURE] Allow defining arguments for f:render with f:argument Feb 20, 2019
@NamelessCoder
Copy link
Member Author

Ready for another look @mbrodala (sorry about the ping, doing open-stuff-cleanups).

@mbrodala
Copy link
Member

mbrodala commented Mar 5, 2019

Looks good from reading (and amazingly simple) but I'd like to conduct at least a simple CLI test to get a feeling for this.


// Prepare a delegate variable provider that will be possible to extract after rendering the child closure.
// Any variable defined therein gets used as argument and overrides any argument of the same name.
// Note: not using late static binding here is a conscious decision: if late static binding had been used
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noticed that this comment is no longer correct, since removing the VH scope argument from the methods it relates to.

@NamelessCoder
Copy link
Member Author

Abandoned; would not fit with Fluid 3.0 and is not vital.

@NamelessCoder
Copy link
Member Author

Re-opened, there has been some interest for the feature and we should probably re-consider it. My plan is to either cross-port the API parts and functionality to the 3.0 branch, or create an identical feature there, to make 2.x and 3.x straight compatible concerning this particular feature.

@NamelessCoder NamelessCoder reopened this May 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants