В предыдущей заметке я писал о своей идее сделать сайт на статических html файлах, а так же о том, какие проблемы и ограничения возникают при использовании статики. Пораскинув мозгами налево и направо, я решил дать бой этим недостаткам. Признаться, местами пришлось немного попотеть (но не больше, чем потеют создатели cms), а местами - перестроить мозги (хе-хе). Сегодня постараюсь изложить теорию. К оружию!
Задача
Что должно получиться в итоге? Давайте, вспоминая недостатки статических сайтов, сразу определимся, чего мы не можем, чтобы потом не возвращаться к этому вопросу.
- Мы не можем обрабатывать и хранить на сервере данные пользователей - в этот пункт можно вложить всё: и отсутствие авторизации с личным кабинетом, и отсутствие интерактивности, как и прочих взаимодействий пользователя с сервером, кроме запроса и чтения информации.
- Мы не можем ограничить доступ пользователя к какой-то информации - в общем-то, этот пункт тоже можно было бы включить в предыдущий, но он очень важен при понимании задачи статического сайта, поэтому я вынес его отдельно.
Плохо ли, что мы всего этого не можем? Я утверждаю, что это не хорошо и не плохо, а именно так, как и должно быть.
Инструменты, используемые при разработке проекта, должны соответствовать задачам, поставленным перед этим проектом. Если в список задач входит обработка и сохранение информации от пользователей, единственный путь, логичный и оправданный - это использование серверных скриптов и баз данных. Статику целесообразно использовать тогда, когда проект направлен на отдачу информации.Вернёмся к задаче. Получиться должен проект, направленный на отдачу информации, не требующий контроля доступа к ней, который будет работать без использования серверных скриптов и баз данных, при этом максимально возможно гибкий, расширяемый, удобный в наполнении и использовании. С этого момента моей целью и стал личный блог. Блог нужен именно для отдачи информации, защищать которую ни к чему, возможная активность пользователей на нём минимальна, хранить их данные нам тоже не за чем.
Решение
Ну всё, с задачей определились. Осталось победить (или переосмыслить) недостатки, которые создают нам досадные проблемы при реализации этой задачи.
Шаблонизация
Никак не могу найти взаимопонимания с верстальщиками в этом вопросе, поэтому, читатель, особенно если ты - верстальщик, обращаюсь к тебе лично. Давай будем задавать правильные вопросы, вдумаемся, и ответим на них.
- Q: Что обычно хранится в шаблонах?
- A: Элементы разметки, повторяющиеся на разных страницах: в основном, это элементы дизайна и вёрстки (на обычных сайтах это шапка, футер, сайдбар), а так же структура тега <head> (в котором содержится тайтл страницы, метаданные и подключаемые карты стилей и скрипты).
- Q: Что отдаёт сервер, отвечая на http запрос?
- A: Заголовки ответа и исходный код html документа.
- Q: Кому отдаёт сервер исходный код html документа?
- A: Пользователям (если быть более точным, их браузерам), поисковым роботам, парсерам - то есть, всем, кто может отправить http запрос.
- Q: Кому (хотя бы из перечисленных акцепторов) требуется содержимое шаблонов?
- A: Динамическое содержимое <head> (а именно - тайтл и метаданные) - всем. Подчёркиваю - динамическое содержимое, - то есть, то содержимое, которое разное на разных страницах, а, следовательно, в шаблон не входит. Ну а всё остальное содержимое шаблонов интересно только пользователю. Подчёркиваю - пользователю.
- Q: Что же интересует всех остальных акцепторов содержимого в исходном коде html документа?
- A: Контент.
- Q: Так обязательно ли, чёрт возьми, заворачивать контент в шаблон на сервере?
- A: Мой ответ - не обязательно!
- Q:
Ты болен, Саша?В таком случае где и как, во имя дьявола, применять шаблон к документу?! - A: Там, где это требуется - у пользователя в браузере. Используй javascript. И не нужно делать такое кислое лицо ;)
Возвращаясь к вопросу о целевом использовании дарованных нам инструментов, хочу привести цитату из википедии:
JavaScript обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам.
Так почему бы не поручить ему взаимодействие с пользователем, а серверу не оставить роль хранения и передачи данных? Поскольку у этого блога дизайн оказался минималистичным, особенно заморачиваться над шаблонизацией мне не пришлось, и если открыть исходный код любой страницы, можно увидеть, что ни одного элемента, отвечающего за дизайн, там нет. В исходном коде - только структурная логика документа. Оформление вынесено в css, а дополнительная разметка (менюшки, хлебные крошки, список статей или подкатегорий в категории) - формируется с помощью javascript.
Гибкость и расширяемость
Этого тоже можно добиться, используя javascript. Поскольку js-код централизован и мы можем вынести его в отдельный файл, пусть даже один единственный, который будет подключаться на всех страницах, с его помощью мы можем расширять функционал нашего сайта, динамически подгружая другие js и css файлы (к примеру, jquery и плагины, написанные на нём), динамически меняя разметку и вёрстку, оставляя в неприкосновенности структурную логику html документа.
Навигация по сайту
Двигаемся дальше. Структура страниц на сайте у нас хранится в файловой системе на сервере, а для формирования навигации (как менюшек, так и постраничной навигации в списках статей) она нам нужна. Получить сведения о структуре каталогов без серверных скриптов мы не можем, следовательно, нам понадобится открытое хранилище, которое будет содержать информацию о структуре сайта. Мне его удобно хранить в объекте javascript:
/*
* Объект "карта сайта"
*/
Mithrandir.siteMap = {
0: {
url : Mithrandir.baseUrl + '/',
title : 'Блог mithrandir.ru - Главная страница',
children: {
2: {url: Mithrandir.baseUrl + '/personal/', title: 'Личное', children:{
1: {url: Mithrandir.baseUrl + '/personal/first.html', title: 'Запись первая - для чего создавался этот сайт'}
}},
3: {url: Mithrandir.baseUrl + '/professional/', title: 'Профессиональное', children:{
4: {url: Mithrandir.baseUrl + '/professional/blog/', title: 'О Блоге', children:{
7: {url: Mithrandir.baseUrl + '/professional/blog/idea.html', title: 'Сайт на статических html файлах: идея, преимущества, ограничения'}
}}
}},
5: {url: Mithrandir.baseUrl + '/map.html', title: 'Карта блога'},
6: {url: Mithrandir.baseUrl + '/contacts.html', title: 'Контакты'}
}
}
Такая структура довольно-таки массивна, но я думаю, что можно придумать что-нибудь гораздо более удобное. Должен отметить, что поиск по такому дереву будет осуществляться на стороне клиента, а значит, сервер грузить не будет. Наша задача - только отдать его.
Имея такую структуру, состряпать менюшку на javascript не составит труда. Со списками статей и подкатегорий на страницах, являющихся категориями - придётся повозиться. Если, к примеру, потребуется выводить не только заголовок, но и краткое описание статьи, не обойтись без ajax запросов. Но ведь у нас есть адрес каждого докумнета, а значит, мы можем получить его содержимое через ajax, распарсить и вывести. Кроме всего прочего, такой документ со структурой сайта поможет сформировать html и xml карту сайта (для пользователя и поисковика соответственно).
Чистота кода или удобство наполнения? И то, и другое!
Хорошо-хорошо, признаю, это моё сугубо личное мнение. Просто мне гораздо проще писать html код, чем мучаться с визуальными редакторами, которые которые делают из исходного кода разваренную рисовую кашу (иногда даже с изюмом). Удобнее видеть всю структуру html документа, чем заполнять отдельные поля в форме. И быстрее открыть проект в NetBeans (или открыть ftp/ssh клиент), найти нужный файл в структуре каталогов и открыть его, чем открывать браузер, згружать админку и искать нужный документ в ней. Придерживаясь мнения, что каждый человек в своём деле должен стремиться к профессионализму, этого же хочу пожелать всем контент-менеджерам и веб-мастерам :)
Разумеется, не каждый захочет наполнять вручную статический html, добавлять потом новую страницу в карту сайта вроде той, что я описывал в предыдущем пункте. На самом деле, для заполнения таких документов тоже ведь можно много чего придумать. К примеру, написать cms или десктопное приложение. Ведь наполнение сайта - это уже другая задача, подразумевающая именно обработку и сохранение информации от пользователя, а значит, использование скриптов в данном случае не противоречит общей идеологии. Эта статья ведь посвящена теории, а не практике, так что, придумать я могу всё, что угодно!
Взаимодействие с пользователем
Идея статического личного блога призывает свести взаимодействие с пользователем к минимуму, точнее, сделать его односторонним. Однако нам могут понадобиться простые фишки - поиск по сайту, возможность писать комментарии. Для таких незатейливых задач вполне могут послужить сторонние сервисы. Поиск по сайту можно поручить google или yandex, которые ищут гораздо лучше, чем вы сами написали бы на php. А для комментариев на сайте существует море виджетов. Я ещё даже не решил, какой выбрать :)
Выводы
- Прежде чем выбрать между статикой и динамикой, нужно определиться с задачами проекта. Именно они должны определить данный выбор.
- Используя статический html и javascript, мы можем добиться шаблонизации, гибкости и расширяемости пользовательских интерфейсов, а так же реализовать навигацию по сайту, имея открытое хранилище его структуры.
- Для наполнения такого сайта потребуются или умелые руки, или специальная cms, которая будет генерировать статические страницы и заполнять хранилище структуры.
С теорией - покончено! Пора обратиться к практике. В следующих заметках этой категории я расскажу о том, как это реализовано на блоге mithrandir.ru.