Theory
Portal એટલે scripts નો ઢગલો
Event portal ચાલે તો છે, પણ એને પ્રામાણિકપણે જુઓ: login.php, search.php, register.php, અને દરેકમાં database નો code, HTML અને logic ગૂંચવાઈને પડ્યાં છે. બીજાં 20 pages ઉમેરો એટલે એ સંભાળી ન શકાય એવું બની જાય: header બદલો તો 30 files સુધારવી પડે; કોઈ ભૂલ શોધવી હોય તો ગૂંચમાં ફંફોસવું પડે.
વ્યાવસાયિક ટીમો આ રીતે બાંધતી નથી. એ માળખું લાદતું framework વાપરે છે. PHP નું પરંપરાગત શીખવણી માટેનું framework એટલે CodeIgniter, અને એનો ગોઠવણનો વિચાર છે MVC: એટલે કે એવી સ્વચ્છ separation જેનાથી આ પાઠ portal ને બરાબર ફરી બાંધે છે.
Theory
MVC: ત્રણ કામ, સ્વચ્છ રીતે અલગ
MVC (Model-View-Controller) application ને 3 સ્તરમાં વહેંચે છે, અને દરેકનું એક જ કામ હોય છે:
- Model: data નું સ્તર: database સાથે વાત કરે છે, registrations સાચવે છે
- View: રજૂઆતનું સ્તર: user ને દેખાતું HTML
- Controller: logic નું સ્તર: request મેળવે છે, Model પાસેથી data માગે છે અને એને View ને સોંપે છે
જવાબદારીઓની separation એ જ મળતું ફળ છે: designer database ના code ને અડ્યા વગર Views બદલી શકે; તમે pages તોડ્યા વગર Model માં database બદલી શકો; logic HTML માં વેરવિખેર થવાને બદલે Controllers માં રહે. ગૂંચવાયેલો script 3 વ્યવસ્થિત, સ્વતંત્ર સ્તર બની જાય છે.
Theory
ગોઠવણ અને routing
ગોઠવણ (CI4): Composer થી install કરો (કે download કરો), config ની files માં base URL તથા database ની ઓળખાણ ગોઠવો, અને અંદરથી મળતો development નો server ચલાવો. CodeIgniter નળીકામ પૂરું પાડે છે: routing, database ની પહોંચ, validation, sessions, જેથી તમે પાયાનું માળખું નહીં પણ સગવડો લખો.
Routing URL ને Controller ની method સાથે જોડે છે. /events નો request (ધારો કે) Events controller ની index() method પર જાય છે; default controller ઘરના રસ્તાને સંભાળે છે; routes Config/Routes.php માં જાહેર થાય છે. એટલે URL હવે કોઈ ખરી file (events.php) તરફ ઇશારો કરતું નથી; એ controller ની ક્રિયા તરફ ઇશારો કરે છે, અને framework એને જોડી આપે છે. આ આડકતરાપણું જ MVC ને વ્યવસ્થિત રહેવા દે છે.
Practical
View load કરતું controller (CI4 નો ઘાટ)
<?php
// app/Controllers/Events.php
namespace App\Controllers;
class Events extends BaseController {
public function index() {
// CONTROLLER: coordinate. Ask a Model for data (simplified here):
$data["events"] = ["Garba Night", "Coding Contest"];
// Hand the data to a VIEW to render:
return view("events_list", $data);
}
}
// A request routed to /events runs index(), which renders the view.
// The VIEW (app/Views/events_list.php) just displays $events as HTML.
// A MODEL (app/Models/EventModel.php) would fetch $events from MySQL.
?>
Quiz
MVC માં database સાથે વાત કરવાની અને data સંભાળવાની જવાબદારી કયા સ્તરની છે?
- View
- Model
- Controller
- Router
Show the answer
Model
MODEL એ data નું સ્તર છે: એ database સાથેની આપલે અને ધંધાનો data સંભાળે છે (registrations લાવવાં અને સાચવવાં). VIEW ફક્ત રજૂઆત છે (user ને દેખાતું HTML). CONTROLLER સંકલન કરે છે: એ request મેળવે છે, Model પાસેથી data માગે છે અને એને View ને આપે છે, પણ સ્વચ્છ MVC માં એની અંદર કાચો database નો code ન હોવો જોઈએ. Router (જે MVC નાં 3 સ્તરમાંનું એકેય નથી) URLs ને controller ની methods સાથે જોડે છે. આ કામોને અલગ રાખવાં એ જ આખો હેતુ છે: data Model માં, દેખાવ View માં, સંકલન Controller માં. એમને ભેળવવાં (View ની અંદર SQL) એ જ એ ખરાબ ઢબ છે જેને અટકાવવા MVC અસ્તિત્વમાં છે.
Think first
Request ને MVC માંથી પસાર થતો તપાસો
કોઈ user CodeIgniter વાળા portal પર /events ખોલે છે. Routing અને MVC નાં 3 સ્તર થઈને render થયેલા page સુધીનો request તપાસો. પછી tap કરો.
Show the answer
1: Routing /events વાળા URL ને Events controller ની index() method સાથે મેળવે છે. 2: Controller (Events::index) ચાલે છે: એ સંકલન કરનાર છે. 3: એ Model (EventModel) પાસે event નો data માગે છે, જે MySQL ને query કરીને records પાછા આપે છે: data નું logic અહીં જ રહે છે. 4: Controller એ data View (events_list.php) ને આપે છે, જે એને HTML તરીકે render કરે છે: રજૂઆતનું logic અહીં રહે છે. 5: તૈયાર HTML browser પર પાછું જાય છે. દરેક સ્તરે બરાબર એક જ કામ કર્યું: route એ controller સુધી પહોંચાડ્યું, controller એ સંકલન કર્યું, model એ data લાવ્યો, view એ બતાવ્યું. URL થી route, route થી controller, controller થી model અને model થી view સુધીનો આ સ્વચ્છ flow એ જ MVC નું request નું ચક્ર છે, અને એને ક્રમમાં કહી બતાવવું એ પરીક્ષાનો મુખ્ય જવાબ છે.
Watch out
MVC અને CodeIgniter ના ફાંદા
View કે Controller માં SQL: database નો code Model માં જ રહેવો જોઈએ; એને બીજે ઢોળવાથી separation તૂટે છે.
Controller માં HTML: રજૂઆત View માં જ રહેવી જોઈએ; controllers સંકલન કરે છે, pages છાપતાં નથી.
URL એટલે file એમ સમજવું: CI માં routes URLs ને controller ની methods સાથે જોડે છે, ખરી .php files સાથે નહીં.
Config છોડી દેવું: base URL અને database ની settings ગોઠવવી જ પડે, નહીં તો app વિચિત્ર વર્તન કરે છે.
Framework સામે લડવું: CI એ આપેલાં tools (routing, validation) વાપરો, એમની આસપાસ ફરીને જાતે બધું બનાવવાને બદલે.
Theory
માળખું ગોઠવાયું; હવે એનાં શક્તિશાળી tools
MVC અને routing સાથે portal વ્યાવસાયિક રીતે ગોઠવાયું છે: data, રજૂઆત અને logic સ્વચ્છ રીતે અલગ. Unit 3 નો છેલ્લો પાઠ CodeIgniter નાં અંદરથી મળતાં શક્તિશાળી tools વાપરે છે: એની form-validation ની library, session તથા flashdata નું સંચાલન, file uploads, અને ફરી વાપરી શકાય એવાં helpers તથા libraries, જેથી unit માં અગાઉ તમે હાથે લખેલું પુનરાવર્તિત કામ framework કરી આપે. પછી Unit 4 IKS ના ખગોળના વિષય તરફ વળે છે. Framework હવે પોતાનું મૂલ્ય સાબિત કરે છે.
Summary
Key takeaways
- Framework માળખું અને ફરી વાપરી શકાય એવાં components આપે છે; CodeIgniter એ PHP નું પરંપરાગત MVC framework છે (CI4).
- MVC જવાબદારીઓ અલગ પાડે છે: Model (data અને database), View (રજૂઆત તથા HTML), Controller (logic અને સંકલન).
- જવાબદારીઓની separation apps ને સંભાળી શકાય એવી બનાવે છે: એક સ્તર બદલો તો પણ બીજાં તૂટતાં નથી.
- ગોઠવણ: Composer થી install કરો, base URL તથા database ગોઠવો, અને development નો server ચલાવો.
- Routing URL ને Controller ની method સાથે જોડે છે (ખરી file સાથે નહીં); default controller ઘરના રસ્તાને સંભાળે છે.
- Request નું ચક્ર: URL -> route -> controller -> model (data) -> view (HTML) -> browser.
- યાદ રાખવાની કડી: Model એટલે data, View એટલે દેખાવ, Controller એટલે સંકલન.