Урок 2. Меню навигации и структура страниц

Урок 2. Меню навигации и структура страниц

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

Открываем файл auto.p и меняем его содержимое на:

@navigation[]
$sections[^table::load[/sections.cfg]]
<table width="100%" border="0" bgcolor="#000000" cellspacing="1">
   <tr  bgcolor="#FFFFFF">
   ^sections.menu{
      ^navigation_cell[]
   }
   </tr>
</table>
<br />

@navigation_cell[]
$cell_width[^eval(100\$sections)%]
^if($sections.uri eq $request:uri){
   <td width="$cell_width" align="center" bgcolor="#A2D0F2">
   <nobr>$sections.name</nobr>
   </td>
}{
   <td width="$cell_width" align="center">
   <a href="$sections.uri"><nobr>$sections.name</nobr></a>
   </td>
}

Что изменилось? На первый взгляд не так уж и много, но функциональность нашего модуля существенно возросла. Мы описали еще один метод - navigation_cell, который вызывается из метода navigation. В нем появилась новая структура:

^if(условие){код если условие "истина"}{код если условие "ложь"}

Что она делает, понять не сложно. В круглых скобках задается условие, в зависимости от того, какое значение возвращает условие, "ложь" или "истина", можно получить разный результат. Также, если в условии записано выражение, значение которого равно нулю, то результат - "ложь", иначе - "истина". Мы используем оператор if для того, чтобы в одном случае поставить ссылку на раздел, а другом нет. Осталось только разобраться с условием. Будем сравнивать на равенство две текстовых строки, в одной из которых - значение URI раздела из таблицы sections, в другой - текущий URI ($request:uri возвращает строку, содержащую URI текущей страницы). Тут возникает вопрос о том, какие же строки равны между собой? Несомненно, только те, которые полностью совпадают и по длине, и по символьному содержанию.

Для сравнения двух строк в Parser предусмотрены следующие операторы:

eq - строки равны (equal): parser eq parser
ne - строки не равны (not equal): parser ne parser3
lt - первая строка меньше второй (less than): parser lt parser3
gt - первая строка больше второй (greater than): parser3 gt parser
le - первая строка меньше или равна второй (less or equal)
ge - первая строка больше или равна второй (greater or equal)

С условием разобрались: если $sections.uri и $request:uri совпадают, ссылку не ставим (а заодно красим столбец в другой цвет - подумаем о наших пользователях, так им будет удобнее), если нет - ставим.

Идем дальше. Меню из первого урока выводило столбцы разной ширины. Ничего страшного, но некрасиво. Проблема решается очень просто: всю ширину меню (100%) делим на количество разделов, которое равно количеству строк в таблице sections. Для этого воспользуемся оператором ^eval() и тем, что можно использовать объекты класса table в математических выражениях. При этом их числовое значение равно числу записей в таблице. Обратите внимание также на то, что мы пользуемся целочисленным делением, используя обратный слеш вместо прямого.

На ^eval() остановимся чуть подробнее. Он позволяет получить результат математического выражения без введения дополнительных переменных, иными словами, хотим что-то посчитать - пишем:

^eval(выражение)[формат]

Использование [формат] дает возможность вывода результата выражения в том виде, который нужен. Форматная строка [%d] отбрасывает дробную часть, [%.2f] дает два знака после запятой, а [%04d] отводит 4 знака под целую часть, дополняя недостающие символы нулями слева. Форматированный вывод нужен, когда необходимо представить число в определенном виде (скажем, 12.44 $ смотрится куда лучше 12.44373434501 $).

Вот, собственно, и все, что касается меню. Теперь оно функционально и готово к использованию.

Наш первый кирпичик для будущего сайта готов. Теперь займемся структурой страниц. Давайте разобьем их на следующие блоки: header - верхняя часть страницы, body - основной информационный блок, включающий также наше меню и footer - нижняя часть страницы. Многие сайты имеют похожую структуру.

Footer будет для всех страниц одинаковым, header - для всех страниц одинаковый по стилю, но с разными текстовыми строками - заголовками страницы, а body будет разный у всех страниц, сохраняя только общую структуру (предположим, два вертикальных информационных блока, соотносящихся по ширине как 3:7). К body отнесем и наше меню.

Каждая из страниц будет иметь следующую структуру:

header
navigation body_additional (30%)	body_main (70%)
footer

Также, как в случае с меню, опишем каждый из этих блоков методом (функцией) на Parser. Давайте подробно разберемся с каждым блоком.

С footer все очень просто - в auto.p добавляем код:

@footer[]
<table width="100%" border="0" bgcolor="#000000" cellspacing="0">
   <tr>
      <td></td>
   </tr>
</table>
$now[^date::now[]]
<font size="-3">
<center>Powered by Parser3<br />1997-$now.year</center>
</font>
</body>
</html>

Никаких новых идей здесь нет, разве что мы впервые использовали класс date с конструктором now для получения текущей даты, а затем из объекта класса date взяли поле year (год). Если это кажется вам непонятным, обязательно вернитесь к первому уроку, где рассказано о работе с объектами на примере класса table. Все идентично, только теперь мы имеем дело с объектом другого класса.

Немного сложнее с модулем header. С одной стороны, нам нужно формировать уникальный заголовок-приветствие для каждой страницы. В то же время он будет одинаковым с точки зрения внешнего вида, различие только в тексте, который будет выводиться. Как же быть? Мы предлагаем сделать следующее: определить в нашем auto.p новую функцию header, внутри которой будет вызываться другая функция - greeting. А функция greeting, в свою очередь, будет определяться на самих страницах сайта и содержать только то, чем отличаются заголовки страниц (в нашем случае строку-приветствие).

Дополняем auto.p следующим кодом:

@header[]
<html>
<head>
<title>Тестовый сайт Parser3</title>
</head>
<body bgcolor="#FAEBD7">
<table width="100%" border="0" bgcolor="#000000" cellspacing="1">
   <tr  bgcolor="#FFFFFF" height="60">
      <td align="center">
         <font size="+2"> <b>^greeting[]</b></font>
      </td>
   </tr>
</table>
<br />

Теперь внимание, кульминация. Parser позволяет сделать очень интересный финт: определить один раз общую структуру страниц в файле auto.p, создать каркас, а затем, используя функции, подобные greeting, в тексте самих страниц, получать разные по содержанию страницы одинаковой структуры. Как это работает?

В самом начале файла auto.p мы определим функцию @main[], которая всегда, причем автоматически, исполняется первой. В нее включим вызовы функций, формирующих части страниц.

В начале auto.p пишем:

@main[]
^header[]
^body[]
^footer[]

А для получения уникального заголовка страниц в каждой из них определим функцию greeting, которая вызывается из header:

для главной страницы:
@greeting[]
Добро пожаловать!

для гостевой книги:
@greeting[]
Оставьте свой след…

и т.д.

Теперь при загрузке, например, главной страницы произойдет следующее:

1. Из файла auto.p автоматически начнет выполняться main.
2. Первой вызывается функция header, из которой вызывается функция greeting.
3. Поскольку функция greeting определена в коде самой страницы, будет выполнена именно она, вне зависимости от того, определяется она в auto.p или нет (происходит переопределение функции).
4. Затем выполняются функции body и footer из main.

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

Осталось описать только основной блок - body. Как мы договорились, он будет состоять из двух частей, каждую из которых будем создавать своей функцией, например, body_main и body_additional, а поскольку навигационное меню, по логике, относится к основной части страниц, вызовем navigation также из body. Снова воспользуемся механизмом виртуальных функций. Редактируем auto.p - дополняем:

@body[]
^navigation[]
<table width="100%" height="65%" border="0" bgcolor="#000000" cellspacing="1">
   <tr  bgcolor="#ffffff" height="100%">
      <td width="30%" valign="top" bgcolor="#EFEFEF">
         <b>^body_additional[]</b>
      </td>
      <td width="70%" valign="top">
         ^body_main[]
      </td>
   </tr>
</table>
<br />

Определение функций body_main и body_additional, также как и в случае с greeting вставим в страницы:

@body_additional[]
Главная страница сайта

@body_main[]
Основное содержание

Этот текст приводится как образец для index.html. Отлично! Структура окончательно сформирована. Мы описали все необходимые модули в файле auto.p, сформировали общую структуру и теперь можем запросто генерировать страницы. Больше не нужно помногу писать одни и те же куски HTML кода. Привычные HTML-страницы трансформируются примерно в следующее (примерное содержание index.html файла для главной страницы):

@greeting[]
Добро пожаловать!

@body_additional[]
Главная страница сайта

@body_main[]
Основное содержание

Просто и понятно, не правда ли? Все разложено по полочкам и легко доступно. При этом после обработки подобного кода Parser создаст HTML-код страницы, у которой будет уникальный заголовок, меню, основной информационный блок заданной структуры и footer, одинаковый для каждой страницы. Фактически, мы уже создали готовый сайт, который осталось только наполнить информацией. Это готовое решение для изящного сайта-визитки, который можно создать прямо на глазах. Естественно, это не единственное решение, но такой подход дает отличную структуризацию нашего сайта. Некоторые умственные усилия при разработке структуры с лихвой окупятся легкостью последующей поддержки и модернизации. Каркас хранится в auto.p, а все, что относится непосредственно к странице, - в ней самой.

Дальше открываются безграничные просторы для фантазии. Допустим, вам понадобилось поменять внешний вид заголовка страниц на сайте. Мы открываем auto.p, редактируем один единственный раз функцию @header[] и на каждой из страниц получаем новый заголовок, по стилю идентичный всем остальным. Для обычного HTML нам пришлось бы вручную переписывать код для каждой страницы. Та же самая ситуация и с остальными модулями. Если возникло желание или необходимость изменить общую структуру страниц, например, добавить какой-то блок, достаточно определить его новой функцией и дополнить функцию main в auto.p ее вызовом.

Подобная организация страниц сайта дополняет проект еще одним мощным средством. Предположим, на одной из страниц нам понадобилось получить footer, отличный от других страниц (напомним, изначально мы предполагали, что footer везде одинаковый). Единственное, что нужно сделать, это переопределить функцию footer на нужной странице. Например, такое наполнение /contacts/index.html:

@greeting[]
Наша контактная информация

@body_additional[]
Главная страница тестового сайта

@body_main[]
Основное содержание

@footer[]
Здесь у нас контакты

изменит привычный footer на обозначенный выше, т.е. если Parser находит в тексте страницы код для функции, вызываемой из auto.p, он выполнит именно его, даже если функция определена в самом auto.p. Если же функция не переопределена на странице, то будет использован код из auto.p.

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

Помните, мы использовали в нашем коде конструкцию $request:uri? Она отличается по синтаксису от всего того, с чем мы имели дело раньше. Что же это такое? Внешне похоже на $объект.свойство (урок 1) - значение полей объекта, только вместо точки использовано двоеточие. На самом деле, это тоже значение поля, только не объекта, а самого класса request. В Parser не предусматриваются конструкторы для создания объектов этого класса. Поля подобных классов формируются самим Parser, а мы можем сразу напрямую обращаться к ним. Техническим языком это называется статическая переменная (поле) uri класса request. Она хранит в себе URI текущей страницы. Также, наряду со статическими переменными, существуют статические методы, с которыми мы столкнемся уже в следующем уроке. При этом можно сразу же вызывать их также без создания каких-либо объектов с помощью конструкторов. Запомните, что в синтаксисе статических полей и методов всегда присутствует двоеточие. Если встречается конструкция вида $класс:поле - мы получаем значение поля самого класса, а запись ^класс:метод является вызовом статического метода класса. Например, для работы с математическими функциями в Parser существует класс math. В нем используются только статические методы и переменные:

$math:PI - возвращает число p. Это статическая переменная класса math.

^math:random(100) - возвращает псевдослучайное число из диапазона от 0 до 99. Это статический метод класса math.

Отличие от записи методов и полей объектов состоит только в двоеточии.

Давайте подведем итоги второго урока.

Что мы сделали: исправили недостатки в меню навигации, созданном на предыдущем уроке, а также описали новые блоки header, footer и body, формирующие внешний вид страниц нашего сайта. Теперь мы имеем готовое решение для быстрого создания сайта начального уровня.

Что узнали: познакомились с ветвлением кода, научились вставлять в текст страниц результаты математических вычислений, сравнивать строки и получать URI текущей страницы. Также мы узнали новые методы объектов класса table и класса date и познакомились с мощным механизмом виртуальных функций Parser.

Что надо запомнить: первым методом в файле auto.p можно определить функцию main, которая выполняется автоматически. Любая из функций может содержать вызовы других функций. Все вызываемые из main функции обязательно должны быть определены или в auto.p, или в тексте страниц. В случае если функция будет определена и там и там, то больший приоритет имеет функция, определенная в тексте страницы. Она переопределяет одноименную функцию из main (т.н. виртуальная функция) и выполняется вместо нее.

Что будем делать дальше: нет предела совершенству! От создания сайта начального уровня мы переходим к более сложным вещам, таким как работа с формами и базами данных для создания по-настоящему интерактивного сайта. Параллельно с этим познакомимся с новыми возможностями, предоставляемыми Parser для облегчения жизни создателям сайтов.

User comments:

Маркус	03.09.2014 19:16
"{" всегда должна быть

Сергей	30.12.2008 02:34
Была огромная проблема: оказывается к примеру в строке: ^if($sections.url eq $request:uri){ Обязательно "{" должна без пробелов идти после "...uri)", и еще: $request:uri — uri нельзя менять на свое, а те переменные, что используются в файле .cfg можно. Как видно у меня там url а не uri. А то постоянно выдавалась ошибка, наконец-таки нашел ее решение :)

In order to add comments you must register.

Дата обновления: 21.07.2014