У гэтым артыкуле я гляджу на выкарыстанні Zend_Layout і Zend_View разам з простымі фронт-кантролера, каб паказаць, як можна пачаць падзяляюць бізнэс-логікі і прадстаўлення ў вашым дадатку. Усе коды даступныя на GitHub:
Голы Zend_Layout і Zend_View на GitHub .

MVC

Агульны шаблон дызайну для сучасных вэб-прыкладанняў з'яўляецца шаблон MVC. Zend Framework ў рэжыме "поўны стэк з'яўляецца адным рэалізацыі MVC ў PHP і складаецца з трох частак:

• Мадэль (М)
• Паказаць (V)
• Кантролер (С)

Карціны пабудаваны так, што бізнес і логікі прадстаўлення цалкам аддзеленыя адзін ад аднаго (з бізнес-логікі ў мадэлі, і прадстаўленне ва ўяўленні) і кантролер сядзіць у сярэдзіне правядзення "аркестр".

Прэзентацыя і логікі

У Zend Framework гледжання апрацоўваюцца два асноўных кампанента: Zend_View і Zend_Layout. Zend_Layout як вынікае з назвы выглядае пасля макет аспект сайта (як правіла, верхнія і ніжнія колонтитулы, бакавыя панэлі і г.д.). Zend_View факусуюць на прадстаўленне даных, што мадэль працуе вырабляць ці атрымліваць.

Як распрацоўшчыкі, і іх прыкладання, развівацца, мы, як правіла, рухацца праз розныя этапы, як правіла, кожнае паляпшэнне ў параўнанні з папярэднім, павышэння эксплуатацыйнай надзейнасці і пашыральнасцю. Адзін з асноўных пытанняў з'яўляецца тое, што ўяўленні і логікі яшчэ атрымаць далучаныя і не проста пачаць, падзяляльнай дзве.

Што здарылася з мяшаннем два?

Там на некалькі прычын, чаму змешвання розных частак прыкладання, напрыклад, дызайнер, які працуе на вашым сайце не можаце (ці веды) для сканавання вакол у кодзе спрабуючы зразумець, дзе, каб зрабіць прэзентацыю змены. Сапраўды гэтак жа распрацоўнік (калі вы, як мне, хто мае дызайн навыкаў страуса) можа выліцца ў халодны пот, калі вы згадвае дызайн карыстальніцкага інтэрфейсу ці працы.

Акрамя таго, што калі ў далейшым вы хацелі б прадставіць свае сайты на розных носьбітах, такіх як мабільныя тэлефоны, планшэтныя ПК, і не падвяргайце дадзеных праз вэб-сэрвісы (XML / JSON / і г.д.)? Змяшаўшыся прадстаўлення і логікі вы стаіце практычна няма надзеі, не вельмі выродлівыя хакі цягнуць прэзентацыі таму з вашага кода, перад ін'екцыяй нешта новае. Калі дадзеныя і прэзентацыі быў аддзелены ўнясення гэтых змяненняў амаль трывіяльныя, стварыце новы скрыпт выгляду для новага фармату і прамых запытаў па меры неабходнасці.

Падзел гэтых двух

У якія развіваюцца яго прымяненне не заўсёды эканамічна прыступіць да ажыццяўлення поўнага рашэння MVC і дадатак павінна быць перанесеныя павольна - часам працуе стары код паралельна з новымі. Гэта можа быць, Ёсць маса логікі (напрыклад, базы дадзеных налады злучэння, аўтэнтыфікацыя, апрацоўку файлаў "cookie і г.д.), якія не гатовыя для ліцця па абранай Вамі рамкі ўстаноўкі, таму старыя і вядомыя, каб быць працуе код можна працягваць выкарыстоўвацца да тых часоў, яна можа быць перапісана / рэарганізавана.

Заўвага: Выкарыстаньне Zend_Layout і Zend_View, як гэта цалкам прымальна ў рамках пейзаж Zend і рамкі быў распрацаваны так, што асобныя кампаненты могуць быць выкарыстаны без астатняй рамкі. Вялікая перавага ў змяняюцца прыкладанняў і, верагодна, адной з асноўных прычын высокага паглынання ў карпаратыўных дадатках.

Фронт-кантролер

Ніжэй я стварыць фронт-кантролера - адзін файл прызначаны, каб забраць якія-небудзь просьбы, якія не адпавядаюць файл на файлавай сістэме. Часта гэта дасягаецца з дапамогай. Htaccess файлаў, такіх як той, якая выкарыстоўваецца ў Zend Framework па змаўчанні ўстаноўкі. У фронт-кантролер я буду стварэння нашага макета і прагляду і паказваюць, дзе розныя часткі прыкладання слізгацення ў яе.

  DEFINE ('APP_PATH, імя папкі (__FILE__ ).'/..');
 / / Пачаць буферызацыю вываду
 ob_start ();

 / / Стварэнне экзэмпляра Zend_View
 Zend_Layout:: startMvc ();
 $ Zend_Layout макета =:: getMvcInstance ();
 $ Макет-> setLayoutPath (APP_PATH ". / Макет / скрыптоў)
     -> SetViewSuffix ('Phtml)
     -> SetLayout ("індэкс");

 $ = $ Гледжання тапалогіі> GetView ()
     -> SetScriptPath (APP_PATH / прадстаўленне / сцэнары ".)
     -> AddHelperPath (. APP_PATH '/ Library / Zend / View / Helper "," Zend_View_Helper');

 / / Устанавіць Базавы URL - OK * * амаль голы, але вам не трэба гэта!
 Zend_Controller_Front:: GetInstance () -> setBaseUrl ($ _SERVER ['HTTP_HOST']);

 паспрабуйце {
     / **
      * Выканайце якое-небудзь прыкладанне маршрутызацыі ...
      * - Можа быць выкарыстоўваючы гэта ў якасці фронт-кантролера і накіроўваючы ўсе запыты
      * Праз гэты файл (пры ўмове, файл не існуе ў файлавай сістэме
      * - Звярніце ўвагу на метад ніжэй толькі для дэманстрацыі сапраўды, было б
      * Жудаснае з вялікай сайт
      * /
     Пераключальнік ($ ['старонкі'] _GET) {
    	 выпадку "індэкс":
    	 выпадку "выключэння":
    		 $ PageName = $ ['старонкі'] _GET;
    		 перапынку;
    	 па змаўчанні:
    		 $ PageName = False;
    		 перапынку;
     }
     / / Прыклад старонка не знойдзена ...
     калі (ілжывыя === $ PageName) {
         $ ResponseHeader = 'HTTP/1.1 404 Старонка не знойдзена ";
         кідаць новыя Exception ("Старонка не знойдзена");
     }

     / **
      * Даданне дадзеных у свае аб'екты тут
      * Вы можаце мець сваю ўласную рэалізацыю кантролера або якой-небудзь ўключае файлы
      * Калі бізнес-логіка часткова аддзеленая ад гледжання логікі
      * /
     $ Выгляд-> DisplayText = 'Прывітанне з Лойда;
     $ Выгляд-> ButtonText = 'I \' M не актыўная!;

	 $ Макет-> Змест = $ Выгляд-> Render (". {$} PageName Phtml");
     Рэха $ макет-> Render ();
 } Catch (Exception $ E) {
	 / / Ачысціце ўжо буферам зьместу - мы не хочам, каб адлюстраваць гэта!
	 ob_clean ();
     калі (! isset ($ responseHeader)) {
    	 $ ResponseHeader = 'HTTP/1.1 500 Internal Server Error ";
     }
     загалоўка ($ responseHeader);
     $ Выгляд-> выключэння = $ E;
     $ Макет-> Змест = $ Выгляд-> Render ("error.phtml ');
     Рэха $ макет-> Render ();
 } 

Па-першае мы пачынаем буферызацыю высновы, тым самым мы можам ўсталяваць нашы загалоўкі ў любы момант запытаць і ведаю, што гэта магчыма, каб адправіць іх. Калі выключэнне быць кінутыя на любой стадыі выканання кода мы ачысціць гэты буфер і выпісаць або памылкі ўтрыманне паведамленні і макет. Гэта гарантуе, што мы не пастаўляюць частка адлюстроўваецца змесціва, якія змяшчаюць памылкі, каб канчатковы карыстальнік.

Наступны новы асобнік MVC з Zend_Layout генеруецца і кажам яму, што з макета сцэнарыяў маюць пашырэнне Phtml, якія можна знайсці ў каталогу па-за грамадскага шляху, і што наш макет па змаўчанні называецца індэкс (. Phtml). Ад макета мы затым выняць аб'ект віду (да якіх мы ўсталёўваем дадзеныя, якія будуць прадстаўлены) і ўжываць аналагічныя ўстаноўкі.

Далей ўстаноўкі аб'екта віду са спасылкай на змаўчанні Zend_View памочнікаў. Адкрыць памочнікі мноства дадатковых функцый выгоды. Напрыклад, ліст з паплаўка у грашовым фармаце, а таксама стварэнне зебры паласатыя табліцы (іх можна прачытаць пра тут ). Пашыраючы Zend_View_Helper_Abstract і дадаць сваю ўласную бібліятэку, у гэты момант яго можна выкарыстоўваць свае ўласныя памочнікі гледжання прыкладання.

Астатняй код прыкладання ў сапраўдны момант акружаная паспрабаваць злавіць {} {} блока. Калі што-небудзь кінуць непрадугледжаных выключэння мы можам злавіць яго і паказаць добры паведамленне пра памылку на канчатковага карыстальніка.

Наша першая задача ў рамках паспрабаваць злавіць {} {} з'яўляецца маршрут наш запыт, што ж вы хочаце яго бачыць? Тут я рэалізаваныя некаторыя вельмі простыя дэманстрацыі кода, дзе я магу праверыць значэнне "старонцы" Атрымаць зменнай. Маршрутызацыі можа быць вельмі шмат складаней. Маршрутызацыі выкарыстоўваецца для выкліку што калі-небудзь кода трэба выканаць, каб атрымаць / апрацоўваць дадзеныя, прадастаўленыя карыстальнікам і сказаць сістэме, што меркаванне (і, магчыма, скрыпт макета) для выкарыстання.

У рэшце рэшт, калі наш маршрутызатар не адпавядае любой старонкі усталёўваецца 404 код адказу і паказвае добры старонка не знойдзена паведамленне для канчатковага карыстальніка. Тут, мы кідаем і злавіць нашых уласных выключэнне (і вельмі агульныя выключэння ў гэтым), але, верагодна, вы будзеце кідаць ўласнае выключэнне ўнутры маршрутызатара кода.

Пасля таго як мы паспяхова накіроўваецца наш запыт мы можам пачаць рабіць што-то з кодам. Можа быць, у вас ёсць свой кантралёры / Мадэлі выкананы або ўключыць код, які ўжо быў аддзелены некалькі. Тут я паставіў пару простых зменных для прагляду аб'екта.

Як толькі гэта будзе скончана, мы проста аказваем думкамі з нашымі дадзенымі. Калі код кідае неперехваченное выключэнне якой-небудзь прычыне гэта захопленых у ніжняй часткі скрыпту. Тут мы ясна ўжо буферам прадукцыі, набор 500 загаловак адказу, і сказаць наша дадатак аказваць скрыпт "памылкі" (якія, як правіла, значна ўсечаную версію нармальнага макет / прагляду і часопісы памылкі для праверкі пазней).

Так як прадстаўленне аказваецца першым і ўводзяць у макет можна змяніць структуру знутры гледжання, ды і набор неабходных дапаўненняў, напрыклад,

• Назва старонкі
• Мэта-тэгі
• Сцэнарыі (URL або код) у раздзеле <head>
• Дадаць дадатковыя стылі і г.д.

Акрамя таго яго можна нават змяніць увесь макет у прадстаўленні з дапамогай ...

  макет () <PHP $-это?> -> setLayout ('alternativeLayout')>? 

... Як і ў выпадку неабходнасці.

І нарэшце ...

Я спадзяюся, што гэта было карысным увядзеннем у Zend_Layout і Zend_View і гэта дазволіць вам пачаць рэалізацыю ўласных асноўных MVC і палепшыць maintainibility / пашыральнасць кода. Калі ласка, паглядзіце на зыходны код для прыкладаў выкарыстання (гл. README файл для інструкцый).

Код мяркуе, што ў вас ужо ёсць Аўтазагрузка працуе (ці вы ўключылі неабходныя класы). Акрамя таго, я не рэкамендую вам ажыццяўляць маршрутызацыю дадзеных або ўстаноўка, як і вышэй, гэта вельмі спрошчаная для дэманстрацыі. Каб убачыць поўны код паглядзець на зыходны код звязаны ў верхняй частцы гэтага артыкула.

Zend Framework версіі: 1.10.6

Адзін адказ на "Голая Zend_Layout і Zend_View"

1. Эндзі кажа:

   Серада 11 Жніўня 2010 года ў 2:33 вечара

   Добра напісаная і найбольш інфарматыўным, дзякуй!

   Адказаць