HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов - Владимир Дронов

На этом выполнение функции searchData заканчивается.

Осталось объявить функцию searchInArray, которая, собственно, будет выполнять поиск в массивах, составляющих базу данных. Объявляющий код (листинг 20.21) мы поместим где-либо перед объявлением функции searchData.

Листинг 20.21

function searchInArray(sKeyword, aDataArray, aResultArray, iSearchMode) {

var sN, sK;

var sKw = "," + sKeyword.toLowerCase();

for(var i = 0; i < aDataArray.length; i++) {

sN = "," + aDataArray[i].name.toLowerCase();

if (aDataArray[i].keyword)

sK = "," + aDataArray[i].keyword.toLowerCase()

else

sK = "";

if (((iSearchMode == 0) || (iSearchMode == 2)) && (sN.indexOf(sKw)!= -1))

aResultArray[aResultArray.length] = aDataArray[i]

else

if (((iSearchMode == 1) || (iSearchMode == 2)) && (sK.indexOf(sKw)!= -1))

aResultArray[aResultArray.length] = aDataArray[i];

}

}

Как уже говорилось, эта функция принимает четыре параметра:

— искомое слово в виде строки;

— массив, составляющий базу данных, в котором будет выполняться поиск;

— массив, в который будут помещаться результаты поиска;

— число, обозначающее режим поиска. Фактически это номер пункта, выбранного посетителем в раскрывающемся списке search_in.

Результат эта функция возвращать не будет.

Давайте рассмотрим объявляющий ее код построчно, т. к. он довольно сложен, хоть и невелик по размеру.

Объявляем служебные переменные:

var sN, sK;

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

var sKw = "," + sKeyword.toLowerCase();

Посетитель — человек непредсказуемый. Кто знает, в каком регистре он наберет искомое слово — в верхнем или нижнем, прописными буквами или строчными. А названия Web-страниц нашего Web-сайта указаны как в верхнем, так и в нижнем регистре. И строка, набранная в верхнем регистре, не равна строке, содержащей те же символы, но набранные в нижнем регистре; так, строки "title" и "TITLE", хоть и содержат одни и те же символы, не равны, поскольку эти символы набраны в разных регистрах.

Выход — перед сравнением строк принудительно преобразовать их к какому-либо одному регистру, скажем, к нижнему. В этом нам поможет метод toLowerCase объекта JavaScript String. Он как раз возвращает строку, равную той, для которой он вызван, но набранную в нижнем регистре. Параметров он не принимает.

Но зачем добавлять к искомой строке спереди запятую? Давайте разберемся. Предположим, посетитель захотел найти материалы по тегу <IMG>. Причем посетитель попался на редкость ленивый, и, вместо того чтобы набрать имя тега полностью, ввел только букву "I".

Средства JavaScript позволяют узнать, присутствует ли в какой-либо строке указанная подстрока. (Как мы потом узнаем, за это "отвечает" особый метод объекта String.) Другими словами, приняв за подстроку введенное посетителем искомое слово, мы с помощью этих средств можем легко узнать, присутствует ли оно в названии или списке ключевых слов какого-либо элемента базы данных. Так, мы выясним, что в строке "IMG" присутствует подстрока "I", а в строке"!DOCTYPE" — нет.

Но ведь подстрока "I" присутствует и в строках "AUDIO", "VIDEO" и "TITLE"! А мы решили, что будем выбирать только те материалы, начало названий или ключевых слов содержит указанное слово. Начало, а не середина или конец! К сожалению, средства JavaScript не позволяют указать, в какой именно части слова должна присутствовать искомая подстрока…

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

Например, если мы добавим к строкам "I", "IMG" и "AUDIO" спереди запятую, то получим",I", ",IMG" и",AUDIO". Посмотрим, что получится: строка",IMG" содержит подстроку",I", а",AUDIO" — не содержит. Принятое нами правило поиска — указанное слово должно содержаться в начале названия — теперь выполняется. Как говорится, не мытьем, так катаньем. Ладно, поехали дальше…

Запускаем цикл со счетчиком, который будет просматривать все элементы массива базы данных, переданного вторым параметром:

for(var i = 0; i < aDataArray.length; i++) {

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

sN = "," + aDataArray[i].name.toLowerCase();

Проверяем, есть ли у данного элемента свойство keyword:

if (aDataArray[i].keyword)

sK = "," + aDataArray[i].keyword.toLowerCase()

else

sK = "";

(Ранее мы решили, что оно будет необязательным.) Если оно есть, преобразуем его значение — список ключевых слов — к нижнему регистру, добавляем к нему спереди запятую и присваиваем объявленной ранее служебной переменной. Если его нет, присваиваем той же служебной переменной пустую строку — "пустой" список ключевых слов.

Если посетитель выбрал первый или третий пункты раскрывающегося списка search_in (т. е. если указан режим поиска по названиям или по названиям и ключевым словам; номер выбранного пункта списка search_in передается четвертым параметром) и если в названии элемента массива присутствует указанное посетителем слово:

if (((iSearchMode == 0) || (iSearchMode == 2)) && (sN.indexOf(sKw)!= -1))

мы присваиваем этот элемент новому элементу массива результатов, переданного третьим параметром:

aResultArray[aResultArray.length] = aDataArray[i]

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

Если посетитель выбрал второй или третий пункты раскрывающегося списка search_in (т. е. если указан режим поиска по ключевым словам или по названиям и ключевым словам) и если в списке ключевых слов элемента массива присутствует указанное посетителем слово

else

if (((iSearchMode == 1) || (iSearchMode == 2)) && (sK.indexOf(sKw)!= -1))

мы присваиваем этот элемент новому элементу массива результатов, переданного третьим параметром:

aResultArray[aResultArray.length] = aDataArray[i];

}

На этом выполнение тела цикла и тела функции searchInArray заканчивается.

Что ж, поиск готов. Откроем наш Web-сайт, наберем в поле ввода какое-либо слово и нажмем кнопку Искать!. Если поиск увенчается успехом, в самом конце контейнера cmain мы увидим список, пункты которого будут содержать гиперссылки на найденные Web-страницы.

Поиск работает!

Что дальше?

В этой главе мы познакомились с Web-формами и элементами управления, тегами HTML для их создания и средствами объектов Web-обозревателя и библиотеки Ext Core для работы с ними. А еще мы наконец-то реализовали поиск на своем Web- сайте!

Только вот выглядит наш поиск на редкость непрезентабельно… Ну ничего, в следующей главе мы существенно улучшим его внешний вид! И помогут нам свободно позиционированные контейнеры — особым образом созданные блочные контейнеры, размеры и местоположение которых на Web-странице мы можем задавать совершенно произвольно.

ГЛАВА 21. Свободно позиционируемые элементы Web-страницы 

В предыдущей главе мы познакомились с Web-формами и элементами управления, HTML-тегами для их создания и средствами объектов Web-обозревателя и библиотеки Ext Core для работы с ними. На основе этих элементов управления и базы данных мы создали систему поиска для своего Web-сайта. Наш небольшой Web-сайтик теперь выглядит просто шикарно!

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

— Контейнер с полосой навигации — не лучшее место для Web-формы поиска. То, что она нарушает дизайн Web-страницы, не страшно — задать для нее подходящее представление не составит для нас труда. Хуже другое — полоса навигации в какой-то момент станет слишком большой, не поместится в контейнер, Web- форма "уедет" вниз, и посетителю, чтобы до нее добраться, придется пользоваться полосами прокрутки. А ведь он должен догадаться, что Web-форма поиска еще присутствует на Web-странице, а не пропала бесследно и невесть куда!

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

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