Када пишете своје програме од почетка до краја, лако је видети контрола протока. Програм почиње овде, тамо је петља, позиви метода су овде, све је видљиво. Али у апликацији Раилс ствари нису тако једноставне. Са било којим оквиром, одричете се контроле таквих ствари као што су "проток" у корист бржег или једноставнијег начина обављања сложених задатака. У случају Руби он Раилс, контролом протока се управља иза сцене, а све што вам остаје је (мање или више) колекција модела, приказа и регулатора.
Срж било које веб апликације је ХТТП. ХТТП је мрежни протокол који ваш веб прегледач користи да разговара са веб сервером. Овде долазе појмови попут "захтев", "ГЕТ" и "ПОСТ", они су основни речник овог протокола. Међутим, пошто је Раилс апстракција овога, нећемо трошити пуно времена на разговор о томе.
Када отворите веб страницу, кликнете на везу или пошаљете образац у веб претраживачу, претраживач ће се повезати са веб сервером преко ТЦП / ИП. Онда прегледач шаље серверу „захтев“, размишљајте о њему као о обрасцу за слање поште који прегледач испуњава тражећи информације на одређеној страници. Сервер у коначници шаље веб претраживачу „одговор“. Руби он Раилс ипак није веб сервер, Веб сервер може бити било шта од Вебрицка (што се обично дешава када покренете Раилс сервер са тхе тхе
командна линија) на Апацхе ХТТПД (веб сервер који покреће већину веба). Веб сервер је само фацилитатор, он узима захтев и предаје га својој Раилс апликацији, који генерише одговор и прослеђује се назад серверу, који га заузврат шаље назад на клијент. До сада је ток:Једна од првих ствари коју апликација Раилс направи са захтевом је да је пошаље преко рутера. Сваки захтев има УРЛ, то је оно што се појављује у адресној траци веб прегледача. Рутер је оно што одређује шта треба учинити са том УРЛ адресом, ако УРЛ има смисла и ако УРЛ садржи било које параметре. Рутер је конфигуриран у цонфиг / роуте.рб.
Прво, знајте да је крајњи циљ усмјеривача ускладити УРЛ с контролером и радњом (више о томе касније). А како је већина Раилс-ових апликација РЕСТфул, а ствари у РЕСТфул апликацијама представљене су помоћу ресурса, видећете редове попут ресурси: постови у типичним апликацијама Раилс. Ово се подудара са УРЛ-овима попут /posts/7/edit са контролором поште, Уредити акција на пошти са ИД-ом од 7. Рутер само одлучује где захтеви иду. Тако да се наш [Раилс] блок може мало проширити.
Сада када је усмјеривач одлучио којему ће контролер послати захтјев и којој радњи на том контролеру послати га. Контролер је група повезаних акција која је све уједињена у класу. На пример, на блогу се сав код за преглед, стварање, ажурирање и брисање постова на блогу повезује у контролер који се зове „Пост“. Акције су нормално методе ове класе. Контролери се налазе у апп / контролери.
Рецимо, веб претраживач је послао захтев за /posts/42. Рутер одлучи да се ово односи на пошта контролер, тхе Прикажи метода и ИД поста који се приказује 42, тако се зове Прикажи метода са овим параметром. Тхе Прикажи метода није одговорна за употребу модела за дохваћање података и коришћење приказа за стварање резултата. Дакле, наш проширени [Раилс] блок је сада:
Модел је и најједноставнији за разумевање и најтежи за имплементацију. Модел је одговоран за интеракцију са базом података. Најједноставнији начин да се објасни да је модел је једноставан скуп позива позива који враћају обичне Руби објекте који обрађују све интеракције (чита и пише) из базе података. Дакле, пратећи пример блога, АПИ који ће контролер користити за дохваћање података помоћу модела изгледаће отприлике Пост.финд (парамс [: ид]). Тхе парамс је оно што је усмјеривач анализирао из УРЛ-а, а Пост је модел. Ово чини СКЛ упите или чини све што је потребно за преузимање поста на блогу. Модели се налазе у апликација / модели.
Важно је напоменути да нису све акције потребне за коришћење модела. Интеракција с моделом потребна је само када је потребно учитати податке из базе података или их похранити у базу података. Као такав, поставићемо знак питања у наш мали дијаграм тока.
Коначно је време да почнете да генеришете неки ХТМЛ. ХТМЛ не управља сам контролер, нити модел са њим управља. Смисао кориштења МВЦ оквира је подијелити све. Операције базе података остају у режиму, ХТМЛ генерација остаје у приказу, а контролер (који га позива рутер) зове их обоје.
ХТМЛ се обично генерише помоћу уграђене Руби. Ако сте упознати са ПХП-ом, односно ХТМЛ датотеком са ПХП кодом који је уграђен у њу, тада ће вам Руби бити врло познат. Ови погледи се налазе у апликација / прикази, а контролер ће позвати једног од њих да генерише излаз и послати га назад на веб сервер. Сви подаци које је контролер преузео помоћу модела обично се чувају у варијабла примерака која ће захваљујући некој Руби магији бити доступна као варијабле примерака из приказа. Такође, уграђени Руби не мора да генерише ХТМЛ, он може да генерише било коју врсту текста. То ћете видети када генеришете КСМЛ за РСС, ЈСОН итд.
Овај излаз се враћа на веб сервер, који га враћа назад у веб претраживач, што довршава поступак.