TYPO3.Fluid

Great, thanks. Should be

$arguments = t3lib_div::array_merge_recursive_overrule(array('settings' => $this->templateVariableContainer->get('settings')), $arguments);

I think. Settings given in the method's arguments should allway overrule.

Felix Oertel wrote:

Great, thanks. Should be

$arguments = t3lib_div::array_merge_recursive_overrule(array('settings' => $this->templateVariableContainer->get('settings')), $arguments);

I think. Settings given in the method's arguments should allway overrule.

yeah right :) fine with this, too...

Hey Bastian,
I don't think that providing the settings in partials would conflict with this concept - especially when it comes to widgets at some time.
In your example, you're using a partial that of course should/has to be configured by passed arguments/options.
But imagine a partial where you allow to configure css class names, colors or a paginagtion related configuration that should be globally changeable via TS. You could use these special layout/design related options from the settings array, easy to adopt for various extensions via TS then, without having to mess around with their default templates or replace the default partial with your customized one etc.
Or what if you like to use a widget in a partial that depends on some configurations options from the settings array?

Hi,

I think as well that it would be a helpful feature. To me, partials are useful in two cases:

1. to encapsulate similar parts across one extension
2. to encapsulate similar parts across multiple extensions.

While I agree with Bastian that in the second case, depending on settings is ugly and non-intuitive, I think it is quite intuitive in the first case -- and it really helps to remove duplication in a single extension.

Bastian, could I somehow convince you? :-)

Greets,
Sebastian

Sebastian Kurfuerst wrote:

Bastian, could I somehow convince you? :-)

gn gn.. not really ;)

compare partials with global functions for a minute.
Of course you could have all method parameters in one array like

public function doSomething(array $options)

To me, partials are useful in two cases:

1. to encapsulate similar parts across one extension
2. to encapsulate similar parts across multiple extensions.

I think, even for the first case it makes sense to move your partial configuration into one "section" of your global settings:

settings {
  somethingCompletelyDifferent = 123
  defaultColor = red

  somePartial {
    defaultCssClass = foo
    defaultColor < tx_pluginsignature.settings.defaultColor
  }
}

and use it like

<f:render partial="yourPartial" arguments="{cssClass: settings.somePartial.defaultCssClass, color: settings.somePartial.defaultColor} />

<f:render partial="yourPartial" arguments="{settings: settings.yourPartial} />

And, finally, if you really want to share all plugin settings with the partial, you can still set them as argument.. But I'm not in favor of implicitly merging them..

Hey,

this issue is now in Gerrit, waiting for reviews.

Issue: https://review.typo3.org/64
Test Case: https://review.typo3.org/62

NOTE: The settings are NOT merged together, like it has been suggested in #6289,
as this will lead to un-obvious behavior for the user.

Greets,
Sebastian