Да, выкладки, в основном, теоретические. Но вот число подключаемых скомпилированных шаблонов при рендеринге страницы при нынешнем подходе (порядка 40 файлов) — это вполне себе реальная цифра. И то, что их число уменьшится — это тоже однозначно так. Как это реально отразится на скорости — хз
Чтоб проверить все это на практике, нужно сделать две верстки — «кусочную» и «блочную» — одного и того же дизайна. Причем, не просто тест, а реальную верстку, чтоб по полной все отработало в обоих случаях. Только так проверить можно. Но захочет ли кто-то на это угрохать кучу времени? ;)
Но тут еще есть плюсы, правда, не такие очевидные: напр., будет, как минимум, один файл (макет), в котором видна вся HTML-структура страницы. И все шаблоны будут иметь правильную DOM-структуру, т.е. не будет такого, что какой-то тег открывается в одном шаблоне, а закрывается в другом, что нередко нехилого гемора добавляет.
Мысль понял. Но согласно синтаксису Smarty, если шаблон начинается с директивы {extends ...}, то в этом шаблоне все, что лежит вне блоков просто игнорируется. Поэтому избавиться от объявления блоков просто так не получится.
И вот жесткой привязки нет. Напр., в наследуемом шаблоне можно и так прописать:
У меня нет готового решения. Но ведь цепочка экшенов тоже может быть какой угодно длинной, и эта проблема успешно решается. Так и тут наверняка можно найти решение.
Я этот механизм блоков не сам придумал, это «родной» механизм Smarty, который введен в третьей версии (еще три года назад). Я лишь попытался объяснить, как это можно более эффективно использовать.
Безымянные блоки в Smarty не предусмотрены, поэтому блоки нужно объявлять явно, как в шаблонах-родителях, так и в шаблонах-потомках.
Что касается названий самих блоков в моих примерах, то они тоже не «от балды» даны, это влияние методологии БЭМ, о которой рассуждали до этого. Поэтому, если говорить шире, я постарался совместить тут два понятия «блоки» — и от БЭМ, и от Smarty. Т.е. это термин «двойного назначения», и класс БЭМ-блока совпадает с именем Smarty-блока:
Здесь <section class=«b-content»> — это для CSS-классов,
а {block name=«b-content»} — для наследования шаблонов.
Пример в топике сильно упрощен. А на деле практически все теги типа <section class=«b-...»> должны внутри себя содержать Smarty-блоки {block name=«b-...»}, где класс секции и имя блока совпадают
Если опустить логические моменты (что тоже важно), то, как минимум, блочная верстка с наследованием должна работать быстрее, т.к. Смарти в этом случае собирает (в идеальном варианте) один итоговый компилированный шаблон. А в случае с ленточной версткой компилируется каждый включаемый шаблон по отдельности, и при выводе они все последовательно инклудятся.
При этом надо понимать, что при нынешнем подходе почти в каждом инклуд-шаблоне есть куча своих инклудов. И в итоге вывод одного, казалось бы, скомпилированного шаблона — это чтение с диска нескольких десятков файлов, которые нужно инклудить друг в друга.
Разумеется, при блочной верстке инклуды тоже могут иногда использоваться (не нужно все доводить до абсурдного абсолюта), но все же есть основания считать, что их будет на порядок меньше. А это значит, что число дисковых операций только на одних шаблонах можно уменьшить раз в десять.
Однажды у великого скульптора Микеланджело спросили о том, каким образом ему удается создавать такие восхитительные скульптуры. Он сказал в ответ: «Я беру камень, а затем просто отсекаю все лишнее».
А, повторюсь, соотношение донейта на скачано сидит возле 0.
Ради интереса прикинул сейчас: суммарное количество скачиваний моих бесплатных плагинов только из каталога ЛС — более 20 тыс. Сумма донейта через каталог ЛС — 30$. Итого — 0.0015$ на скачивание :)
Трудно сказать. Наверное, в первую очередь, в том, что понимаю и принимаю концепцию движка (именно концепцию, а не техническую реализацию, к которой часто бывают претензии). Почему-то я очень быстро понял, как устроен движок, и что и где нужно менять/добавлять/убирать, чтоб получить тот результат, который нужен. А так же то, почему иногда нельзя получить желаемого результата )
И это все настолько хорошо укладывается в голове, что ответ на вопрос «Как сделать это?» рождается, как правило, гораздо быстрее, чем при работе с другими движками.
Так же постоянные конфликты с плагинами. WP в этом плане просто идеально спланирован для конечного юзера
Я, конечно, давно не делал на WP серьезных проектов, но в свое время этих конфликтов в Вордпрессе нахлебался выше крыше. А уж когда возникала необходимость что-то свое допилить-доработать, не трогая ядра, то такие пляски с конями начинались, что мама не горюй
Вопрос, думаю, не в том, что нельзя найти ответы на какие-то вопросы (самостоятельно ли, в инете ли, в общении ли), а в том, комфортно ли с каким-то движком работать или нет. Я про ЛС узнал, когда очень неплохо понимал нутро WP, и дня три уже плотно ковырялся с Джумлой, проектируя новый сайт. Скачав и поковырявшись с ЛС пару часов, я понял, что мне работать с ним комфортно, чего я не мог сказать ни про Джумлу, ни про Друпал.
Конечно, у меня много претензий к ЛС и сейчас, и неоднократно приходилось какие-то вещи делать через анус, но работать с ним мне все равно комфортней, чем со многими другими движками
{* display value of page from URL ($_GET) http://www.example.com/index.php?page=foo *}
{$smarty.get.page}
{* display the variable "page" from a form ($_POST['page']) *}
{$smarty.post.page}
{* display the value of the cookie "username" ($_COOKIE['username']) *}
{$smarty.cookies.username}
{* display the server variable "SERVER_NAME" ($_SERVER['SERVER_NAME'])*}
{$smarty.server.SERVER_NAME}
{* display the system environment variable "PATH" *}
{$smarty.env.PATH}
{* display the php session variable "id" ($_SESSION['id']) *}
{$smarty.session.id}
{* display the variable "username" from merged get/post/cookies/server/env *}
{$smarty.request.username}
А о чем? Если юзер имеет OpenID-аккаунт, а ряд сайтов на ЛС имеют плагин регистрации/авторизации через OpenID, то этим как раз решается та проблема, о которой речь идет в топике. Разумеется, она решается именно для тех сайтов, которые реализовали у себя регистрацию через OpenID.
Кто то скажет есть OpenID, я например не хоче вешать на свой блог 1000 и один плагин...
Я не люблю вешать на свой сайт сотни плагинов...
Будем дальше уменьшать число плагинов, чтоб авторизация через OpenID на сайте работала? ;)
Чтоб проверить все это на практике, нужно сделать две верстки — «кусочную» и «блочную» — одного и того же дизайна. Причем, не просто тест, а реальную верстку, чтоб по полной все отработало в обоих случаях. Только так проверить можно. Но захочет ли кто-то на это угрохать кучу времени? ;)
Но тут еще есть плюсы, правда, не такие очевидные: напр., будет, как минимум, один файл (макет), в котором видна вся HTML-структура страницы. И все шаблоны будут иметь правильную DOM-структуру, т.е. не будет такого, что какой-то тег открывается в одном шаблоне, а закрывается в другом, что нередко нехилого гемора добавляет.
И вот жесткой привязки нет. Напр., в наследуемом шаблоне можно и так прописать:
и так:
Работать будет одинаково, т.к. порядок блоков тут не играет значения, они будут вставляться в родительском шаблоне туда, где изначально объявлены.
Это уже мое предложение — сделать стандартом жесткую связку HTML-блоков и Smarty-блоков в изначальном макете.
Безымянные блоки в Smarty не предусмотрены, поэтому блоки нужно объявлять явно, как в шаблонах-родителях, так и в шаблонах-потомках.
Что касается названий самих блоков в моих примерах, то они тоже не «от балды» даны, это влияние методологии БЭМ, о которой рассуждали до этого. Поэтому, если говорить шире, я постарался совместить тут два понятия «блоки» — и от БЭМ, и от Smarty. Т.е. это термин «двойного назначения», и класс БЭМ-блока совпадает с именем Smarty-блока:
Здесь <section class=«b-content»> — это для CSS-классов,
а {block name=«b-content»} — для наследования шаблонов.
Пример в топике сильно упрощен. А на деле практически все теги типа <section class=«b-...»> должны внутри себя содержать Smarty-блоки {block name=«b-...»}, где класс секции и имя блока совпадают
При этом надо понимать, что при нынешнем подходе почти в каждом инклуд-шаблоне есть куча своих инклудов. И в итоге вывод одного, казалось бы, скомпилированного шаблона — это чтение с диска нескольких десятков файлов, которые нужно инклудить друг в друга.
Разумеется, при блочной верстке инклуды тоже могут иногда использоваться (не нужно все доводить до абсурдного абсолюта), но все же есть основания считать, что их будет на порядок меньше. А это значит, что число дисковых операций только на одних шаблонах можно уменьшить раз в десять.
Аргумент? ;)
Но вообще, под блочной в данном случае я имею ввиду «блочную с наследованием», т.е. когда используются блоки и механизм наследования Smarty.
А ленточная — это нынешний подход, когда есть много-много кусочков шаблона, а потом они собираются в один окончательный шаблон инклюдами:
Так что бери ЛС и отсекай лишнее
И это все настолько хорошо укладывается в голове, что ответ на вопрос «Как сделать это?» рождается, как правило, гораздо быстрее, чем при работе с другими движками.
Конечно, у меня много претензий к ЛС и сейчас, и неоднократно приходилось какие-то вещи делать через анус, но работать с ним мне все равно комфортней, чем со многими другими движками
И подумал, что, возможно, в этом что-то есть. Я не очень верстальщик, но программист — перешел с WP на LS
Будем дальше уменьшать число плагинов, чтоб авторизация через OpenID на сайте работала? ;)