По мере того, как новые функции будут завершены, я дополню их короткими специализированными статьями, которые дадут разработчикам и пользователям знания о том, чего ожидать при обновлении до Fluid 3.0, а также вдохновят вас на новые способы структурирования ваших проектов с использованием Fluid.

У нас было две основные темы на семинаре:

1. Документация
2. Разработка: в частности, сокращение и объединение API-интерфейса Fluid для разработчиков и пользователей.

Прежде всего, я хотел бы поблагодарить Systime за их давнюю преданность TYPO3 и за щедрое предложение гостеприимства, времени, еды и всех усилий, которые были направлены на координацию семинара! Еще одно спасибо Unikka за спонсирование раунда пиццы и Феликсу Якоби за спонсирование кофе для наших участников. Моя компания, NamelessCoder, спонсировала посещение ресторана, но это я говорю спасибо участникам, а не наоборот.

Обзор и результаты семинара Fluid 3.0

Улучшение документации Fluid

• Мы выбрали стратегию использования целевой страницы и разделили документацию Fluid на две основные части: быстрая документация по началу работы для привлечения новых пользователей и ознакомление их с синтаксисом и т.д. И более обширная документация по API для старых и новых разработчиков, которым требуется расширить Fluid такими вещами, как пользовательские ViewHelpers
• Мы исследовали, как улучшить файлы XSD, сгенерированные Fluid, с помощью документации ViewHelper, чтобы быть намного более информативными и точными в отношении типов аргументов (добавление таких вещей, как имена классов PHP, в стандартный набор свойств XSD, таких как string, integer и т.д.)
• Мы также обсудили цель рендеринга дополнительной документации Fluid в файлы XSD. Например, манифест файлов шаблонов и их обязательные аргументы
• Мы кратко затронули стратегию документирования различий, которые будут представлены в Fluid 3.0, таким образом, чтобы их было легко использовать для любого мигрирующего. Например, предоставляя им документ типа «если вы сделали это раньше, вам нужно сделать это сейчас», чтобы перечислить новые практики, которые 1:1 заменяют старые практики.

Улучшения в разработке Fluid

• Мы ввели строгие типы в максимально возможном количестве мест с наименьшим количеством критических изменений для пользователей. Эта работа также выявила ряд небольших проблем с тестами, и позволила нам улучшить как код, так и тесты.
• Мы усовершенствовали решение, чтобы заменить использование регулярных выражений в Fluid. Исторически сложилось так, что на Fluid повлияло несколько проблем, связанных с регулярными выражениями, и недавно была обнаружена пара серьезных проблем. Новое решение больше не будет использовать регулярные выражения для разделения шаблонов, вместо этого будет реализовано гораздо более линейное и независимое от платформы решение. Это новое решение также облегчает несколько новых функций, которые будут описаны более подробно позже
• Мы обсудили возможные жизнеспособные альтернативы довольно сложной логике, которую Fluid использует для компиляции шаблонов в классы PHP, что, в свою очередь, позволило бы упростить ViewHelpers, чтобы больше не различать скомпилированные/некомпилированные состояния выполнения, и, в свою очередь, уменьшить сложность API-интерфейсов ViewHelpers.
• Затем мы начали работу по унификации внутреннего API Fluid. Эта работа является предшественником некоторых важных функций Fluid 3.0, например, параметризованных шаблонов и разделов. Мы не смогли закончить эту часть, но продолжаем эту тему после семинара
• Мы подготовили переименование пакета Fluid Composer в Typo3 / Fluid-Engine. Чтобы получить больше информации, следите за этими изменениями!

После семинара я продолжил работать над всем, что обсуждалось и планировалось во время сессии. Эта работа в настоящее время почти завершена и в итоге стала более или менее полной перепиской каждой части Fluid с нуля.

Заглядывая вперед: Fluid 3.0 Устаревшие и лучшие практики

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

• Сильное изменение для решения проблем синтаксического анализа: это было наиболее критично, и необходимо было срочное изменение, потому что анализатор шаблонов был полностью переписан. Разрывное изменение влияет на случаи, когда ранее вам приходилось намеренно нарушать обнаружение синтаксического анализатора. Например, при написании объектов JS может потребоваться выполнить что-то вроде <f:format.raw>{</f:format.raw>, чтобы избежать открывания фигурных скобок. Обратите внимание, что это конкретное использование теперь вызывает ошибку синтаксического анализа! Это влияет только на этот вариант использования и только при использовании на открывающей фигурной скобке. Если вы использовали его вокруг закрывающих фигурных скобок, не должно быть никаких проблем. Причина в том, что синтаксический анализатор Fluid теперь чувствителен только к последовательности и не может быть намеренно нарушен вложенными тегами. В будущем, встроенные выражения, которые не нужно анализировать как Fluid, можно экранировать, просто добавив обратную косую черту впереди. Например, запись \{“foo”: “bar”} означает, что содержимое curlies будет восприниматься буквально как строка.
• Fluid больше не использует кеширование. Область действия Compiler удалена, и методы compile() больше не будут вызываться. Версии шаблона класса PHP не создаются, и в шаблоне используется только одно представление шаблона или компонента (ViewHelper или другое). Это также означает, что нет разогрева кэша: могут быть добавлены новые методы для настройки Fluid с полными картами классов и файлов, чтобы сделать поиск статичным, но влияние будет незначительным.
• Вся концепция различных частей, макетов и шаблонов устарела. Эта трехсторонняя концепция сводится к одной концепции: Atoms. Новая концепция служит той же цели, что и частичные варианты и макеты.
• Вся область представления - интерфейсы, абстрактные классы и класс TemplatePaths - устарели. Fluid 3.0 больше не будет навязывать какие-либо решения о том, как будет отображаться шаблон. Вся эта область действия заменяется классом FluidRenderer, который принимает имя файла в качестве точки входа. Только файл и контекст, никакой ориентации MVC или чего-либо еще. Это в сочетании с концепцией Atoms полностью заменяет старое разрешение шаблонов Fluid и макетирование / частичное использование.
• Больше нет шаблонных препроцессоров, а сама функция удалена.
• ViewHelpers полностью переработан и предлагает множество новых возможностей. Наиболее важным изменением является удаление устаревших свойств «templateVariableContainer» и «viewHelperVariableContainer», которые теперь должны быть доступны через RenderingContext.
• Методы render() и renderStatic() для ViewHelpers теперь считаются устаревшими. Вместо этого ViewHelpers может реализовывать метод evaluate(), который принимает аргумент RenderingContext. Это будет внедрение наилучшей практики в будущем
• Начиная с версии 3.0 использование render() или renderStatic() приводит только к затратам при выполнении, с точки зрения циклов CPU и объема памяти.
• Базовый класс для ViewHelpers все еще существует, но теперь он является необязательным. Теперь он предоставляет только служебные методы и поддержку старых методов ViewHelper, таких как render(). ViewHelper может теперь расширять AbstractComponent или вообще не использовать базовый класс, а затем полностью изменять каждый метод API
• InterceptorInterface был удален. На перехват больше нельзя воздействовать, например, без его реализации в качестве ViewHelper. Экранирование теперь является встроенной и включенной по умолчанию функцией, которую необходимо явно отключить при настройке.
• Выражения больше не отделены от ViewHelpers. ViewHelper может реализовать новый интерфейс, чтобы сигнализировать, что он также работает как выражение (например, выражения math {foo + 1}), и когда Fluid анализирует выражение, он просто создает соответствующий экземпляр ViewHelper. Это означает, что ViewHelper работает как выражение и как ViewHelper. Например, Math работает как {foo + 1}, но также как {f:expression.math(a: foo, b: 1, operator: ‘+’)} для более сложных случаев использования.
• Это не совсем удаление или устаревание: экранирование кавычек во вложенном встроенном синтаксисе больше не нужно вообще. Fluid 3.0 игнорирует такое экранирование и поэтому совместим, но новые шаблоны могут быть написаны независимо от экранирования кавычек. Последовательность сама по себе имеет значение, т.е. ваши пары кавычек должны совпадать, но вы можете использовать одинаковый тип кавычек на всех уровнях вложенности.
• Существуют и другие не упомянутые здесь исключения, но все они влияют на API, который никогда не считался действительно общедоступным.

Использование замещенных функций

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

• Атомы (Atoms) это новая концепция, чтобы заменить части (partials) и макеты (layouts). Атом может работать как макет, и как часть, в зависимости от того, что он содержит и где он используется. Атомы регистрируются так же, как ViewHelpers, чтобы принадлежать пространству имен, и каждое пространство имен затем имеет несколько путей файловой системы, где будет выполняться поиск. Когда Atom используется в шаблоне, который не содержит ничего, кроме разделов, он работает как макет сегодня. Когда используется где-то внутри шаблона, он работает как часть. Основное отличие состоит в том, что Atom можно создать так, чтобы он содержал только разделы, и при использовании это приводит к тому, что разделы импортируются в текущий шаблон (и можно перезаписывать, определяя новые разделы с тем же именем). Практические примеры этой новой концепции будут представлены перед выпуском. Суть в том, что f:layout и f:render устарели, как и partialRootPaths, и все остальные коллекции путей к шаблонам.
• Например, Atom может существовать в res/atoms/myAtom.html. Регистрация пространства имен Atom «foo» по пути res/atoms/ означает, что <foo:myAtom> в Fluid отображает или импортирует шаблон и разделы внутри, или заставляет его работать так же, как сегодня работает макет. Эти массивы путей поддерживают несколько путей и могут быть расширены таким же образом, как «частичные пути», как расширяются сегодня.
• Редко используемые переключатели, такие как {escape-off}, теперь должны быть записаны как {@escaping off}, иначе они будут игнорироваться. Риск их фактического использования в реальных проектах очень низок, и вы сразу узнаете, влияет ли это на вас. Единственное исключение - {namespace xyz=Foo\Bar}, которое имеет специальную обработку (устарело, удалено в 4.0). В будущем они должны быть записаны как {@namespace xyz=Foo\Bar}
• Извлечение пространства имен из (X) узлов HTML теперь работает только для тегов <html>, но, кроме этого, оно работает точно так же, как и раньше. Если вы использовали <div xmlns:f=“…”>, вам нужно будет заменить его на <html>

Хорошей новостью является то, что существует невероятное количество новых функций синтаксиса, которые полностью совместимы со старым синтаксисом, но предоставляют множество новых способов объявления массивов, упрощенного встроенного синтаксиса, обработки ванильных (X) HTML-тегов. с классами ViewHelper и многое другое.

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

Релиз Fluid 3.0 в настоящее время не запланирован. Предполагается, что он не будет использоваться в v10 LTS и, скорее всего, не станет зависимостью от TYPO3 до разработки v11, что следует почти сразу после выпуска v10 LTS.

Я надеюсь, что вы теперь хорошо информированы и уведомлены обо всех положительных событиях для Fluid 3.0. Посмотрите другие статьи для пользователей Fluid 3.0.

Вы также можете изучить обзор семинара от команды документации для получения дополнительной информации.

 
Вычитка: Amy Hunt