Рис. 3.2 Слайдер уроков. Пример использования JavaScript.

Также присутствует кнопка вверх, которая делается тоже с помощью JavaScript.



Рис. 3.3 Кнопка вверх. Пример использования JavaScript.

3.2 Разработка физической модели БД

Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты: 

1. Реляционная модель данных - удобный способ представления данных предметной области. 

2. Язык SQL - универсальный способ манипулирования такими данными.

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

Логическая модель данных 

Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

Логическая модель данных является начальным прототипом будущей базы данных. Она строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).

Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.

Физическая модель данных 

На еще более низком уровне находится физическая модель данных.

Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.

Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.

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

В случае реляционной модели данных под этим подразумевается следующее:

· создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;

· определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

· разработка средств защиты создаваемой системы.

Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.

· Они связаны с совершенно разными аспектами системы, поскольку отвечают на вопрос, что делать, а не как делать.

· Они выполняются в разное время, поскольку понять, что надо сделать, следует прежде, чем решить, как это сделать.

· Они требуют совершенно разных навыков и опыта, поэтому требуют привлечения специалистов различного профиля.

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

Этапы физического проектирования базы данных:

1. Перенос глобальной логической модели данных в среду целевой СУБД.

2. Проектирование основных отношений.

3. Разработка способов получения производных данных.

4. Реализация ограничений предметной области.

5. Проектирование физического представления базы данных.

6. Анализ транзакций.

7. Выбор файловой структуры.

8. Определение индексов.

9. Определение требований к дисковой памяти.

10. Проектирование пользовательских представлений.

11. Разработка механизмов защиты.

12. Обоснование необходимости введения контролируемой избыточности.

13. Текущий контроль и настройка операционной системы.

Физическое проектирование базы данных включает шесть основных этапов. Концептуальное и логическое проектирование охватывает три первых этапа разработки баз данных, а физическое проектирование - этапы 4-9. Этап 4 стадии физического проектирования включает разработку основных отношений и реализацию ограничений предметной области с использованием доступных функциональных средств целевой СУБД, на этом этапе должно быть также принято решение по выбору способов получения производных данных, которые включены в модель данных.

Этап 5 включает выбор файловой организации и индексов для основных отношений. Как правило, СУБД для персональных компьютеров имеют фиксированную структуру внешней памяти, а другие СУБД предоставляют несколько альтернативных вариантов файловой организации для хранения данных. С точки зрения пользователя организация внутренней структуры хранения отношений должна быть совершенно прозрачной - пользователь должен иметь возможность получать доступ к любому отношению и к отдельным его строкам без учета способа хранения данных. Это означает, что СУБД должна обеспечивать полную независимость физического хранения данных от их логической организации. Только в этом случае внесение изменений в физическую организацию базы данных не окажет никакого влияния на работу пользователей. Соответствие между логической моделью данных и физической моделью данных определяется внутренней схемой базы данных. Разработчик должен предоставить подробные физические проекты базы данных с учетом применяемой СУБД и операционной системы. В проекте реализации базы данных в СУБД разработчик должен определить структуры файлов, которые будут использоваться для представления каждого отношения. В проекте реализации базы данных в операционной системе разработчик должен указать расположение отдельных файлов и обеспечить необходимую их защиту. Прежде чем приступить к изучению этапа 5 рассматриваемой методологии, рекомендуем читателю ознакомиться со сведениями о файловой организации и структурах внешней памяти, приведенными в приложении В.

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

На этапе 8 анализируется также необходимость снижения уровня требований нормализации данных в логической модели, что может способствовать повышению общей производительности системы. Однако эти действия следует предпринимать только в случае реальной необходимости, поскольку введение в базу данных избыточности неизбежно вызовет появление проблем с поддержанием целостности данных. На этапе 9 описан способ организации текущего контроля операционной системы, позволяющий своевременно обнаруживать и устранять все проблемы производительности, которые могут быть решены на уровне проекта, а также учитывать новые или изменившиеся требования.

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

Проектирование физического представления базы данных

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

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

2. Выбор файловой структуры- Определение наиболее эффективной файловой структуры для каждого базового отношения.

3. Выбор индексов- Определение того, будет ли добавление индексов способствовать повышению производительности системы.

4. Определение требований к дисковому пространству- Оценка объема дискового пространства, необходимого для размещения базы данных.

Физическая структура базы данных моего сайта.

Рис. 3.4 Структура базы данных.

3.2 Создание интерфейса пользователя

Сегодня ни для кого не секрет, что графический пользовательский интерфейс любого программного продукта является одним из ключевых факторов его популярности. Времена, когда связь между пользователем и приложением повсеместно устанавливалась при помощи командной строки, практически безвозвратно канули в лету, уступив место графическому пользовательскому интерфейсу (GUI от Graphical User Interface).

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

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

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

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

Рис. 3.5 Структура сайта

По этой структуре я начал создавать дизайн. При создании дизайна мне очень помогла программа Adobe Photoshop, которую и посвящён мой сайт.



Рис. 3.6 Первый вариант дизайна.

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

Рис. 3.7 Логотип сайта.

Новый дизайн более привлекательный чем старый, все чисто и аккуратно. Максимально проработано до мелочей. Все элементы дизайна:

Рис. 3.8 Дизайн сайта



Рис. 3.9 Форма поиска

Рис. 3.10 Навигатор сайта. Меню

Рис. 3.11 Слайдер

Рис. 3.12 Сайдбар: форма авторизации и список категорий.

Рис. 3.13 Краткая информация уроков.



Рис. 3.14 Блог комментария.

Рис. 3.15 Личный кабинет пользователя.

3.3 Организация поиска по данных

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

Поиск как правило можно реализовать двумя способами:

Первый способ поиска, поиск - реализованный средствами движка сайта (php или какой ни будь другой язык веб-программирования) - но это только для серьезных веб-программистов, для простых смертных предпочтителен способ номер 2; поисковая форма, обращающаяся к поисковику (Google, Яндекс или какому ни будь другому).

Я сделал систему поиска по второму способу, которого доступен каждому человеку, освоившему азы html, и подходит для любого сайта, даже состоящего из набора статических html-страниц. Однако такой поиск будет вестись только по тем страницам, которые есть в базе поисковика. Чтобы все страницы сайта нормально индексировались необходимо соблюдение двух правил:

1) на каждую страницу сайта должна вести прямая ссылка без редиректа;

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

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

Простейший алгоритм, следующий:

· Создать HTML-форму со строкой поиска, а также кнопкой "Submit". В текстовое поле пользователи будут вводить поисковый запрос, а далее нажимать на кнопку.

· Получить поисковый запрос (как правило, передаваемый методом GET, но иногда применяют и POST), а также, в целях защиты от XSS, пропустить его через функцию htmlspecialchars().

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



Рис. 3.16 Результаты поиска.

Показываю примерный SQL-запрос для таких случаев:

SELECT * FROM lessons WHERE `text_article` LIKE %search%

Соответственно, вместо search подставляется строка поиска.

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

Многие из Вас скажут, что ничего сложного здесь нет. И будут отчасти правы, однако, давайте разберём такой пример строки поиска: "ищу этот текст". Встаёт вопрос: "А что, собственно, ищется?". То ли ищется точное вхождение текста "ищу этот текст". Или, быть может, ищется текст, где присутствуют все три слова, но которые могут следовать далеко не друг за другом. Или, возможно, ищется текст, где присутствует хотя бы одно из этих слов.

И вот здесь задача значительно усложняется. Можно сделать сложную систему синтаксиса (как в поисковых системах), например, ищется точное вхождение, если запрос задан в кавычках. А можно давать выбор пользователям, как именно они хотят проводить поиск (с помощью radio-кнопок). Таким образом, сделано у меня на сайте. Поэтому в предыдущий алгоритм добавляется ещё один пункт: составление SQL-запрос. Вот пример SQL-запроса, когда нужно вытащить все материалы, в которых имеется хотя бы одно слово из запроса "ищу этот текст":

SELECT * FROM articles WHERE (`text_article`  LIKE  "%ищу%"  OR `text_article` LIKE "%этот%" OR`text_article` LIKE "%текст%")

Соответственно, в скрипте поиска Вы должны генерировать подобные SQL-запросы, посылать к базе данных, получать ответ и выводить его. Это всё ещё больше усложняется, если Вы выводите записи по релевантности, так как трудно сразу сказать, что должно быть релевантнее: 3 точных вхождения запроса, либо 10 вхождений частей запроса. У меня на сайте предпочтение всегда отдаётся точным вхождениям, но этот момент уже достаточно спорен. Безусловно, это сложно, и если это Вы делаете в первый раз, то несколько часов Вы точно потратите.

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

Поиск на web-сайте нужен, поскольку он должен выполнять следующие задачи: 

· обеспечивать альтернативную навигацию;

· делать доступными архивы сайта и получение информации с них; позволять увеличить активность посетителей на сайте, делая его более дружественным и привлекательным;

· представлять собой удобный сервис для профессионалов. 

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

Выбирая движок, нужно учитывать следующие факторы, характеристики и параметры: 

· Ранжирование. Нужно определиться с тем, какие сайты должны занимать верхние уровни, а какие должны быть от ранжированы по релевантности, а также по зоне; 

· Поддержка документов различных форматов. Безусловно, поисковые системы анализируют документы в распространенном формате html, но не следует забывать о текстовых документах в форматах pdf, doc; 

· Скорость обновления. Если речь идет о новостном web-сайте, то очень важно, чтобы время публикации новости, а также время, когда она попадает в индекс, были минимальными. Кроме того, поисковый индекс должен обновляться не реже одного раза в день; 

· Учет всех разделов web-сайта; 

· Подавление дублей с помощью навигационной обвязки. Если говорить о новостной ленте, то часто одна и та же новость дублируется в разных разделах web-сайта. Реализованный поисковик должен уметь выявлять и группировать такого рода дубли; 

· Расширение запросов; 

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

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

Перед тем, как организовать поиск на web-сайте, полезно знать, какие есть виды поисковых систем для установки на интернет-ресурсе: 

1. Крупные поисковые системы. Они подходят в том случае, если нет необходимости управлять

2. Поиск по web-сайту, что встроен в CMS. 

3. Средства реляционных систем управления базами данных. Данный вид поиска очень удобен для разработчиков сайта. Они характеризуются тем, что есть ограничение на количество документов, по которым осуществляется поиск, кроме того, каждый из документов должен находиться в БД (базе данных). 

4. Внешний поисковый сервис. Этот вид поиска характеризуется тем, что данные представляются в определенном формате - xml. Внешний поисковый сервис заходит на web-сайт снаружи. Недостатком такого вида поисковой системы является то, что они не выделяют мета данные, что связаны с документом. 

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

Организация поиска на web-сайте невозможна без оценки его качества. Чтобы осуществить контроль, необходимо оценить полноту и точность поиска - это формальные оценочные параметры, что может использовать разработчик. Качество поиска определяется отсутствием дублей и прочего навигационного «мусора», временем появления документа в поисковом индексе. Следует также обратить внимание на сниппеты. 

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

Перелинковка web-сайтов осуществляется с помощью создания словаря тематических запросов из предметной области интернет-ресурса. Термины такого словаря запросов хорошо использовать для создания соответствующих ссылок из всех документов web-сайта на поисковую выдачу по конкретному запросу. 

Организовывая поиск на web-сайте, следует знать о таких новых возможностях как кластеризация результатов поиска, эффективные интерфейсные решения. Как пример, можно назвать Quintura, которая не является пассивной, а активно предлагает пользователю варианты выдачи на его запрос, учитывает все пожелания, затем, анализируя найденную информацию, снова предлагает варианты выдачи. Еще одной инновационной возможностью является реферирование документов поисковой выдачи, возможность показа краткой выдачи. 

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

Схема работы поисковой системы:

Рис. 3.17 Схема работы поисковой системы.

3.4 Система регистрации пользователя

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

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

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

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

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

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

3.5 Загрузка фото, видео файлов

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

Первым делом, что нужно усвоить - это то, что сама HTML-форма, в которую подставляется файл должна быть не совсем обычной, вот пример HTML-кода такой формы:

<form action = "loading.php" method = "post" enctype = 'multipart/form-data'>

<input type = "file" name = "somename" />

<input type = "submit" value = "Загрузить" />

</form>

Ключевой момент здесь - это атрибут "enctype" со значением "multipart/form-data". Без него ничего работать не будет.

Теперь пишем скрипт "loading.php", в котором мы ещё загружать файл не будем, а пройдёмся немного по различным важным моментам, которые надо обязательно учитывать, иначе может пострадать безопасность:

<?php

print_r($_FILES);

?>

В результате, Вы увидите содержимое глобального двумерного массива $_FILES:

name - имя загружаемого файла.

type - MIME-type загружаемого файла. Это, пожалуй, самый важный параметр для обеспечения безопасности. И всегда при приёме файлов необходимо проверять MIME-type, иначе проблем не оберётесь. В следующей статье мы поговорим об этом более детально.

tmp_name - физический путь к временному файлу. Именно в это место и помещается файл, а уже потом мы его переносим в другое место. Фактически, файл уже загружен, а нам лишь надо его переместить в нужную папку на сервере.

error - код ошибки. Если 0, то ошибок нет.

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

И все эти параметры присутствуют для каждого загружаемого файла (каждые из которых представляют собой массив в двумерном массиве $_FILES).

Теперь давайте уже закончим с загрузкой файлов на сервер в PHP, и для этого напишем такой код ("loading.php"):

<?php

$uploadfile = "images/".$_FILES['somename']['name'];

move_uploaded_file($_FILES['somename']['tmp_name'], $uploadfile);

?>

То есть вначале мы задаём путь к загружаемому файлу на сервере. Здесь мы хотим поместить файл в директорию "images" с тем же именем, что и было раньше у файла. А функцией move_uploaded_file() мы перемещаем файл в выбранную нами директорию из его временного хранилища.

Однако, обратите внимание, это очень важно! Так использовать код ни в коем случае нельзя, иначе Вашему сайту будет угрожать серьёзная опасность! Фактически, на данный момент может быть загружено абсолютно всё, что угодно: любые исполняемые файлы, скрипты, HTML-страницы и другие весьма опасные вещи. Поэтому обязательно надо проверять загружаемые файлы на сервер очень тщательно. И вот этим мы и займёмся в следующей статье. Поскольку тема очень важная, то я советую Вам подписаться на обновления, чтобы не пропустить эту статью.

3.6 Панель администратора

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

Итак, давайте вновь распишу порядок действий, которые необходимо выполнить:

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

2. Примем решение о том, какие данные мы хотим видеть в Admin-панели. Например, наверняка нам потребуется видеть пользователей нашего сайта, наши статьи, может быть, какие-нибудь опросы.

3. Создаем класс для управления Admin-панелью. Здесь должны быть созданы методы, которые позволяют делать выборку из самых разных таблиц, а также добавлять и редактировать записи в них. И сделать подобные методы нужно для всех таблиц, с которыми мы хотим работать в Admin-панели (мы уже должны были выбрать это в предыдущем пункте). Например, самый простой пример с пользователями. Минимальный набор требуемых методов: выборка всех пользователей, добавление нового пользователя, изменение пользователя. Безусловно, все эти задачи должны быть нами уже реализованы при создании движка для сайта, поэтому здесь нам надо будет, возможно, как-то изменить данные конкретно для Admin-панели.

4. Разбить шаблон сайта на отдельные части и скопируем их в отдельные файлы с расширением tpl. Также поставим элементы шаблона, например, так: "Пользователь {username} зарегистрировался {regdate}". Это всего лишь пример, а данные, вообще говоря, удобнее выводить в таблицах.

5. Создаем обработчик, который будет заниматься подстановкой вместо элементов шаблона соответствующие данные.

6. Собираем по кирпичикам все страницы Admin-панели нашего сайта с помощью созданного в предыдущем пункте класса.

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

Как видите, последние 4 пункта идентичны тем, которые мы выполняли при создании движка. Здесь объём работы будет значительно меньше, поэтому, думаю, мы с этим без проблем справитесь.

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



Заключение

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

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

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

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



Cписок использованных литератур и источников

Ш Леонтьев В.П. «Web-дизайн. Руководство пользователя» 2003г-640с.

Ш Крамер Р. «HTML: наглядный курс Web-дизайна» 2001г-298с

Ш Нидерст М.В. «Web-мастеринг для профессионалов. Настольный справочник»

2001г-240с

Ш Аленова Наталья «Html для чайников» (http://postroika.ru) 2007г

Ш Видео уроки Евгения Попова

Ш Видео уроки Михаила Русакова

Ш www.referats.ru

Ш www.stydenty.ru

Ш www.websitegarage.com

Размещено на Allbest.ru

...