[TYPO3-english] How to insert additionalparams with more than 2 level for f:link.page

[Stephan Schuler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Bernd.


I think you get me slightly wrong. So here's some clarification.

> which means: you are very much restricted in the the use of indizes to URL parameters by fluid

That's correct. But that's the way it is. Think about the "action" or "controller" argument which determine the target routing of an extbase plugin. Those are written as "@action" or "@controller", too. So the problem isn't only related to "@widget".

> this might make it more readable for humans, but the result will be full of whitespace AND #10(LF) in inappropiate positions

This, imho, doesn't matter because those aren't part of the output HTML but only internally used.

Here's why:
> <f:link.page pageUid="1234" additionalParams="{
>     foo: 'bar',
>     bar: 'baz',
>     baz: '{
>         key: \'value\'
>     }'
> }">Click me</f:link.page>

Yes, the cached fluid template stuff will contain whitespaces and line breaks. But they will never make it to the output. The


> rebuilding all new means ignoring or rewriting tx_news

I'm not talking about rebuilding the link view helper or news. The only thing I'm saying is: You cannot count on the argument "@widget_0" being there forever.
Have a look at the core code of the AbstractWidgetViewHelper. There it says:
> $widgetIdentifier = '@widget_' . $widgetCounter;
So, the "@widget_" is kind of a static string, you might rely on that. But the "0" value only says "it's the first widget in that particular page". If you have more than one widget view helpers (let's say you paginate both, news on the one side and news-comments unrelated to news on the other) then one of the view helpers will be addressed by "@widget_0", the other by "@widget_1". And that's the point: Having "_0" here isn't reliable.
If you don't change your code, or if you know this thing and adjust accordingly, then everything is fine. But usually those kind of hard coded parameters are the source of regression errors.

> why do the pagination use such a strange param which is incompatible with fluid syntax

I tried to explain it in my last paragraph. You're dealing with parameters that are neither static nor configurable but only handled internally. They are created internally and resolved internally. And that's the reason why you should not use them: Because they might change "suddenly" and you don't know what happened. Formally, one could say "they are not part of the public API".
This is imho not a problem of Fluid, nor is it a problem of the paginate itself. It's a general thing to address internal variables that aren't meant to be used by other things then the core.

The basic thing you're trying to solve is: How can I address Widget ViewHelpers from the outside. This *is* a problem of Extbase/Fluid, but not of its syntax but of its concept and design. And this is not possible, currently. So I wouldn't call it a problem but a missing feature. An important one, since you're clearly not the only one trying to call ViewHelpers from the outside, but still a missing feature.


Regards,



Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Website: media.netlogix.de



- --
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Internet: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt



- -----Ursprüngliche Nachricht-----
Von: typo3-english-bounces at lists.typo3.org [mailto:typo3-english-bounces at lists.typo3.org] Im Auftrag von bernd wilke
Gesendet: Montag, 16. September 2013 14:30
An: typo3-english at lists.typo3.org
Betreff: Re: [TYPO3-english] How to insert additionalparams with more than 2 level for f:link.page

Am 16.09.13 13:06, schrieb Stephan Schuler:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hey there.
>
>
> I guess the problem is *not* related to hierarchical parameter processing and overruling.
> It's related to general Fluid array syntax, especially the thing where array keys are detected.
>
> You cannot use "special characters" such as "@" as part of array keys in Fluid.
> Try those:
>
>> <f:debug>{widget_0:'{currentPage: \'xxxxx\'}'}</f:debug>
>> <f:debug>{@widget:'{currentPage: \'xxxxx\'}'}</f:debug>
>
> The first will output a properly formatted array, such as "array('widget_0' => array('currentPage' => 'xxx'))".
> The second one creates the flat string instead, since it's no valid array notation in Fluid.
>
> So, you most likely will not be able to use "@widget_*" as link parameters.

which means: you are very much restricted in the the use of indizes to URL parameters by fluid :-((((

 >
> Writing those kind of links isn't necessarily unreadable. The only thing that makes it feel a bit clumsy is escaping. Besides that, using some line breaks and indention isn't that ugly.

it's not the readability but the correct working.

>> <f:debug>{
>>      0: 'fooo',
>>      1: 'bar',
>>      foo: '{
>>          key: \'value\',
>>          key2: \'{
>>              key3: \\\'value2\\\'
>>          }\'
>>      }'
>> }</f:debug>

this might make it more readable for humans, but the result will be full of whitespace AND #10(LF) in inappropiate positions as this is not removed by fluid.
you will find a lot of empty (just whitespace) lines in the newer TYPO3 generated websites as fluid-templates are used and fluid only removes fluid-control-tags but no whitespace/linebreaks around.

>
> Ok, I must admit that using own view helpers that take individual arguments for that is better in terms of usability. It is both, better readable and less error prone since you cannot mistype argument names without Fluid exceptions.
> But using individual view helpers that extend existing ones for each and every one-hit situation usually feels a bit like xclassing of former days. That's useful in some cases, but I would not go using it as golden hammer.
>
> But since you clearly want to have this "@widget_0" argument name here, you might have no other chance.

as I want to use the pagination of tx_news the URL-params are defined by tx_news and so the base viewhelpers.
rebuilding all new means ignoring or rewriting tx_news.

on the other hand: why do the pagination use such a strange param which is incompatible with fluid syntax ???


> You could try the PaginateViewHelper instead. That one comes with proper link building. This way you could completely avoid accessing the "@widget_*" property, which isn't good ad all because you cannot rely on having "_0" as suffix forever.

on the other page I use the PaginateViewhelper, which works well. but on
'this' page I need to generate Links to all the paginate-pages which did
not work.
so I tried to generate the links by hand. and failed again. :(

bernd
- --
http://www.pi-phi.de/cheatsheet.html
_______________________________________________
TYPO3-english mailing list
TYPO3-english at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.3.0 (Build 9307)
Charset: utf-8

wpUDBQFSNwRMpp0IwsibV8MBCJHHBACHz0DD3clMoHyrK5aW2V34LgD7ZIDMSSCv
9t5kzfQQOF3Lc/BUPpLEqPsPjd+8cqgS9PVQnw27OZu5MnxE/j4b4hApT29f1vex
nBtKIT+/0MaiYGXyinboQzAV28Qx+TsMVn0EKn+XLiHRkGOrPgYsUOaCrc0M8CR3
3VfEe3XnJg==
=pBMj
-----END PGP SIGNATURE-----