2016-12-31 9 views
4

Если я хочу использовать TypoScript как поколение меню в шаблоне жидкости у меня есть два возможных пути:Каково наилучшее использование typoscript в жидкостных шаблонах?

  • используют TypoScript, чтобы заполнить переменную для шаблона. делает это так:

    page.10 = FLUIDTEMPLATE 
    page.10 { 
        templateName = index.html 
        // ... define pathes ... 
        variables { 
         contentMain < styles.content.get 
         mainMenu < temp.mainMenu 
         : 
        } 
    } 
    

    и в шаблоне просто использовать переменную:

    <div class="header"> 
        <div class="logo">{logo->f:format.raw()}</div> 
        <div class="main-menu">{mainMenu->f:format.raw()}</div> 
    </div> 
    
  • другим способом является использование в е: CObject ViewHelper называть часть TypoScript.
    TypoScript:

    page.10 = FLUIDTEMPLATE 
    page.10 { 
        templateName = index.html 
        // ... define pathes ... 
        variables { 
         contentMain < styles.content.get 
         : 
        } 
    } 
    lib.mainMenu < temp.mainMenu 
    

    в то время как шаблон жидкость выглядит следующим образом:

    <div class="header"> 
        <div class="logo">{logo->f:format.raw()}</div> 
        <div class="main-menu"> 
         <f:cObject typoscriptObjectPath="lib.mainMenu /> 
        </div> 
    </div> 
    

так. Мой вопрос: каковы плюсы и минусы каждого из них?
Существуют ли различия для разных версий TYPO3?

ответ

4

Я не согласен с мнением pgampe как существуют большие различия относительно этих 2 подходов!

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

  • У вас есть несколько тяжелых плагинов USER_INT на странице в столбце, который не используется (больше). они будут по-прежнему вызываться, хотя они никогда не отображаются.
  • Вы используете EXT: новости и функции ExcludeDisplayedNews. Если есть новостной плагин, который каким-то образом передается через переменные (но никогда не выводится), новостной плагин, который отображается и отображается, будет пропускать записи новостей.
+1

Эта информация, я думаю, жизненно важна для упоминания каждый раз, когда упоминаются данныепроцессоры. Это, довольно просто, побочный эффект частей предварительного рендеринга. Моим личным советом было бы придерживаться тяжелого рендеринга в шаблонах Fluid - вообще говоря, это означает, что вы избегаете dataProcessors и используете ViewHelpers, например, из пакета VHS или тех, которые вы пишете сами. Или просто объекты TS старой школы, которые вы затем визуализируете с помощью f: cObject (который не страдает от проблемы «должен сделать все заранее»). –

2

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

Элементы, которые визуализируются в зависимости от других значений записей, лучше использовать с помощью режима просмотра cObject.

Технически нет большой разницы, если результат кэшируется в кеше страницы. Этот метод предпочитает только вопрос вкуса и удобочитаемости.

Оба метода могут использовать dataProcessors для возврата массивов или объектов, которые могут быть итерированы или обработаны иным образом в шаблоне. Специально для создания меню, в предстоящем TYPO3 8.x LTS будет процессор меню, который выплескивает меню в виде массива. См. Функцию #78672 (прилагается с TYPO3 8.5). Если вы используете что-то подобное, я предлагаю всегда передавать его как переменную. Это делает его более понятным и не скрывает его в шаблоне.

https://docs.typo3.org/typo3cms/extensions/core/8-dev/Changelog/8.5/Feature-78672-IntroduceFluidDataProcessorForMenus.html

+0

Я вас понял?части страницы, которые зависят от данных текущей страницы, должны использоваться в качестве переменных шаблона. например все данные из записей страниц, меню (по крайней мере до 8) и весь контент (tt_content) из всех столбцов. «Безусловно»? как насчет состояния языка или других условий, которые вы обычно оцениваете как условия типизации? каково поведение во время выполнения для неэкранированного рендеринга? Я принимаю неправильные значения для VH-вызовов вместо переменных шаблонов. –

+0

Теоретически, ViewHelpers должны превосходить TS dataProcessors на каждом шагу с одним возможным исключением: после сброса системного кеша необходимо перекомпилировать шаблоны Fluid, что вызывает замедление при первом рендеринге. После чего ViewHelpers будут выполняться только тогда, когда они фактически будут отображаться и будут выполняться как прямой PHP, никакого анализа не будет. Настройка на основе DataProcessor полностью неспособна к этой селективности и будет исправлять меня, если я ошибаюсь, повторно выполнять этот TS постоянно, как и f: cObject. Если производительность является вашей метрикой, то любое решение, которое раздувает TS, не рекомендуется *. –

+0

Это зависит от того, предпочитаете ли вы использовать метод push или pull при шаблонизации. Надвигающийся подход, вероятно, приводит к тому, что генерируется слишком много данных, тогда как подход pull имеет тенденцию загромождать (см. Wordpress) шаблон и затрудняет отслеживание зависимостей. – pgampe