Внимание! Данная запись отмечена как устаревшая и/или потерявшая актуальность! Возможно автор уже передумал и теперь придерживается другой точки зрения, нежели изложенная в тексте ниже.

Концепция: верстка HTML-страниц ячейками

Дневник / Вёрстка сайтов: CSS, HTML, LESSПросмотров: 18663 (207)

Верстальщики знают, делая первый сайт, мы позволяем себе разные вольности, например указать стили прямо в тэгах; вместо стиля с margin, добавляем BR и т.д. Второй сайт мы делаем лучше, ведь в голове копошится мысль, чтобы как-то систематизировать свои стили и HTML-разметку. На третьем сайте окончательно и бесповоротно рождается желание (кричащее все громче с каждым последующим сайтом) все унифицировать: и css-стили, и HTML-разметку.

Данная работа является скорее «мыслью вслух», чем какой-то конечной разработкой, поэтому просьба не устраивать холиваров и не высказывать своё «фи» не по поводу.

Любая web-страница имеет какую-то структуру. Обычно это блоки, расположенные определенным образом. Если мы, для примера, посмотрим на мой сайт, то увидим, что есть верхние два блока: название сайта, меню. Ниже следует блок сайдбара (с виджетами) и справа - основной текст. Замыкает страницу подвал с какой-то информацией.

Тут я хочу остановиться и сделать маленькое замечание. Давайте взглянем на сайт глазами «чайника», который вообще ничего не понимает в HTML. То есть нас совершенно не интересует каким образом все это сделано - нам просто важно как блоки расположены на странице.

Мысленно уберем все тексты и картинки и оставим только блоки. То есть сейчас мы не будем углубляться в то, что у них за содержимое, нас просто интересует их расположение.

Технически как правило, это тэги DIV. Для того, чтобы их выравнивать относительно друг друга, они делаются «плавающими» - float. Тут сложность в том, что DIV изначально не совсем были предназначены для такого поведения. Когда появилась поддержка CSS2 со стороны браузеров, то дело несколько улучшилось, но, опять же, есть проблема не совсем одинакового поведения «плавающих» блоков в разных браузерах. Наш горячо «любимый» Internet Explorer до сих пор имеет своё особое представление о поведении таких блоков и верстальщики вынуждены идти на массу ухищрений, чтобы как-то обойти все эти неурядицы.

Впрочем, сейчас речь идет не о браузерах, а о том, что мы пытаемся получить, располагая DIV'ы по странице. Ответ очевиден - ячейки в некой «каркасной» сетке/таблице.

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

Как я уже сказал, «плавающие» DIV'ы не совсем удобный «материал», поэтому стили для описания каркаса получаются довольно-таки громоздкими. На сегодняшний день, благодаря усилиям вебмастеров и разработчиков браузеров, мы имеем более-менее нормальную поддержку «плавающих» блоков и тему можно было бы закрыть, если бы не несколько «но».

Мы знаем, что в HTML давным-давно существует тэг TABLE. Почему же среди верстальщиков фраза «табличная верстка» стала чуть ли не ругательной?

От таблиц отказались по двум основным причинам. Во-первых, при верстке таблицами приходится оперировать столбцами и ячейками, поэтому HTML-код получается более сложным, за счет открытия/закрытия строк (TR). Кроме этого для таблицы нужно следить за количеством ячеек в каждой строке. В общем работа с таблицей требует более щепетильного отношения.

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

Теперь давайте расмотрим некоторые недостатки блочной (DIV) верстки по сравнению с таблицами.

Главный из них это то, что практически все плавающие блоки следует помещать в еще один блок-контейнер, поскольку (по определению) float-элементы браузер выводит из «стандартного» потока вывода и позиционирует «отдельно». Из-за разных браузеров как раз и возникает такая потребность. То есть на практике нужно добавлять еще много DIV, из-за чего увеличивается и HTML-разметка, и CSS-стили.

Также следует отметить и сложности с выравниванием парных блоков по высоте. На сегодняшний день разработано несколько методов, от «обманки» в виде фонового изображения, до дополнительных блоков (только ради этого) и специальных JS-скриптов.

С таблицами же таких проблем просто нет - они изначально и создавались с таким поведением. Так почему же мы отказываемся от специально разработанного TABLE и пытаемся получить эту же самую таблицу, но с помощью других тэгов?

Если сравнить количество тэгов и css-стилей для таблиц, то мы увидим, что их ничуть не больше, чем при блочной верстке. Это раньше мы видели массу вложений таблиц в таблицу, стили прямо в тэгах. Сейчас же ситуация принципиально другая - HTML-разметка точно такая же: с классами и id, а стили вполне компактные и понятные. И главное нет стилей/хаков/пр. для иммитации табличного поведения. Ну а про совместимость между браузерами можно легенды складывать. smile

Что же касается постепенного отображения, то этот недостаток можно списывать в утиль. Современные браузеры пытаются предугадать отображение таблицы и показывают её по мере загрузки. Если нет группированных ячеек, то отображение будет сразу корректным без переверсток.

Тут, кстати, как раз наоборот - проблема с блочной версткой. На медленном соединении, HTML успевает загрузиться раньше, чем CSS-стили. Если сверстать страницу на таблице, то расположение элементов будет сразу корректным, потому что таблица так устроена по определению. А при блочной верстке вначале увидим гиганскую ленту всех блоков один под другим, а уже по мере загрузки стилей, переверстку как положено. Такое поведение я часто встречаю на FireFox 3.5 (на других не проверял). (Но, если строго, то медленные соединения сейчас уже совсем не те, что пару лет назад, поэтому скорость загрузки страницы в браузере уже никто не учитывает.)

У табличной верстки есть еще один очень серьезный плюс - в ней никогда не будет «съехавших» сайдбаров.

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

Но табличная верстка меня заинтересовала не просто так. Создание сайтов моя основная работа. Большинство сайтов похожи друг на друга по своей HTML-разметке, различия только в CSS-стилях. И вот, чтобы каждый раз не изобретать велосипед, я придумал один HTML и несколько CSS-каркасов (что-то роде Zen Garden). Таким образом, когда я делаю новый сайт я смотрю под какую «модель» он подходит и копирую нужный CSS-файл.

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

Тут, собственно, и появилась идея - отказаться от HTML-верстки или хотя бы свести её к минимуму.

Конечно же HTML будет, но его не нужно будет верстать в привычном виде. Вместо создания HTML, нужно использовать PHP-функции, которые будут описывать, наполнять и выводить ячейки каркаса. Таблица для этой задачи подходит идеальным образом, поэтому я именно на ней и решил остановиться.

Впрочем, если у вас хватит знаний, то можно сделать что-то аналогичное и для блочной верстки.

Рассмотрим используемые функции.

  • grid_start(название сетки /это более правильно, чем таблица/, количество строк, количество столбцов) - задаем сетку.
  • grid_r_c(сетка, строка, столбец, файл/функция) - наполняем ячейку.
  • grid_end(сетка) - выводим сетку.

Теперь вернемся к блокам этого сайта и попробуем описать их с помощью моего метода:

grid_start('head', 1, 2);
grid_r_c('head', 1, 1, 'head1.php');
grid_r_c('head', 1, 2, 'head2.php');
grid_end('head');
  
grid_start('main', 1, 2);
grid_r_c('main', 1, 1, 'sidebar.php');
grid_r_c('main', 1, 2, 'main.php');
grid_end('main');
  
grid_start('footer', 1, 1);
grid_r_c('footer', 1, 1, 'footer.php');
grid_end('footer');

У нас будут созданы три TABLE: #head, #main и #footer. При этом автоматически будут проставлены все классы для всех строк и ячеек. То есть здесь мы лишь описываем каркас страницы, а дальнейшую кастомизацию и оформление делаем как обычно с помощью css-стилей.

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

Я намеренно не стал углубляться в тонкости и детали реализации функций «grid_» - это лишь пример, показывающий концепцию. В реальном проекте наверное можно дополнить функции прочими параметрами, как например произвольный класс, id, подключение не файла, а выполнение функции и т.д. Тут фантазия уже неограничена.

upd Вот пример из последней реализации. В ней функции grid_ сами решают какой генерировать код: таблицей или блоком. Если указана только одна ячейка, то это одиночный DIV. Если это один столбец, то это вложенные DIV'ы. Если несколько колонок, то это TABLE. В будущем, если получится, можно попробовать усложнить анализ, чтобы объединять ячейки и выводить какие-то блоки не таблицей, а блоками.

--- main-start.php
 
<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
 
require_once(getinfo('template_dir') . 'header.php'); 
 
grid_start('all', 1, 1);
    grid_r_c('all', 1, 1, 'ob_start');
 
    # шапка
    grid_start('header', 3, 1);
 
        grid_r_c('header', 1, 1, '', '
            <h1><a href="' . getinfo('siteurl') . '">' . getinfo('name_site') . '</a></h1>
            <h2><span>' . getinfo('description_site') .' </span></h2>
        ');
     
        grid_r_c('header', 2, 1, 'main-menu.php');
 
    grid_end('header');
 
    # середина
    grid_start('main', 1, 3);
 
        grid_r_c('main', 1, 1, 'sidebar-1.php', '');
        grid_r_c('main', 1, 2, 'ob_start');
 
?>
 
--- тут система выводит данные
 
--- main-end.php
<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
 
        grid_r_c('main', 1, 2, 'ob_end');
        grid_r_c('main', 1, 3, 'sidebar-2.php');
    grid_end('main');
 
    grid_start('footer', 1, 1);
        grid_r_c('footer', 1, 1, 'footer.php');
    grid_end('footer');
 
    mso_hook('body_end');
 
    grid_r_c('all', 1, 1, 'ob_end');
 
grid_end('all');
 
if (function_exists('ushka')) echo ushka('google_analytics');
 
?>
</body>
</html>

Комментариев: 21 RSS

1DVF22-10-2009 01:24

Давно использую css-framework.ru - перекрывает 90% надобностей.

2MAX22-10-2009 07:22

Да, и обратите внимание, что в разным css-фреймворках также происходит иммитация таблиц с помощью т.н. модульной сетки. Результирующий HTML ничем не проще, чем при обычном TABLE.

3Андрей Морковин22-10-2009 08:03

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

Но хедер и футер - это явные одиночные блоки, которые нужно верстать именно блоками (т.е. дивами).

Но разговор не об этом. Действительно интересный и правильный подход с использованием функции grid. Остается где-то взять нормальную функцию grid. А где ее взять? Написать самому?

И тут возникает вопрос, а зачем это нужно, если каркас самой страницы можно дернуть с http://csstemplater.com/, например. В каркасе будет, конечно, все путанно и сложно, но если поскрипеть мозгами в течении 10 минут, то можно раз и на всегда разобраться, найти нужные места и делать в них вставку остального наполнения.

Вобщем, если бы была нормальная функция grid с подробным описанием, я бы ей пользовался, потому что код получается более понятный. Пока функции нет буду использовать http://csstemplater.com/

4MAX22-10-2009 10:00

Но хедер и футер - это явные одиночные блоки, которые нужно верстать именно блоками (т.е. дивами).

Верно, там где используется одна ячейка лучше генерировать не TABLE, а DIV. Но пусть это останется на совести функций grid_.

А где ее взять? Написать самому?

Да, самому. Дело в том, что эти функции должны работать в рамках CMS, или хотя бы какой-то оболочки из PHP. Поэтому реализация функций будет немного отличаться. Например для вывода в MaxSite CMS я задал предопределенные парметры ob_start и ob_end, которые служат для буферизации вывода. Просто так устроен шаблон.

И еще. Традиционно нужно вначале построить HTML, а уже потом его «натягивать» на CMS. В предложенном способе все сразу делается в рамках CMS. На мой взгляд это гораздо быстрей и легче.

И тут возникает вопрос, а зачем это нужно, если каркас самой страницы можно дернуть с http://csstemplater.com/, например. В каркасе будет, конечно, все путанно и сложно, но если поскрипеть мозгами в течении 10 минут, то можно раз и на всегда разобраться, найти нужные места и делать в них вставку остального наполнения.

Верно, в основном так и делают. Получают каркас, потом его потрошат, добавляют нужные блоки, оформление и натягивают на CMS. В моем способе вы сразу определяете сетку и решаете чем будут заполнены ячейки. Ведь львинную долю HTML генерирует сама система. На долю верстальщика остается только сделать каркас и кастомизировать оформление. Думаю, что если мы поручим первую задачу программе, ничего страшного не произойдет. smile

5Philipp22-10-2009 10:55

Вообще такой подход вовсе не требует оязательного применения таблиц.

А еще насколько мне помниться, в таких конструкциях обеспечить горизонтальное выравнивание элементов по сетке не намного проще, чем в чисто div-ных фреймворках.

ЗЫ. съехавший сайдбар - это все-таки серьезное невладение материалом.

ЗЫЫ. все-таки модульную сетку придумали раньше табличной верстки, ибо она еще типографская. И именно ее и имитировали вложением таблиц или объединением ячеек, а теперь воспроизводят в фреймворках.

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

6Apathetic22-10-2009 16:46

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

Предыдущий комментатор абсолютно прав, говоря, что таблицы в верстке использовались как костыль для имитации модульной сетки. Да и вообще, верстать таблицами - значит возвращаться в прошлый, 20 век =)

С другой стороны, не могу не заметить частую необходимость табличной верстки под IE6 - в этом "раю" без таблиц часто бывает не обойтись.

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

P.S. Очень плохо, что анонимному комментатору никак нельзя подписаться на комментарии.

7MAX22-10-2009 17:18

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

Совершенно точно можно сказать, что говорите ерунду. RTFM.

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

Если вы вообще знаете (что-то я сомневаюсь), что такое модульная сетка, то таблицы как раз идеально подходят под эту роль. И если для таблиц нам не нужны костыли, то для div'ов их приходится использовать предостаточно.

Да и вообще, верстать таблицами - значит возвращаться в прошлый, 20 век =)

Из чего я делаю вывод, что вы вообще далеки от темы обсуждения. cool smirk

8Аноним22-10-2009 17:35

Совершенно точно можно сказать, что говорите ерунду. RTFM.

http://www.w3.org/TR/html401/ - вы про эти мануалы? Спасибо, читывал. Вместо тыканья пальцем лучше объясните, в чем заключается ерундовость моего высказывания? По-вашему, использовать таблицы для верстки страниц - семантично? О_о

И, да, я знаю, что такое модульная сетка, знаю, для чего она используется, и, вы не поверите (inb4 "вы правы, не верю"), знаю, как ее удобнее выстраивать. Если вам требуется расшифровка слова "имитация", то нате вам: таблицами, предназначенными для представления табличных данных, макет страницы можно только имитировать. Да, это будет выглядеть как надо, но по сути будет лишь имитацией того, что на самом деле должно быть.

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

9MAX22-10-2009 18:04

http://www.w3.org/TR/html401/ - вы про эти мануалы? Спасибо, читывал. Вместо тыканья пальцем лучше объясните, в чем заключается ерундовость моего высказывания?

Ну вот и почитайте мануалы, прежде чем нести околесицу. Таблицы такой же равноправный элемент в HTML, как и DIV. Более того, таблицы - куда более сложный элемент, чем примитивный блок, а некоторые свойства ячеек таблиц (например одна высота парных ячеек - более чем частая задача), вы если и сделаете, то гиганскими кусками css-стилей. Поройтесь и посмотрите, что для таблиц это элементарная вещь.

По-вашему, использовать таблицы для верстки страниц - семантично?

Вот и докажите, что верстка таблицами несемантично. Если вы уж такой их противник.

И, да, я знаю, что такое модульная сетка, знаю, для чего она используется, и, вы не поверите (inb4 "вы правы, не верю"), знаю, как ее удобнее выстраивать.

Уверен, что в этом вопросе, вы не в курсе. cool smirk

таблицами, предназначенными для представления табличных данных, макет страницы можно только имитировать.

Да, ну! А дивами по вашему не имитируем? Блоки вообще стандартно выводятся построчно и все манипуляции с float это попытка обойти это ограничение.

Если вы можете доказать, что верстать таблицами в конечном счете проще, удобнее и семантичнее, чем нормальными слоями, то честь вам и хвала.

При чем тут слои? Вы уж совсем запутались. oh oh Смею вас уверить, что для меня, как и для любого грамотного верстальщика, нет принципиальной разницы как сверстать, будь то div'ы или table. Если для вас это сложность, то могу посоветовать не плеваться, а учиться и набираться опыта.

10Apathetic22-10-2009 18:40

Вы продолжаете голословно заявлять о моей неграмотности. Совершенно непонятно, на чем основано ваше мнение.

Я вам так скажу: я действительно не понимаю, почему вы продолжаете спорить. Тема про блочную и табличную верстку обсосана уже до костей, и все подробно разжевано даже для таких упоротых, как я. А вы все спорите, да еще как-то по-детски. Ну что это, в самом деле: "Совершенно точно можно сказать, что говорите ерунду", "Если вы вообще знаете (что-то я сомневаюсь)" и далее по списку.

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

11MAX22-10-2009 19:04

Понимаете в чем дело. Я не могу, да и желания особого нет, объяснять и разжовывать азы и обьяснять прописные истины. Если вы считаете, что таблицы негодятся для построения каркаса страницы, то это ваше право. И хотя, я тоже предпочитаю верстать именно блоками, но это не значит, что табличная верстка - «прошлый век». К вашему сведению таблицы входят в спецификации HTML очень давно и их позиция нисколько не пошатнулась за последнее время. Поэтому говоря о «несемантичности» и «гвоздях» вы просто создаете о себе соответствующее мнение, но никак не доказываете, что таблицы хуже блоков.

Если бы в HTML был бы механизм построения модульной сетки, то все разговоры имели бы смысл. Я лишь пытаюсь донести мысль, что факты о «вредности» таблиц надуманы или неверны. Вы, например, написали много текста, но ни одного доказательства, почему нельзя использовать таблицы. И не сможете. wink

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

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

12Виталий23-10-2009 19:40

Сам в основу ложу таблицу, а уж потом верстаю по выбору. И с кросс-браузерностью, и с валидацией, и с семантикой не имею проблем.

13DVF24-10-2009 12:50

Таблицы действительно изначально предназначались для вывода табличных данных, а использовать их в основе вёрстки начали как раз из-за сложностей с дивами. Вообще как нужно использовать дивы хорошо видно на CSS-Zen-Garden.

14Комментатор 11924-10-2009 18:51

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

Вернекмся именно к помодульному выводу. То ли я вас не понимаю, то ли вы изобретаете велосипед.

В моем способе вы сразу определяете сетку и решаете чем будут заполнены ячейки. Ведь львинную долю HTML генерирует сама система. На долю верстальщика остается только сделать каркас и кастомизировать оформление.

Начнем сначала. Перед вами ПСДшка (работаем на заказ, так?). Дальше мы говорим верстальщику:

А. Порежь на свое усмотрение

Б. Даем ему сетку от фреймворка и говорим - порежь по ней, с такими-то классами

В. Сами накладываем свою сетку, делаем вывод со всеми своими классами и айдишниками, говорим верстальщику - порежь по этой сетке и напиши "оформительский" ЦСС и оптимизируй картинки. Это вы имеете в виду под своим способом?

Повторюсь - способ, при котором функция вывода последовательно принимает куски данных, пережевывает - оборачивает в оформление и отдает в вывод - реализован и весьма давно. По факту оказалось неудобным для использования - трудно менять и настраивать дизайн. Удобней оказался промежуточный вариант - куски выплевываются в хтмл - каркас, а функция обработки занимается в основном форматированием данных. Сответственно дизайнер с верстальщиком работают над каркасом, а программист подстраивает функцию вывода. Причем верстальщик может верстать под заранее известные классы (форматирование по умолчанию) -> редизайн может сводиться к замене каркаса и ЦСС.

15MAX24-10-2009 19:33

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

Абсолютно верно. Таблица жестко завязывает порядок вывода и поэтому переверстывать вручную довольно сложно. Но в моей концепции как-раз и задача решается в два счета. Ну например, было так:

grid_start('footer', 1, 2);
		grid_r_c('footer', 1, 1, 'footer.php');
		grid_r_c('footer', 1, 2, '', 'текст');
	grid_end('footer');

Это две ячейки в одной строке. Грубо говоря две колонки. Решили поменять их одну под другой. Стало:

grid_start('footer', 2, 1);
		grid_r_c('footer', 1, 1, 'footer.php');
		grid_r_c('footer', 2, 1, '', 'текст');
	grid_end('footer');

То есть мы просто задали сетку как нужно и определили, что в каждой ячейке должно выводиться.

Тут важным моментом является еще и то, что мы можем не просто задать сетку, но и завязать на неё вывод какого-то программного вывода. Например в MaxSite CMS в дефолтном шаблоне:

- шапка: название сайта, описание

- main-menu: какое-то главное меню (горизонтальное)

- основной текст

- сайбар/сайдбары с виджетами

- подвал.

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

В. Сами накладываем свою сетку, делаем вывод со всеми своими классами и айдишниками, говорим верстальщику - порежь по этой сетке и напиши "оформительский" ЦСС и оптимизируй картинки. Это вы имеете в виду под своим способом?

Почти. Я всё-таки исхожу из того, что верстальщик сам решает какую сетку использовать и как разбить её на ячейки. С помощью этого метода делается все несложно. Тут, конечно, идеальным вариантом будет верстка сразу под конкретную CMS, тогда не нужны никакие промежуточные преобразования. Но в целом нет проблем придумать функцию, которая отдает сгенерированный каркас в файл. Дальше верстальщик натягивает нужный дизайн. Что же касается классов и id, то тут часть классов функция сама проставляет, но можно указывать и свои произвольные варианты.

То есть я думаю, что верстальщик должен наложить сетку на дизайн и определить где какие блоки будут выводиться. Дальше он приступает непосредственно к своей работе - «натягивает» дизайн на конкретные блоки. Но к сетке ему уже нет надобности возвращаться.

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

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

ps В конце статьи добавил пример кода для шаблона с шапкой, двумя сайдбарами и подвалом.

16Комментатор 11924-10-2009 21:05

Давным-давно, в одной далекой Дании (или Германии)... в общем, этого реликта зовут TYPO3 (typo3.org). Возможно, слышали или знакомы. Разумеется, ваш способ компактнее.

Прошу учесть, что время разработки - где-то 96-2000, и что примерноо с 2000-2002 массово применяются шаблоны с метками, как более простые в обращении.

Разумеется, это будет вывод в таблицу организованный системой, которая написана конечно на ПХП. Вообще в системе весь поток вывода рассматривается как ПХП-массив, для каждого элемента которого указан способ рендеринга и источник данных. Каждый элемент рассматривается как псевдообъект. Одним из классов таких псевдообъектов являются COLUMNS.

Итак, поехали - далее следует код шаблонизатора.

page.10 = COLUMNS
page.10 {
  rows = 1
  1.1 = PHP_SCRIPT
  1.1.file = header.php
}
page.20 = COLUMNS
page.20 {
  rows = 1
  1.1 = PHP_SCRIPT
  1.1.file = content.php
  1.2 = PHP_SCRIPT
  1.2.file = sidebar.php
}
page.30 = COLUMNS
page.30 {
  rows = 1
  1.1 = PHP_SCRIPT
  1.1.file = footer.php
}

Разумеется, написана жуткая ересь smile т.к. включение данных из файлов считается жутким моветоном и допускается, только если без этого не обойтись (при запросе встроенными функциями учитываются права, время и прочий контекст плюс данные форматируются)

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

17MAX24-10-2009 23:16

Понятно. Спасибо. Признаться, с typo3 не сталкивался. Довольно сложный у них подход. Но не в этом дело. Насколько я понял, то в этой системе все реализуется через «описательную» часть. Причем это не только непосредственный вывод, но и некая конфигурация для админ-панели. Как частный случай, наверное можно задать и модульную сетку. По функциям, если я правильно понял, то есть там что-то вроде CodeIgniter'овского «HTML Table Class». Годится для генерации таблицы, но без «интеллекта».

Я, пожалуй, всё-таки еще повожусь и выложу описание своих grid_. Потому что так на пальцах, наверное неплохо, но пощупать в жувую куда интересней. Ну и идеи, может кто подкинет. Но вообще, мне кажется может получиться стоящая вещь. Сейчас я смог сделать не только автовыбор DIV-TABLE, но и задание произвольных class, id и любых атрибутов блока/ячейки. Данные могут выводиться из файла, текста или функции. Предсмотрена буферизация, её получение и если нужно (при отладке), очистка. Также сделал вывод массива-структуры GRID, и генерация «голого» каркаса. Еще хочу попробовать реализовать всё-таки механизм colspan и rowspan. Тогда, можно будет задавать практически произвольную сетку.

18Комментатор 11925-10-2009 11:10

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

И если последовательно проводить политику - толко чистая PHP-шаблонизация, т отакой подход выглядит очень удобным.

А с третьей стороны, еще раз замечу - ИМХО максимальную скорость разработки сайта можно получить когда на входе система получает чистый ХТМЛ-шаблон, ну или шаблон с метками. а index.php по существу содержит только строчку showView (url, getData (url), getTemplate (url));

19MAX25-10-2009 19:11

Вы правы: если есть готовый HTML, то дальше только программирование. Как там он цепляется к CMS - дело десятое. smile Но у меня как раз задача сделать этот самый HTML. wink

20Surrealisstik07-06-2010 12:56

На мой, сугубо личный взгляд, основанный на моём же сугубо личном профессиональном опыте, могу сказать следующее:

Таблицами верстаючи можно сверстать быстро и кроссбраузерно типовой шаблон для любого сайта. Но, для нестандартного макета лучше использовать всё же div.

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

Я считаю, что каждый решает сам, исходя из потребностей проекта, из своего опыта.

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

21Дмитрий11-05-2012 14:27

Спасибо за статью, очень грамотный ход мысли, как раз сам работаю над этим grin

заметил небольшую опечатку:

когласно этим ячейкам
Оставьте комментарий!

Комментарий будет опубликован после проверки. Вы соглашаетесь с правилами сайта.

(обязательно)

РЕКЛАМА
Продвижение сайтов Продвижение сайтов в Казани. |

О сайте

Здесь вы получите самую полную информацию о создании сайтов на MaxSite CMS.

Рейтинг@Mail.ru