links of f:widget:paginate result in "Request URI too long"
I recently had the problem that f:widget:paginate created URIs that were way too long. The links contained every option of every <select> field and totaled up to some hundred, since the application simply needs lots of (short) values in the <select>s.
Nothing helped to solve the problem...then I occasionally read "How to dynamically create objects" in the sub-forum Extbase MVC and I recognized that the problem is about the "__trustedProperties" variable. I did not recognize it earlier since such long query strings are not good to read at all. I concentrated on fixing the problem within the viewhelper itself before.
Still I don't know why it takes all values - even if none was selected - and I define it as mind-numbing bug of the viewhelper -.-
I know that there is a reason for having "__trustedProperties" and that its name does not include "trusted" for fun, but when it comes to "delete your applicaion" vs. "fix it somehow!" you might want to disregard that, too.
The snippet below deletes "__trustedProperties" and its value inside pagination links. Ahead this string, there is the name of your controller roughly defined by .+? so that you don't have to explicitly name it on every page, and after there are the values that must end with & based on the must-have-format of valid query variables ([^&]+ reads until the next & occurs).
It is jQuery but easily can be written in native JS by using document.getElementsByClassName() etc.
Re: links of f:widget:paginate result in "Request URI too long"
Update: the occurence of the error is not limited to this widget, since "__trustedProperties" contains to many values also if no paginator is used. Thus, the error must be somewhere around fluid/Classes/ViewHelpers/FormViewHelper.php and the setting/handling of the variable $formFieldNames in extbase/Classes/Mvc/Controller/MvcPropertyMappingConfigurationService.php and the function generateTrustedPropertiesToken() BUT ONLY IF the <select> has set the attribute "multiple" to "true". If this value is false, everything works just fine and not-selected <options> do not occur anywhere.
For some (very very bad or even no) reason, every part of the form is stored in "__trustedProperties" serialized, though storing every <option> of a <select> is totally useless since doesn't even contain values. Hence, it could not be used for anything, I guess.
Here is a snippet of the serialized "_trustedProperties" that will be added as encoded query string later on:
The array "corpusSigel" contains key->values that always have the form of number_of_current_index->1
That doesn't make sense to me - not at all. The ViewHelper needs to know what fields it should contain - fine. But it does not need to know how many unselected <option>s there are; especially so if it's without values.
TYPO3-english mailing list
[hidden email] http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english