Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Национальный горный университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

003 Опис програми

.pdf

Скачиваний:

Добавлен:

28.03.2016

Размер:

1.35 Mб

Скачать

☆

<<< < Предыдущая 12 / 32 3 > Следующая >>>

02070743.00569-01 13 01

Опис таблиць в db/migrate наводиться в додатку А.

Тепер напишемо реалізацію класу ActiveRecord::Base для кожної з приведених таблиць з вказівкою стосунків таблиць і валідаторів полів (див.

додаток А)

3.2.2. Створення контролерів (controller)

Система відстежування помилок має на увазі різний рівень доступу до моделі і, відповідно, різну реакцію системи на певні дії системи. Рівнів користування системою буде три: користувач, що задає проблему, робітник,

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

Контролери розташовуються в каталозі app/controllers. Таке нехитре правило допомагає розробникові не морочитися в призначеннях кожного каталогу проекту, особливо якщо проект масштабний. Ім'я контролера повинне складатися з назви самого контролера і слова Controller, а назва файлу – із словом <имя>_controller.rb. у нашому випадку буде 4 контроллери: ApplicationController (application_controller.rb), AdminController (admin_controller.rb), TechController (tech_controller.rb) і UserController (user_controller.rb). Контролери необхідно успадкувати від класу

ActionController::Base.

Для всіх трьох рівнів управління існують загальний операції, такі як зміна пароля, зміна інформації про аккаунт і вихід з системи. Ці операції варто винести в базовий клас ApplicationController (див. додаток 3).

Для аккаунта адміністратора передбачені операції аутентифікації користувача-адміністратора, створення нових користувачів / категорій /

станів виконання, їх редагування і логування.

Для аккаунта робітника – операції створення / модифікації проблеми,

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

02070743.00569-01 13 01

Рис. 3.7. Ієрархія контролерів в додатку «система відстежування помилок»

3.2.3. Створення виглядів (view)

Створення призначеного для користувача вигляду грає важливу роль,

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

Наприклад реалізація вигляду для головної сторінки входу до системи адміністратором має наступний вигляд:

02070743.00569-01 13 01

Рис. 3.8. Сторінка входу для адміністратора

Призначені для користувача вигляди розташовуються в каталозі app\views. Для кожного з виглядів користувачів виділимо окремий каталог: admin, tech і user. У кожному з каталогів опишемо поведінку системи для кожної одиниці функціональності моделі:

Admin: перегляд і редагування проблем, логування, перегляд і редагування інформації про користувачів.

Tech: перегляд і редагування проблем, логування

User: перегляд і створення проблем, перегляд інформації про свого користувача.

Також виділимо шаблони більш високого абстракції (layouts), в яких скомпонуем елементи представлення окремих користувачів. Для цього визначимо в каталозі app\views\layouts три файли (admin.rhmtl, tech.rhtml, user.rhtml), які виконуватимуть роль контейнерів відповідних наборів функціональностей. Вихідний код шаблонів абстракції приведений в додатку

4, а реалізацію виглядів – в додатку 5

02070743.00569-01 13 01

3.3. Рух даних по системі

Розглянемо наш додаток у дії з точки зору оброблюваних даних.

Розглянемо повний цикл: від запиту браузеру до сервера до здобуття від нього відповіді.

1. Спочатку браузер формує запит на сервер у вигляді або стандартного запиту через рядок запиту, або безпараметричний запит.

Рис. 3.8. Взаємодія браузера та сервера

2.Потім цей запит обробляється сервером (у нашому випадку

Mongrel) і передається в парсер запитів (routes.rb)

Рис. 3.9. Шлях передачі запиту парсерові

02070743.00569-01 13 01

3. Парсер запитів розбиває отриманий запит на інформативні частини (асоціативний масив) і передає їх на вхід контролеру.

Рис. 3.10. Взаємодія парсера та контролера

4. Контролер інстантується залежно від вибраного режиму користувача (один з 3-х варіантів). Режим приходить у вигляді елементу асоціативного масиву з парсера.

		UserController
		app/controller/admin_controller.rb
		TechController
		app/controller/admin controller.rb
		@instance_variables
		AdminController
		my # Объект контроллера
	app/controller/admin_controller.rb
	@instance_variables
	@instance_variables			ApplicationController
	myaction# Объект контроллера
	myaction# Объект контроллера
	@instance_variables		use	app\controllers\application_controller.rb
my # Объект контроллера
my # Объект контроллера
	action			include SomeModule
				include SomeModule

action

Рис. 3.11. Інстантація контроллера

02070743.00569-01 13 01 5. Далі контролер аналізує отриману команду від вигляду і ініціює

зміну моделі.

Рис. 3.12. Зв'язок модель-контролер

6.Модель змінюється і контролер передає зміни вигляду.

Рис. 3.13. Зв'язок контролера та вигляду

02070743.00569-01 13 01

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

8.На основі шаблону виконується ERB код і формується тіло відповіді, яке і передається назад на сервер.

Представление (View) app/views/:controller/:name

:action	=> name	true	:status => 200
:js	=> true	false	or ‘200 OK’	:type=>:erb
:js	=> true	false		:type=>:erb

		Включение	http response	default template
		в :layout =>	status code	engine