I denna artikel tittar jag på med Zend_Layout och Zend_View tillsammans med en enkel front controller för att visa hur det är möjligt att starta separera affärslogik och presentation i din ansökan. All kod finns på GitHub:
Naked Zend_Layout och Zend_View på GitHub .

MVC

En gemensam design mönster för moderna webbapplikationer är MVC mönstret. Den Zend Framework i "full stack"-läge är en implementation av MVC i PHP och består av tre delar:

• Modell (M)
• Visa (V)
• Controller (C)

Mönstret är utformat så att näringslivet och presentation logik är helt separerade från varandra (med affärslogik i modellen, och presentation i bild) och regulatorn sitter i mitten som utför "orkester".

Presentation och Logic

I Zend Framework anser hanteras av två huvudkomponenter: Zend_View och Zend_Layout. Zend_Layout som namnet antyder tar hand om layouten aspekt av området (i allmänhet sidhuvud, sidfot, sidofält, etc). Zend_View fokuserar på att presentera de data som modellen har arbetat med att producera eller härleda.

Som utvecklare och deras tillämpningar, utvecklas tenderar vi att gå igenom olika stadier, vanligen varje en förbättring jämfört med tidigare, förbättra underhållet och utbyggbarhet. En av de viktigaste frågorna är att presentation och logik ändå få samsas och det är inte enkelt att starta mellan de två.

Vad är fel med att blanda de två?

Det finns flera orsaker till att blanda olika delar av programmet, till exempel en designer som arbetar på din webbplats kanske inte vill (eller har kunskap) för att skanna runt i koden försöker ta reda på var att göra presentationen förändringar. På samma sätt en utvecklare (om du som mig som har färdigheter av en struts) kan bryta ut i en kall svett när du nämner design eller UI arbete.

Dessutom vad händer om du senare skulle vilja presentera dina webbplatser på olika medier, som mobiltelefoner, Tablet PC, eller exponera data via Web Services (XML / JSON / etc)? Efter att ha blandat presentation och logik man står nästan inget hopp utan några mycket fula hack att dra presentationen tillbaka ut i din kod, innan du injicerar något nytt. Om data och presentation har skilts göra dessa förändringar är nästan trivial, skapa en ny vy manus för det nya formatet och direkta förfrågningar så är lämpligt.

Som skiljer de två

I ett framväxande ansökan dess inte alltid ekonomiskt att börja genomföra en fullständig lösning MVC och ansökan måste migreras långsamt - ibland kör gammal kod parallellt med nya. Det kanske att det finns massor av logik (såsom databas anslutningsinställningen autentisering, hantering av cookies, etc) som inte är redo för gjutning till valt ramar setup, därför gamla och kända-att-vara-fungerande kod kan fortsätta att användas tills den kan skrivas om / omstrukturerade.

Obs: Zend_Layout och Zend_View gillar detta är helt acceptabelt i Zend Framework landskapet och ramen har konstruerats så att enskilda komponenter kan användas utan resten av ramen. En stor fördel i att utvecklas ansökningar, och förmodligen en av de viktigaste skälen för högt upptag i företagets tillämpningar.

Front Controller

Nedan har jag skapa en front controller - en enda fil för att plocka upp alla förfrågningar som inte motsvaras av en fil på filsystemet. Detta uppnås ofta med hjälp av en. Htaccess-fil som den som används i den förvalda Zend Framework installera. Inom den främre regulatorn jag kommer att bygga upp vår layout och visa och visar var de olika delarna av ansökan glida in i den.

  define ('APP_PATH ", dirname (__FILE__).'/..');
 / / Start buffrande effekt
 ob_start ();

 / / Skapa en instans Zend_View
 Zend_Layout:: startMvc ();
 $ Layout = Zend_Layout:: getMvcInstance ();
 $ Layout-> setLayoutPath (APP_PATH. '/ Layout / scripts ")
     -> SetViewSuffix (phtml)
     -> SetLayout ("index");

 $ View = $ layout-> getView ()
     -> SetScriptPath (APP_PATH "/ visa / scripts".)
     -> AddHelperPath (. APP_PATH "/ Library / Zend / Se / Helper", "Zend_View_Helper ');

 / / Ställ Grundwebbadress - ok * nästan * naken, men du behöver inte detta!
 Zend_Controller_Front:: getInstance () -> setBaseUrl ($ _SERVER ['HTTP_HOST']);

 try {
     / **
      * Utföra vissa ansökan routing ...
      * - Skulle kunna använda detta som en front controller och styra alla förfrågningar
      * Genom denna fil (förutsatt fil finns inte i filsystemet
      * - Not metoden nedan är egentligen bara för demonstration, det skulle vara
      * Hemsk med en större anläggning
      * /
     switch ($ _GET ['sida']) {
    	 fall "index":
    	 fall "undantag":
    		 $ Pagename = $ _GET ['sida'];
    		 break;
    	 standard:
    		 $ Pagename = false;
    		 break;
     }
     / / Exempel på en sida inte hittas ...
     if (falsk === $ pagename) {
         $ ResponseHeader = 'HTTP/1.1 404 Sidan kunde inte hittas';
         kasta nytt undantag ("Sidan kan inte visas ');
     }

     / **
      * Lägga till data i vyn objekt här
      * Du kan ha din egen controller genomförandet eller vissa inkluderar filer
      * Där affärslogik delvis separeras från tanke logik
      * /
     $ Visa-> displayText = 'Hello från Lloyd ";
     $ Visa-> buttonText = 'I \' m ej aktiv '!;

	 $ Layout-> innehåll = $ Visa-> render (". {$ Pagename} phtml");
     echo $ layout-> render ();
 } Catch (Exception $ e) {
	 / / Rengör redan buffrade innehåll - vi vill inte visa det!
	 ob_clean ();
     if (! isset ($ responseHeader)) {
    	 $ ResponseHeader = 'HTTP/1.1 500 Internal Server Error ";
     }
     header ($ responseHeader);
     $ Visa-> undantag = $ e;
     $ Layout-> innehåll = $ Visa-> render ("error.phtml ');
     echo $ layout-> render ();
 } 

Först börjar vi Utmatningsbuffer, genom att göra detta kan vi sätta våra huvuden vid någon punkt i begäran och vet att det är möjligt att skicka dem. Bör ett undantag kastas i något skede av kod vi städa buffert och skriva ut eller innehåll felmeddelande och layout. Detta garanterar att vi inte levererar del hämtat innehåll som innehåller fel till slutanvändaren.

Nästa en ny MVC instans av Zend_Layout genereras och vi berättar det som anges layout skript har ändelsen phtml, finns i en katalog utanför det offentliga väg och att vår standardlayouten kallas index (. Phtml). Från layout vi utvinner därefter att objektet (som vi sätter våra data som ska presenteras) och tillämpa liknande setup.

Nästa vi setup vyn objekt med en hänvisning till standard Zend_View hjälpare. View helpers är uppsättningar med ytterligare bekvämlighet funktionalitet. Till exempel skriver ut en växelkassa i monetär form, eller skapa en zebra randig bord (de kan läsa om här ). Genom att utvidga Zend_View_Helper_Abstract och lägga ditt eget bibliotek på denna punkt är det möjligt att använda din egen medhjälpare ansökan vy.

Resten av programkoden är nu insvept i en try {} catch {}-block. Skulle något kasta en felhantering undantag vi kan fånga den och visa ett trevligt felmeddelande till slutanvändaren.

Vår första uppgift i try {} catch {} är att styra vår begäran, vad användaren vill se? Här har jag genomfört några mycket enkel demonstration koden där jag kontrollera värdet på "sidan" få variabel. Din routing kan vara mycket mycket mer komplex. Dirigering används för att kalla det någonsin kod måste utföras för att få / hantera uppgifter från användaren och att tala om för systemet vad anser (och möjligen layout script) att använda.

Ytterst om vår router inte matchar någon sida den innehåller ett 404-svar-kod och visar en trevlig sida inte hittas budskap till slutanvändaren. Här kastar vi och fånga vår egen undantag (och ett mycket allmänt undantag på det) men antagligen du skulle kasta dina egna undantag inifrån routern kod.

När vi har lyckats dirigeras vår begäran kan vi börja göra något med koden. Det kan vara att du har en egen controllers / genomförs modeller eller du inkludera lite kod som redan har separerade något. Här har jag ställa ett par enkla variabler för att se objektet.

När denna är klar vi helt enkelt göra åsikter med våra data. Om koden kastar en felhantering undantag av någon anledning är fångade nära botten av skriptet. Här har vi tydligt redan buffrade utgång, som en 500 svarshuvud, och säga till våra program för att göra "fel" uppfattning script (vilket är i allmänhet en mycket avskalad version av den normala layouten / visa och loggar felet för kontroll senare).

Eftersom vyn renderas först och sprutas in i layouten är det möjligt att ändra layouten från inom synhåll, och faktiskt ställa krävs extramaterial, till exempel,

• Sidrubrik
• Metataggar
• Skript (webbadresser eller kod) i avsnittet <head>
• Lägg till ytterligare färger, etc

Dessutom har även möjligt att ändra hela layouten inifrån vyn med hjälp ...

  layout () <php $ this-?> -> setLayout (alternativeLayout ')>? 

... Och när detta behövs.

Slutligen ...

Jag hoppas att detta har varit en nyttig introduktion till Zend_Layout och Zend_View och det gör att du kan börja genomföra dina egna grundläggande MVC och förbättra maintainibility / utbyggbarheten av din kod. Ta en titt på källkoden för exempel på användning (se README filen för instruktioner).

Koden förutsätter att du redan har automatisk laddning som arbetar (eller du har inkluderat krävs klasser). Dessutom skulle jag inte rekommendera att du genomför routing eller datainmatning enligt ovan, är detta mycket förenklade för demonstration. För att se hela koden ta en titt på källkoden kopplade på toppen av denna artikel.

Zend Framework version: 1.10.6

En Svaren till "Naked Zend_Layout och Zend_View"

1. Andy säger:

   Onsdag 11 augusti 2010 kl 14:33

   Välskrivna och mest informativa, tack!

   Svara