Написання Веб-сайту кафе

Размещено на http://www.allbest.ru/

ВСТУП

На сучасному рівні розвитку інформаційних технологій використання комп'ютера для збереження будь-яких видів інформації стає єдиним засобом, що надає широкі можливості керування інформацією. Важливу роль у процесі отримання інформації відіграє мережа Інтернет. Сьогодні в Україні послугами Інтернет з різною періодичністю користуються близько 9 млн. жителів України. Internet сьогодні це найбільш розвинена у світі інформаційна система, за допомогою якої здійснюється комунікація між мільйонами користувачами. За допомогою мережі Internet забезпечується доступ до більш як п'яти мільйонів інформаційних Web-сайтів. Якщо прийняти до уваги кількісні показники українського сегменту Internet, то вони налічують 200-300 тисяч користувачів, загальна кількість Web-серверів на сьогодні досягла позначки 4,5 тисяч. З самого початку розвитку Internet, а особливо з появою Web-технологій, мережа орієнтована на інформаційне забезпечення своїх користувачів.

Метою даної наукової роботи є дослідження розвитку сучасних Web-технологій та їх ефективного застосування на прикладі створення Web-сайту кафе.

На сьогодні представлення організацій у мережі Internet є необхідним для покращення ефективності її роботи, обміну інформацією між усіма учасниками ринкового процесу та способом заявити про свою діяльність великому загалу користувачів глобальної мережі. Саме тому темою наукової роботи було обрано використання Web-технологій для створення сайту кафе «Соллі».



Розділ 1. Дослідження предметної області

1.1 Вибір Технології та платформи для розробки

Для написання сайту було використано технологію Model-view-controller (MVC, «модель-представлення-поведінка», «модель-подання-контролер», «модель-вид-контролер») - схема використання декількох шаблонів проектування, за допомогою яких модель даних програми, користувальницький інтерфейс і взаємодія з користувачем розділені на три окремих компонента. Таким чином, щоб модифікація одного з компонентів надавала мінімальний вплив на інші. Дана схема проектування часто використовується для побудови архітектурного каркаса, коли переходять від теорії до реалізації в конкретній предметній області.[1]

Історія

Концепція MVC була описана в 1979 році [ 2 ] Трюгве Реенскауг (англ. Trygve Reenskaug), тоді працюючим над мовою програмування Smalltalk в Xerox PARC . Оригінальна реалізація описана в статті «Applications Programming in Smalltalk - 80 : How to use Model -View - Controller» [ 3 ] . Потім Джим Алтофф з командою розробників реалізували версію MVC для бібліотеки класів Smalltalk -80.

В оригінальній концепції була описана сама ідея і роль кожного з елементів : моделі, представлення і контролера. Але зв'язки між ними були описані без конкретизації . Крім того, розрізняли дві основні модифікації:

Пасивна модель - модель не має жодних способів впливати на представлення або контролер, і використовується ними як джерело даних для відображення. Всі зміни моделі відслідковуються контролером і він же відповідає за перебудову представлення, якщо це необхідно. Така модель частіше використовується в структурному програмуванні, так як в цьому випадку модель є просто структура даних, без методів їх обробки.

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

Класичною реалізацією концепції MVC прийнято вважати версію саме з активною моделлю.

З розвитком об'єктно-орієнтованого програмування та поняття про шаблони проектування був створений ряд модифікацій концепції MVC, які при реалізації у різних авторів можуть відрізнятися від оригінальної . Так, наприклад, Еріан Верми в 2004 році описав приклад узагальненого MVC [ 4 ]

Призначення

Основна мета застосування цієї концепції полягає в поділі бізнес-логіки (моделі) від її візуалізації (уявлення, виду). За рахунок такого поділу підвищується можливість повторного використання. Найбільш корисне застосування даної концепції в тих випадках, коли користувач повинен бачити ті ж самі дані одночасно в різних контекстах та / або з різних точок зору. Зокрема, виконуються наступні завдання:

До однієї моделі можна приєднати кілька видів, при цьому не зачіпаючи реалізацію моделі. Наприклад, деякі дані можуть бути одночасно представлені у вигляді електронної таблиці, гістограми і кругової діаграми .

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

Ряд розробників спеціалізується тільки в одній з областей: або розробляють графічний інтерфейс, або розробляють бізнес-логіку. Тому можливо добитися того, що програмісти, що займаються розробкою бізнес-логіки (моделі), взагалі не будуть інформовані про те, яке представлення буде використовуватися.

Концепція

Концепція MVC дозволяє розділити дані, представлення та обробку дій користувача на три окремих компонента:

Модель (англ. Model). Модель надає знання: дані і методи роботи з цими даними, реагує на запити, змінюючи свій стан. Не містить інформації, як ці знання можна візуалізувати .

Представлення, вид (англ. View). Відповідає за відображення інформації (візуалізацію) . Часто як представлення виступає форма (вікно) з графічними елементами.

Контролер (англ. Controller). Забезпечує зв'язок між користувачем і системою : контролює введення даних користувачем і використовує модель та подання для реалізації необхідної реакції.

Важливо відзначити, що як представлення, так і контролер залежать від моделі. Однак модель не залежить ні від уявлення, ні від контролера. Тим самим досягається призначення такого поділу: воно дозволяє будувати модель незалежно від візуального представлення, а також створювати кілька різних представлень для однієї моделі.

Для реалізації схеми Model-View-Controller використовується досить велика кількість шаблонів проектування (залежно від складності архітектурного рішення), основні з яких «спостерігач», «стратегія», «компонувальник» [ 5 ] .

Найбільш типова реалізація відокремлює вигляд від моделі шляхом встановлення між ними протоколу взаємодії, використовуючи апарат подій (підписка/сповіщення). При кожній зміні внутрішніх даних в моделі вона оповіщає всі залежні від неї представлення, і вони оновлюється. Для цього використовується шаблон «спостерігач». При обробці реакції користувача вид вибирає, залежно від потрібної реакції, потрібний контролер, який забезпечить той чи інший зв'язок з моделлю. Для цього використовується шаблон «стратегія», або замість цього може бути модифікація з використанням шаблону «команда». А для можливості однотипного звернення до підоб'ектів складно-складеного ієрархічного виду може використовуватися шаблон «компонувальник». Крім того, можуть використовуватися й інші шаблони проектування, наприклад, «фабричний метод», який дозволить задати за замовчуванням тип контролера для відповідного виду.

Найбільш часті помилки

Початківці програмісти (особливо у веб-програмуванні, де абревіатура MVC стала популярна) дуже часто трактують архітектурну модель MVC як пасивну модель MVC. У цьому випадку модель виступає виключно сукупністю функцій для доступу до даних, а контролер містить бізнес-логіку. У результаті код моделей за фактом є засобом отримання даних з СУБД, а контролер являє собою типовий модуль, наповнений бізнес-логікою, або скрипт в термінології веб-програмування. У результаті такого розуміння MVC розробники стали писати код, який Pбdraic Brady, відомий в колах спільноти Zend Framework, охарактеризував як ТТУК - «Товсті тупі потворні контролери» (Fat Stupid Ugly Controllers) [ 6 ] :

Середньостатистичний ТТУК отримував дані з БД (використовуючи рівень абстракції бази даних, роблячи вигляд, що це модель) або маніпулював, перевіряв, записував, а також передавав дані в представлння. Такий підхід став дуже популярний тому, що використання таких контролерів схоже на класичну практику використання окремого php-файлу для кожної сторінки програми.

Але в об'єктно-орієнтованому програмуванні використовується активна модель MVC, де модель - це не тільки сукупність коду доступу до даних і СУБД, а вся бізнес-логік, слід зазначити про можливість моделі інкапсулювати в собі інші моделі. У свою чергу, контролери є лише елементи системи, в чиї безпосередні обов'язки входить прийом даних із запиту і передача їх іншим елементам системи. Тільки в цьому випадку контролер стає "тонким" і виконує виключно функцію сполучної ланки (glue layer) між окремими компонентами системи.

CodeIgniter - популярний MVC фреймворк з відкритим вихідним кодом, написаний на мові програмування PHP, для розробки повноцінних веб-систем і додатків. Розроблено компанією EllisLab (англ.), А також Ріком Еллісом (Rick Ellis) і Полом Бурдик (Paul Burdick).[7]

Поточна стабільна версія CodeIgniter'а (CodeIgniter 2.x), як і більш ранні версії, поширюються під проприетарною ліцензією в стилі Apache / BSD, проте розробляється зараз гілка CodeIgniter 3 переліцензірована під OSL 3.0.

Історія

Перший публічний реліз фреймворка стався 28 лютого 2006 року. З виходом версії 2.0 28-го січня 2011 CodeIgniter розділився на дві гілки:

CodeIgniter Core - гілка, яка робить акцент на стабільності, у зв'язку з чим розвивається повільно. Ця версія фреймворку є ядром популярної CMS ExpressionEngine 2.0.

CodeIgniter Reactor - гілка, яку розвиває спільноту. Ця гілка розвивається швидко і містить найновіші можливості.

Особливості

CodeIgniter відрізняє простота [ 8 ], яка досягається завдяки наступним факторам:

Якісна і повна документація з прикладами, а також велика спільнота і Wiki [ 8,9 ]

Безліч відео уроків, які можна знайти як на офіційному сайті, так і на сторонніх ресурсах [ 10-13]

Фреймворк дає свободу програмісту, не створюючи будь-яких структурних обмежень і конвенцій

Програмісту не потрібно вчитися користуватися генераторами коду з командного рядка

CodeIgniter працює практично на будь-якому хостинговому плані, який має підтримку PHP версії 5.1 і вище

CodeIgniter вважається одним з найшвидших і не вимогливих до ресурсів фреймворків [ 8,14]

Малий розмір дистрибутива [ 8 ] (розмір версії 2.1.1 складає всього 2.2 Мб)

Фреймворк дозволяє відмовитися від моделей (незважаючи на те, що це не вітається і не є доброю практикою)

Документація CodeIgniter пропагує «товсті» контролери і «тонкі» моделі. Валідація і побудова бізнес-логіки відбуваються в основному в контролері. Незважаючи на це, фреймворк дає свободу розробнику, тому він може самостійно вибрати підхід до розробки застосунку.

Можливості

Підтримка баз даних MySQL, PostgreSQL, MSSQL, SQLite, Oracle.

Підтримка псевдо-ActiveRecord, який здебільшого повторює синтаксис мови SQL.

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

Підтримка як сегментованих ЛЗУ (Людині Зрозумілий Урл), так і звичайних URL-ів з передачею параметрів.

Фреймворк містить в собі безліч необхідних бібліотек, які створюють функціонал для роботи з файлами, відправлення електронних листів, валідації форм, підтримки сесій, роботи з зображеннями і так далі.

Володіє можливістю кешування на стороні сервера SQL - запитів і генеруються html - сторінок. З версії 2.0 для кешування можуть використовуватися XCache або APC.

У 2011 році з'явився менеджер пакетів під назвою Sparks, який дозволяє легко встановити сторонні бібліотеки за допомогою командного рядка.

У 2011 році з'явилося доповнення, яке робить можливим підтримку міграцій.

Підтримка модульності (HMVC) за допомогою доповнень.

Незважаючи на відсутність ORM в стандартом пакеті, існує можливість використання PHP ActiveRecord, Doctrine, Propel та деяких інших ORM після невеликих змін або доповнень у вихідному коді фреймворка.

За замовчуванням CodeIgniter не використовує шаблонизатор, але є можливість використовувати його власний або один з альтернативних шаблонизатор (Smarty, TinyButStrong).

1.2 Огляд інших популярних платформ для розробки сайтів

Kohana

Також існує платформи альтернативи CodeIgniter.

Наприклад Kohana (вимовляється «кохана» або «когана»; раніша назва -- Blue Flame) -- веб-фреймворк на мові PHP з відкритим кодом, який теж використовує архітектурну модель MVC (англ. Model View Controller). Його мета -- бути безпечним, легким і простим у використанні[15].

Електронний журнал для веб-розробників PHP Inside визнав Kohana «вибором редакції… за архітектуру, швидкість і спільноту»[16]

Історія

Проект Kohana був створений як відгалуження PHP-фреймворку CodeIgniter під назвою Blue Flame[17]. Головною причиною форку був перехід до відкритішої для громадськості моделі розробки, оскільки багато користувачів були невдоволені швидкістю розробки і виправлення помилок у CodeIgniter. Рік Елліс (англ. Rick Ellis) -- творець і власник CodeIgniter -- радо зустрів відгалуження від свого проекту, але допомагати відмовився; він підштовхнув новий проект до створення власної документації і порадив перейменувати проект.[18] В липні 2007 Blue Flame був перейменований в Kohana для того, щоб уникнути проблем з авторськими правами в майбутньому.[19]

Назва «Kohana» було вибрано, коли розробники почали переглядати словники корінних американців для того, щоб вибрати слово, яке не порушувало б авторського права. Kohana мовою Сіу означає «швидкий». Українською вимова назви Kohana -- «кохана» -- означає та, яку кохають, палко люблять. Також в японській мові має значення «маленька квітка», та ім'я відомої касатки (Kohana) -- всі ці значення не мають відношення до назви.

Особливості

· Висока безпека

· Екстремальна легкість

· Легкий у розумінні

· Використовує MVC-модель

· Повна сумісність з UTF-8

· Дуже легко розширюється

Технології

· Суворе ООП, реалізоване на PHP5

· Проста абстракція бази даних з використанням SQL-драйверів

Версії

Гілки розробки

В даний час паралельно розробляються три гілки [20]:

Гілка 3 .1. X. Поточна стабільна версія 3.1.4. Офіційно підтримувалася до лютого 2012 р. Проте, оскільки версія 3.1.4 була випущена в липні 2011 р., очікується ще як мінімум один мінорний реліз із закриттям відомих багів.

Гілка 3 .2. X. Рекомендується для створення нових програм [21]. Поточна стабільна версія 3.2.0. Офіційна підтримка до липня 2012

Гілка 3 .3. X. На даний момент випущено RC1 і RC2. У даній гілці продовжена переробка механізму "запит-відповідь" (Request/Response), особливо в частині HMVC-запитів.

Відмінності між версіями

Відмінність від Kohana CodeIgniter

Суворе ООП на базі можливостей PHP5. Передбачає багато плюсів: захист видимості, автоматичне підвантаження класів, інтерфейси, абстрактні класи, перевантаження властивостей і методів, і застосування патерну одинак (Singleton).

Kohana приєдналася до ініціативи GoPHP5. Всі релізи після 2.2 відповідатимуть цим вимогам.

Збережено стиль CodeIgniter. Будь-який розробник, що використовував CodeIgniter швидко зрозуміє структуру Kohana.

Керується спільнотою, а не компанією. Kohana управляється дискусіями, ідеями та кодом спільноти. Розробники Kohana з усіх куточків світу, кожен зі своїм власним талантом. Це дозволяє прискорити і зробити гнучкішим цикл розробки в якому реагування на проблеми займає години, замість днів або місяців.

Масиви GET, POST, COOKIE, і SESSION працюють як передбачається. Kohana не обмежує доступ до глобальних змінних, але надає ту ж фільтрацію та XSS захист, що і CodeIgniter.

Каскадні ресурси, модулі й спадкування. Контролери, моделі, бібліотеки, хелпери, і види можуть бути завантажені з будь-якого місця вашої системи, програми, або модуля. Опції конфігурації спадковувані і можуть динамічно перезаписуватся кожним застосунком.

Нема конфліктів просторів імен. Суфікси класів, як «_Controller», використовуються для запобігання конфліктів простору імен. Це дозволяє контролерам та моделями користувача завантажуватися в один і той же час.

Справжнє автозавантаження класів. Діє для бібліотек, контролерів, моделей, і хелперів. Це не попереднє завантаження, а справжнє динамічне підвантаження класів при їх ініціалізації.

Хелпери -- статичні класи, а не функції. Для прикладу, замість використання «form_open()», ви можете використовувати форму «form::open()».

Пов'язаність драйверів бібліотек і API.

Потужний обробник подій. У Kohana події можуть бути динамічно додані, замінені або, навіть, вилучені. Це дозволяє вносити значні зміни в процес роботи Kohana, без модифікації існуючого системного коду.

CMS

Також дуже поширеною технологією розробки сайтів є Система керування вмістом (СКВ; англ. Content Management System, CMS) -- програмне забезпечення для організації веб-сайтів чи інших інформаційних ресурсів в Інтернеті чи окремих комп'ютерних мережах.

Існують сотні, а може, навіть й тисячі доступних CMS - систем. Завдяки їхній функціональності їх можна використовувати в різних компаніях. Незважаючи на широкий вибір інструментальних та технічних засобів, наявних в CMS, існують загальні для більшості типів систем характеристики.

Перші СКВ були розроблені у великих корпораціях для організації роботи з документацією. У 1995-му від компанії CNET відокремилася окрема компанія Vignette, яка започаткувала ринок для комерційних СКВ. З часом діапазон продукції розширювався і все більше інтегрувався у сучасні мережеві рішення аж до популярних веб-порталів. [21]

Багато сучасних СКВ поширюються як безкоштовні і легкі у встановленні (інсталяції) програми, які розробляються групами ентузіастів під ліцензією GNU/GPL.

Системи управління веб-сайтом часто розраховані на роботу у певному програмному середовищі. Наприклад, система MediaWiki, під управлінням якої працює Вікіпедія, написана мовою програмування PHP і зберігає вміст і налаштування у базі даних типу MySQL або PostgreSQL; тому для її роботи потрібно, щоб на сервері, де вона розміщена, були встановлені веб-сервер (Apache, IIS чи інший), підтримка PHP та системи керування базами даних MySQL або PostgreSQL, а також, в разі необхідності, додаткові програми для обробки зображень чи математичних формул. Такі вимоги є досить типовими для відкритих СКВ.[22]

Різновиди СКВ

Web content management systems для управління веб-сайтами (наприклад, енциклопедіями, подібними до Вікіпедії, онлайн-виданнями, блогами, форумами, корпоративними чи персональними веб-сторінками та ін.)

Транзакційні СКВ для забезпечення транзакцій у електронній комерції.

Інтегровані СКВ для роботи з документацією на підприємствах.

Електронні бібліотеки (Digital Asset Management) для забезпечення циклу життя файлів електронних медіа (відео, графічн., презентації тощо).

Системи для забезпечення циклу життя документації (інструкції, довідники, описи).

Освітні СКВ -- системи для організації Інтернет курсів та відповідного циклу життя документації. Наприклад:

Системи, що мають українську локалізацію:

- Moodle -- використовується більш ніж 20 ВНЗ України, має українську локалізацію;

- MaxSite CMS -- досить гнучка в налаштуванні CMS на CodeIgniter, має українську локалізацію;

- Joomla -- повна українська локалізація Joomla! 1.5.x, Joomla! 1.0.x - переклад фронтальної частини. Переклади розширень.

- ATutor -- використовується у Тернопільському національному технічному університеті імені Івана Пулюя;

- Ilias -- використовується у Київському національному університеті імені Тараса Шевченка.

Системи, що не мають української локалізації але одночасно не мають проблем із відображенням символів кирилиці (ті, що працюють з шрифтами юнікод UTF-8):

- OLAT;

- Interact;

- Docebo;

- Wordcircle;

- e107.

Платформенні СКВ (Platform Content Management Systems) підтримують автоматизацію роботу з комп'ютерними файлами, папками, програмами у визначеному програмному середовищі.

Корпоративні СКВ (Enterprise content management systems) з різноплановим пристосуванням для потреб підприємницької діяльності. Підтримують цикл життя внутрішньої і зовнішньої документації.

Приклади корпоративних СКВ:

- RedDot;

- Microsoft CMS;

- Rhythmyx;

- Documentum;

- Open pages;

- Chrystal Software;

- Viagnette;

- CyberTeams;

- Blue Martini;

- Tikiwiki CMS Groupware;

Способи роботи

Генерація сторінок за запитом. Системи такого типу працюють на основі зв'язки «модуль редагування > база даних > модуль представлення». Модуль представлення генерує сторінку з контентом при запиті на нього на основі інформації з бази даних. Інформація в БД змінюється за допомогою модуля редагування. Сторінки заново створюються сервером при кожному запиті, а це створює навантаження на сервер. Але це навантаження може бути багатократно зменшене при використанні методів кешування, які є в сучасних веб-серверах.

Генерація сторінок при редагуванні. Системи цього типу при редагуванні сторінок вносять зміну у вміст сайту та створюють набір статичних сторінок. При такому способі втрачається інтерактивність між відвідувачами сайтів та контентом даного сайту.

Змішаний тип. Як зрозуміло із назви, цей тип поєднує в собі переваги перших двох. Може бути реалізований шляхом кешування - модуль представлення генерує сторінку один раз, надалі вона через деякий час буде в декілька разів швидше завантажуватися із кешу. Кеш може оновлюватись як автоматично, через деякий час чи при внесенні змін у певні розділи сайту, так і вручну за командою адміністратора. Другий підхід -- збереження певних інформаційних блоків на етапі редагування сайту і збирання сторінок з цих блоків при запиті відповідної сторінки користувачем.

Особливості

Існують CMS двох видів: платні і безкоштовні.

Безкоштовні CMS поширюються у вільному доступі, і, як наслідок, за технічну підтримку ніхто не відповідає. Варто пам'ятати про те, що і за збереження, безпеку, при використанні безкоштовної CMS ніхто не буде нести відповідальності.[23]

Характеристики CMS безкоштовної нітрохи не поступаються за якістю CMS платним, проте вірна приказка і для інтернет технологій щодо безкоштовного сиру. Нерідко CMS поширюють угруповання хакерів, з метою частково або повністю здійснювати контроль над сайтами.

Платні CMS поділяються на два типи:

-системи із закритим кодом (вихідний код закодований (кріптований) і не допускає будь-яких змін); -системи з відкритим кодом (для внесення зміни будь-якої з функціональних можливостей вихідний код відкритий). Характеристики CMS з відкритим і закритим кодом мають ряд характерних ознак, які є як перевагами, так і недоліками. Відкритий код дозволяє зловмисникам простіше зламати сайт, а це значить, що можуть постраждати всі ресурси, для створення яких була обрана саме ця CMS. Для того, щоб купити систему з закритим кодом, необхідно переконатися в правильності вибору. Перерахуємо далі по яким характеристикам CMS необхідно вибрати оптимальну для Вашого бізнесу.

Критерії для визначення функціональності CMS Критеріїв для визначення функціональності CMS всього чотири:

функціональність системи управління (основні характеристики CMS це юзабіліті, налаштованість, зручність в обігу, навігації; можливість незначних змін і редизайну без зупинки роботи сайту);

універсальність системи управління (можливість використовувати дані характеристики CMS для створення сайту будь-якого рівня складності, будь то візитка або великий портал);

адміністрування сайту (можливість призначати різним групам користувачів різні рівні доступу, якісний захист системи від зломів);

інші характеристики CMS (такі як можливість перенесення на іншу платформу без втрати інформації, можливість зберігати резервні копії, хороший відгук бази даних).

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

Система управління - програма, що надає інструменти для додавання, редагування, видалення інформації на сайті. Існують різноманітні системи управління сайтом, серед яких зустрічаються платні і безкоштовні, побудовані за різними технологіями. Кожен сайт має панель управління, яка є лише частиною всієї програми, але достатня для управління ним. Велика частина сучасних систем керування вмістом реалізується у вигляді візуального (WYSIWYG) редактора - програми, яка створює HTML-код із спеціальної спрощеної розмітки, що дозволяє користувачеві простіше форматувати текст. [24]

Функції прикладних програм керування контентом

Найпоширеніші функції CMS - систем перераховані нижче:

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

Збір та адаптація контенту з існуючих джерел.

Класифікація та індексування контенту. Контент повинен бути описаний формальними ознаками (наприклад, дата створення, автор) і класифікаційними даними (наприклад, предметна категорія чи ключові слова). Така діяльність описується як зв'язок контенту та метаданих.

Перегляд контенту. Необхідний для всіх видів опублікованого контенту.

Затвердження. Формальне затвердження опублікованого контенту - важлива складова правової відповідальності за нього.

Перетворення контенту. Тексти, графіка, звуки та інші форми контенту мають бути перетворені до формату, що є найзручнішим або використовується в даній CMS - системі.

Зберігання контенту. Контент, як правило, зберігається в файлах або в БД. У випадку складніших застосувань контент підлягає управлінню версіями програмного забезпечення (SMC).

Тестування і верифікація контенту. Може стосуватись різних аспектів, таких як:

Розірвані зв'язки;

Сторінки, які повільно відкриваються;

Програмні помилки в аплетах і скриптах;

Помилки в комунікації клієнт-сервер.

Перевірка готовності контенту - це тип тестування, який включає верифікацію (перевірку) завершеності та цілісності великого об'єму контенту (наприклад, інформацію про різні аспекти нової послуги).

Публікація. Враховує всі фізичні аспекти публікації контенту, включаючи дублювання контенту на різних серверах.

Підтримка, актуалізація та контроль за змінами. Включає моніторинг опублікованого контенту та реагування на сигнали та необхідність змін.

Recall та архівування. Recall може відбуватися з багатьох причин - наприклад, втрата актуальності контенту, втрата законних прав на контент, низька частота відвідуваності, поява новішого контенту тощо. Будь-який Recalled контент є архівований.

Звіти та аналіз. Включає різні форми звітування та аналізу, з метою кращого обслуговування користувачів, покращення вигляду порталу. [25]

1.3 Розгляд вже існуючих успішних проектів

платформа web сайт контент

Кафе «Франзоль» http://www.franzol.com.ua/

Сайт кафе «Франзоль» має простий і зручний зовнішній інтерфейс

На головній сторінці розміщені акційні прас листи, що періодично оновлюються. Інтерфейс представлений двома меню. Верхнє меню з основними вкладками «Концепція», «Новинки», «Дисконтна система», «Фото» та бокове з асортиментом закладу. Інтерфейс інтуїтивно зрозумілий і не має зайвих яскравих ефектів. Дизайн сайту виконаний в м'яких тонах, з округлими плавними лініями.

Рис. 1.3.1 Головна сторінка сайту Кафе «Франзоль»

Мережа кафе «Компот» http://www.compot.ua/

Дизайн сайту спрощено до мінімуму, він представлений як список контактів та адреси окремих кафе у місті Одеса, с посиланням на pdf документ асортименту кожного. Такий дизайн має переваги у простоті та зручності, але користувачам не надається інформація про інтер'єр та екстер'єр кафе. Також немає корисної для відвідувача інформації про працівників кафе, акції та інше. Сайт має посилання на групу в соціальній мережі а вже там адміністрація розмістила більш докладну інформацію.

Рис. 1.3.2 Головна сторінка сайту мережі кафе «Компот»

Сайт кафе друзі http://druzicafe.com.ua

Не зважаючи на мінімалістичний дизайн на сайті є вся корисна інформація про кафе. В головному верхньому меню сайту ми бачимо вкладки «Кафе», «Галерея», «Меню», «Контакти». Це меню не має посилань на інші сторінки натомість в ньому якісно виконаний java скрипт, що виконується без перезавантаження поточної сторінки. При натисканні галерея фонове зображення, яке одночасно є альбомом, можна змінити на нове.



Рис. 1.3.3 Головна сторінка сайту кафе «Druzi»

Даний сайт є прикладом вдалого поєднання простоти та якості загальної картинки і функціональності.

1.4 Постановка задачі

Отже, переглянувши доступні платформи для створення сайтів і вже існуючі успішні проекти, створимо макет власного проекту сайту кафе «Солли».



Список використаних джерел

1) Сергей Рогачев. Обобщённый Model-View-Controller 2007

2) Trygve M. H. Reenskaug/MVC XEROX PARC 1978-79

3) How to use Model-View-Controller (MVC)

4) Vermeij. Arjan A Generic MVC Model in Java 2004

5) Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приёмы объектно-ориентированного проектирования. Паттерны проектирования 2001

6) The M in MVC: Why Models are Misunderstood and Unappreciated | Pбdraic Brady перевод

7) Codeigniter.com (англ.) -- Сайт фреймворка

8) http://setti.biz/574/ odeIgniter vs. CakePHP. Архивировано из первоисточника 29 февраля 2012. (рус.)

9) http://devtrench.com/posts/codeigniter-vs-symfony/ CodeIgniter vs Symfony. Архивировано из первоисточника 29 февраля 2012. (англ.)

10) http://ellislab.com/codeigniter/ CodeIgniter Video Tutorials. Архивировано из первоисточника 29 февраля 2012. (англ.)

11) http://derekallard.com/blog/post/more-codeigniter-video-tutorials-from-the-community CodeIgniter Video Tutorials By Community. Архивировано из первоисточника 29 февраля 2012. (англ.)

12) http://net.tutsplus.com/tutorials/php/codeigniter-from-scratch-day-1/ CodeIgniter From Scratch. Архивировано из первоисточника 29 февраля 2012. (англ.)

13) http://net.tutsplus.com/tutorials/php/easy-development-with-codeigniter/ Easy Development With CodeIgniter. Архивировано из первоисточника 29 февраля 2012. (англ.)

14) http://pr0digy.com/codeigniter/benchmark-update-static-cake-codeigniter-kohana/ Benchmark update: Cake vs. CodeIgniter vs. Kohana

15) http://docs.kohanaphp.com/overview [Kohana User Guide]

16) http://ernieleseberg.com/php-news-kohana-fork-from-codeigniter/ «Kohana fork from CodeIgniter» (англійською). PHP devReview(). 2007-07-19. Архів оригіналу за 2012-03-12.

17) http://ellislab.com/forums/viewthread/53347/P30/#260782 Форум CodeIgniter, червень 2007 р.

18) http://docs.kohanaphp.com/overview/history overview:history [Kohana User Guide]

19) http://kohanaframework.org/download Kohana: Download

20) http://docs.kohanaphp.com/changelog Історія версій

21) Nirav Mehta. Choosing an Open Source CMS. Beginner's Guide. -- Packt (англ.)русск., April 2009. -- 340 p. -- ISBN 978-1-847196-22-4

22) Martin Brampton. PHP5 CMS Framework Development. -- PACKT publishing, June 2008. -- 328 p. -- ISBN 978-1-847193-57-5

23) Денис Колисниченко Движок для вашего сайта. CMS Joomla!, Slaed, PHP-Nuke. -- Петербург: БХВ, 2008. -- 352 с. -- ISBN 978-5-9775-0258-0

24) Савельева Н. Системы управления контентом (рус.) // Открытые системы. -- 2004. -- № 4.

25) http://joomla-ua.org/ Українські локалізації CMS та їх розширень:

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

...