Возвращение массива в USER_INT userFunc приводит к выводу <! - INT_SCRIPT - PullRequest
Новая
       15

Возвращение массива в USER_INT userFunc приводит к выводу <! - INT_SCRIPT

0 голосов
/ 05 июня 2019

У меня есть userFunc, которому я звоню через 

lib.random = USER_INT
lib.random {
  userFunc = My\Plugin\UserFunc\Functions->random
}

когда я возвращаю массив и пытаюсь получить к нему доступ, это не удается. 

<v:variable.set name="random" value="{f:cObject(typoscriptObjectPath: 'lib.random')}" />
{random.max}

Когда я пытаюсь отладить его, я получаю <!--INT_SCRIPT строку

Кто-нибудь знал проблему и решение?

/ е:

Я хотел бы прояснить проблему, описав сценарий.

У меня есть плагин с формой входа. Когда пользователь входит в систему, я устанавливаю JWT с различной базовой информацией (имя, адрес электронной почты). Эта информация должна отображаться в разных местах по всему Веб-сайту, а не только на одной странице (например, страница профиля). Некоторые дела - это предварительно заполненные формы или просто глупые слова «Привет, Пол».

Поэтому, когда я впервые захожу в систему (Свежий браузер, нет кеша), то после выхода из системы я читаю «Привет, Пол» и захожу с другой Учетной записью (назовем это «Питер»), а затем по-прежнему пишется «Привет». Пол ", ни" Привет, Питер ". Когда я очищаю кеш браузера, все в порядке.

Может быть, это поможет, может быть, решить мою дилемму. :)

Ответы [ 2 ]

0 голосов
/ 05 июня 2019

TL; DR: некэшированные детали в TYPO3 заменяются в сгенерированной строке вывода страницы с помощью маркеров и не могут связываться в указанном здесь направлении.Выборочное кэширование, отключение кэширования или отсоединение данных от основного запроса (с XHR или другим) являются единственно возможными методами.

Должно быть ясно, что USER_INT достигает своей функциональности путем замены строки всгенерированное тело страницы .Это означает, среди прочего, что:

  • Вы никогда не можете передать вывод USER_INT чему-либо в Fluid, даже если вся страница не кэширована.Вы фактически передадите строку, содержащую <!---INT_SCRIPT... (весь маркер).
  • Однако вы можете сгенерировать USER_INT из Fluid, который заканчивается на сгенерированной странице, которая затем заменяется визуализированным объектом (используйте f: cОбъект для рендеринга USER_INT или COA_INT).

Далее приводятся соображения по поводу варианта использования.Прежде всего, cookie (на практике) изменяет параметры запроса и должен быть частью идентификатора кэша, который использует ваша страница (по умолчанию это не так).Во-вторых, если указанный куки-файл изменяет способ отображения страницы (и это зависит от вашего варианта использования), это вызовет проблему при кэшировании страницы.В-третьих, изменение вывода страницы в зависимости от файла cookie указывает, возможно, на конфиденциальную информацию или, по крайней мере, на информацию, относящуюся к конкретному пользователю.

Принимая во внимание вышеизложенное, ваш вариант использования должен выполнять одно из следующих действий:

  1. Либо отображать весь фрагмент вывода, который изменяется в зависимости от cookie, как USER_INT.Это означает обертывание всего вывода Fluid и рендеринг всего этого без кэширования.Обратите внимание, что компиляция шаблона все еще происходит (и вы можете использовать f: cache.static для жесткого кэширования определенных частей, если они никогда не изменяются в зависимости от параметров запроса).
  2. Или добавьте значение cookie на cHash (страницахэш-значение), так что наличие установленного cookie означает, что вы запрашиваете конкретную кэшированную версию, которая соответствует cookie.Это предпочтительный способ, если значения вашего файла cookie, как правило, одинаковы для многих пользователей (например, он содержит выбранного контактного лица из ограниченного списка и сохраняет его в файле cookie).
  3. Или, в случае, если ваш выводсодержит действительно конфиденциальную информацию. Требуется, чтобы элемент содержимого или страница были доступны только при входе в определенную группу.Это имеет две цели: во-первых, он защищает страницу от просмотра без аутентификации, но во-вторых, он также делает содержимое страницы не кэшируемым или не кэшируемым с помощью идентификатора пользовательской группы внешнего интерфейса как части идентификатора кэша .
  4. Выполните рефакторинг для запроса XHR и сделайте для любой конечной точки, которую он использует, USER_INT или вручную отключенный контекст кэширования, затем загрузите данные.Или установите фактические данные в файле cookie, затем используйте JS для вставки значений, где это необходимо.

Надеюсь, это проясняет различные контексты и почему они не могут общаться в том направлении, в котором вы пытаетесь;даже если они обмениваются строками вместо массивов.

См. также: .cache подобъект в TypoScript, в котором вы сможете создать уникальный идентификатор кэша для варианта использования 2, описанного выше.

0 голосов
/ 05 июня 2019

USER_INT не кэшируются, поэтому значения для этого заменяются после создания кэша.

Я думаю f:cObject - неправильный путь. Реализация собственного ViewHelper для получения тех же данных должна быть лучшим способом. 

<?php
namespace My\Plugin\ViewHelpers;

use TYPO3Fluid\Fluid\Core\Rendering\RenderingContextInterface;
use TYPO3Fluid\Fluid\Core\ViewHelper\AbstractViewHelper;
use TYPO3Fluid\Fluid\Core\ViewHelper\Traits\CompileWithRenderStatic;

class RandomViewHelper extends AbstractViewHelper
{
    use CompileWithRenderStatic;

    /**
     * @var boolean
     */
    protected $escapeOutput = false;

    /**
     * @param array $arguments
     * @param \Closure $renderChildrenClosure
     * @param RenderingContextInterface $renderingContext
     * @return string
     */
    public static function renderStatic(
        array $arguments,
        \Closure $renderChildrenClosure,
        RenderingContextInterface $renderingContext
    ) {
        return rand();
    }

}

Теперь вы можете использовать его следующим образом: 

{my:random()} or <my:random />
...