Smarty er faktisk ikke en «Mal Engine", det ville være mer nøyaktig beskrevet som en "mal / Presentasjon Framework." Det vil si, det gir programmereren og mal designer med et vell av verktøy for å automatisere oppgaver som vanligvis behandles på presentasjonen laget av en søknad. Jeg understreke ordet Work fordi Smarty er ikke en enkel tag-erstatter mal motor. Selv om det kan brukes til en slik enkel formål, er dens fokus på rask og smertefri utvikling og utrulling av søknaden din, og samtidig opprettholde høy ytelse, skalerbarhet, sikkerhet og fremtidig vekst.
Så er Smarty riktig for deg? Hva det kommer ned til er å bruke riktig verktøy for jobben. Hvis du vil ha enkel variabel erstatning, kan det være lurt å se på noe enklere eller rulle din egen. Hvis du vil ha en robust templating rammeverk med en rekke verktøy for å hjelpe deg som din søknad utvikler seg inn i fremtiden, er Smarty sannsynligvis et godt valg.
Hvorfor bruke det?
En av Smartys primære design mål er å legge til rette for separasjon av applikasjonskoden fra presentasjonen. Vanligvis inneholder applikasjonskoden forretningslogikk av søknaden din, skrevet og vedlikeholdes i PHP-kode. Denne koden blir vedlikeholdt av programmerere. Presentasjonen er måten innholdet presenteres for sluttbrukeren, som er skrevet og vedlikeholdes i malfiler. Malene er vedlikeholdt av mal designere.
I sin mest grunnleggende funksjon, henter programmet kodeinnholdet, tildeler det til mal motor og viser det. Innholdet kan være noe sånt som overskriften, slagord, forfatter og kroppen til en avisartikkel. Applikasjonskoden har ingen bekymring hvordan dette innholdet vil bli presentert i malen. Malen designer er ansvarlig for presentasjon. De redigere malfiler, legge markup og bringe den til ferdigstillelse. Dette innebærer vanligvis ting som HTML-koder, stilark og andre verktøy levert av malen motoren.
Dette paradigmet tjener flere formål:
) Designere kan ikke bryte applikasjonskode. De kan rote med maler alt de ønsker, men koden forblir intakt. Koden vil bli strammere, sikrere og enklere å vedlikeholde.
) Feil i malene er begrenset til Smartys feilhåndteringsrutiner, noe som gjør dem så enkel og intuitiv som mulig for designeren.
) Med presentasjon på sitt eget lag, kan designere endre eller helt redesign det fra scratch, uten innblanding fra programmereren.
) Programmerere ikke rote med maler. De kan gå om å opprettholde applikasjonskoden, endre måten innholdet er ervervet, gjør nye virksomhetsregler osv uten å forstyrre presentasjonen laget.
) Maler er en nær representasjon av hva det endelige resultatet vil bli, noe som er en intuitiv tilnærming. Designere bryr meg ikke hvor innholdet kom til malen. Hvis du har utenforliggende data i malen som en SQL-setning, åpner denne risikoen for å bryte programkode ved utilsiktet sletting eller endring av designeren.
) Du er ikke åpne serveren til kjøring av vilkårlig PHP-kode. Smarty har mange sikkerhetsfunksjoner innebygd slik at designere vil ikke bryte sikkerhet, enten tilsiktet eller utilsiktet. De kan bare gjøre det de er begrenset til i malene.
Selv om applikasjonskode er skilt fra presentasjonen, dette betyr ikke nødvendigvis at logikken blir skilt fra. Applikasjonskoden åpenbart har logikk, men malene kan ha logikk basert på betingelse av at det er for presentasjonen bare. For eksempel, hvis designeren ønsker å veksle bord rad farger eller store bokstaver noen tilordnet innhold, kan de. Dette er presentasjonen logikk, noe programmerer bør ikke være opptatt av. Hvor ofte har du hatt noen presentasjon vises i en enkelt kolonne, og deretter du ville ha det i to eller tre kolonner, slik at applikasjonskoden må justere for å imøtekomme dette? En bedre metode er å tildele innholdet i en enkelt rekke og la malen håndtere presentasjonen. Dette vil forenkle din søknad og holde maler fleksibel. Smarty leverer verktøy for å håndtere denne type situasjon.
Dette betyr at Smarty hindrer deg fra å sette programmet logikken i malen ikke, må du ha en bit av selvdisiplin. Her er et eksempel på å bygge forretningslogikk i malen (som er riktig, unngå å gjøre dette hvis det er mulig):
{If $ smarty.session.user og ($ user_type eq "redaktør" eller $ user_type eq "admin")}
rediger
{/ If}
De logiske sjekker om brukeren er logget inn, og de er enten en redaktør eller administrator, så de får lov til å redigere denne så avkrysningsredigerings dukker opp. Det er logikk som hører til i applikasjonskoden. Malen bryr seg ikke om hva legitimasjon denne brukeren har, det bare trenger å vite om redigeringsfeltet vises eller ikke! Så la oss se på et mer passende tilnærming:
{If $ edit_flag}
rediger
{/ If}
Det er opp til søknaden programmerer å tildele $ edit_flag, en enkel og lett å forstå variabel i malen. På denne måten malen er ikke lenger avhengig av underliggende datastruktur. Hvis formatet av sesjonen datastrukturen stadig endres, må noe som skal justeres i malen.
Nå skal vi se på et par ting du kan gjøre med Smarty. En ting den kan gjøre er egendefinerte funksjoner. Dette er koder i malen som utfører en bestemt oppgave. Eksempel:
{Html_image file = "masthead.gif"}
Her har vi en funksjon som heter "html_image". Denne funksjonen tar bildet gitt i "fil" attributt og gjør alt arbeidet er nødvendig for å komme opp med følgende HTML-kode:
Bildet funksjon gjorde ork å finne ut høyden og bredden og leverer standard grensen flagget. Selvfølgelig kan du bare bruke statiske HTML-koden i malen i stedet, men dette viser hvordan en egendefinert funksjon kan benyttes for å forenkle en svært vanlig oppgave. Designeren kan fokusere på design og mindre på tekniske ting. Videre, hvis designer bestemmer seg for å slippe inn en annen størrelse mastetoppen bilde, ikke malen trenger justering.
html_image er en funksjon som kommer med Smarty. Du kan også lage dine egne egendefinerte funksjoner. Her er et annet eksempel på hva man kan se slik ut:
{Html_link type = "artikkel" id = "abc123" text = "Brann tar ut Hotel"}
Dette er å bruke en egendefinert funksjon som heter "html_link". Den kommer opp med følgende HTML-kode:
Brann tar ut Hotel
Hva betyr dette oppnå? For ett, ikke designer trenger ikke å være opptatt av formatet på en URL til en artikkel. Med hardkodet webadresser, hva skjer hvis en dag programmerer bestemmer seg for å rydde ting opp, og endrer URL-syntaksen fra /display_article.php?id=abc123 til / ART / abc123? Vi måtte redigere hver mal med en artikkel URL. Dette er bare et eksempel på hvordan en mal funksjon kan lage maler enklere å vedlikeholde.
Nå for litt på programmerere og maler. Tidligere ble det nevnt at programmereren har ingen omsorg for hva malene gjøre med innholdet. På et konseptuelt nivå dette er sant, men i den virkelige verden du ikke kommer til å forvente malen designer til å konstruere alle malene ut av løse luften. Tross alt, gjør forretningslogikk bestemme hvilket innhold er tildelt malene. I så fall vil programmereren typisk oppsett Rammeverk maler for designeren å begynne med. Denne inneholder vanligvis rå elementer som innhold variabler og seksjons looper, og kanskje et par enkle kodetagger slik at de ikke begynner med innholdet i et stort rot. Her er et eksempel på et skjelett mal som looper gjennom en liste over artikler og viser dem i en tabell:
| {$ artikkel [kunst] .headline} | {$ artikkel [kunst] .date} | {$ artikkel [kunst] .author} |
Utgangen kan se omtrent slik ut:
| Hvordan Vesten ble vunnet | 2 desember 1999 | John Wayne | |||
| Team taper, avslutter trener | 2 februar 2002 | John Smith | |||
| Gourmet Cooking | 23 januar 1954 | Betty Crocker |
Nå for noen vanlige spørsmål:
Hvorfor bruke maler i det hele tatt? Hva er så tøff om å skrive I stedet for {$ title}?
Å gjøre ting enklere å lese var ikke et design mål, men mer av en bivirkning. Bruke maler har store fordeler, hvorav mange har blitt forklart ovenfor. Siden vi er i en mal miljø anyways, er {$ title} mindre overflødig enn , Spesielt når du begynner å se på det i lange sider med innhold, så det var ganske åpenbart at en enklere syntaks bidrar til å lage maler lettere å lese og vedlikeholde.
Mal ta tid å analysere, lage applikasjoner mye tregere.
Det kan være sant i noen tilfeller, men med Smarty det er ikke tregere enn å utføre et PHP-skript. På den første henrettelsen av en mal, konverterer Smarty malen filer til PHP-skript (kalt mal kompilering.) Deretter PHP-skript bare inkludert. Par dette med en PHP gasspedalen og du virkelig har en rask templating miljø med minimal overhead.
Smarty er for komplisert, hvordan kan det være så rask?
Smarty kjerne er ganske mager vurderer hva det er i stand til. Det meste av funksjonaliteten ligger i plugins. Plugin arkitektur er utformet slik at bare de nødvendige plugins er lastet på forespørsel. Med denne rammen vil legge hundrevis av nye plugins ikke påvirke ytelsen. Dette gjør Smarty rask, skalerbar og fleksibel.
Smarty har også caching funksjoner som dynamisk kan oppdatere og holde deler av siden uncached på din smak. Caching lagrer resultatet av den kompilerte maler, sparer behovet for å utføre dem på hver påkalling.
Alt dette snakket om akseleratorer, hvordan Smarty kjøre uten en?
Faktisk det går ganske bra uten en. Smarty krever ikke en akselerator, men malen filene selv vil dra nytte av en, noe som er unikt for Smarty (AFAIK). Hvis du ikke har en akselerator, er utførelsen malen ikke så fort, men ikke treg på noen måte, siden de ikke er analysert! Du også beholde alle de andre fordelene og funksjonene til Smarty. Også, siden akseleratorer er fritt tilgjengelig det er egentlig ikke en unnskyldning for å ikke bruke ett. De vil hjelpe ytelse med alle PHP apps, bruker Smarty eller ikke.
Hvordan kan det være enklere å vedlikeholde?
Enkelte ting kan ikke forklares, men bare oppleves. Fordelen med separasjon av programmet logikken fra presentasjonen kan ikke understrekes nok. Smarty har også noen fine feilhåndtering funksjoner og en innebygd debugging konsollen, slik at du kan se malen hierarki og tilordnet variabler på et øyeblikk. Legge til egendefinerte funksjoner til Smarty er like enkelt som å slippe dem i plugin katalogen og nevne dem i malen.
De malkodene ikke XML-basert, redaktøren min ikke liker det.
De {} skilletegn er bare en standard, de er enkle å skjelne mellom HTML-koder. Hvis du ikke liker dem, endre skilletegn eller kanskje noe mer XMLish som Det er også mange bruker bidrag til Dreamweaver og lignende, gi dem en titt i bidrag området.
Det er Smarty i et nøtteskall, forhåpentligvis kan du legge det til ditt arsenal av verktøy for web-applikasjon bygningen. For virkelig å lære mer, lese manualen topp til bunn, delta i fora og se hva folk diskuterer
Egenskaper .
- Caching: Smarty gir finkornede caching funksjoner for caching hele eller deler av en gjengitt nettside, eller forlate deler uncached. Programmerere kan registrere mal fungerer som hurtiglagerbar eller ikke-lagres, gruppe bufrede sider i logiske enheter for enklere administrasjon, osv.
- konfigurasjonsfiler: Smarty kan tilordne variabler trukket fra konfigurasjonsfiler. Mal designere kan opprettholde verdier som er felles for flere maler på ett sted uten innblanding fra programmerer, og config variabler kan enkelt deles mellom programmering og presentasjon deler av programmet.
- Sikkerhet: Maler inneholder ikke PHP-kode. Derfor er en mal designer ikke sluppet løs med full effekt av PHP, men bare den delen av funksjonalitet gjort tilgjengelig for dem fra programmerer (programkode.)
- Enkel å bruke og vedlikeholde: Web sidedesignere forholder seg ikke med PHP-kode syntaks, men i stedet en lett-å-bruke templating syntaks ikke mye annerledes enn vanlig HTML. Malene er et veldig nært bilde av det endelige resultatet, dramatisk forkorte design syklusen.
- Variable Modifikatorer: Innholdet av tildelte variabler kan lett justeres på skjerm-tid med midler, som viser i alt store bokstaver, html-escaped, formatering datoer avkorting tekstblokker, og legger til mellomrom mellom tegn, etc. Igjen Dette gjøres uten innblanding fra programmereren.
- Mal Funksjoner: Mange funksjoner er tilgjengelige for malen designer til å håndtere oppgaver som genererer HTML kode segmenter (nedfellsmenyen, tabeller, pop-ups, etc.), viser innhold fra andre maler i-linje, looping løpet matriser av innhold , formatering av tekst for e-post-utgang, sykling om farger osv.
- Filter:. Programmereren har full kontroll over mal produksjon og utarbeidet mal innhold med pre-filter, post-filtre og utgangsfiltre
- Resources.: Maler kan trekkes fra en rekke kilder ved å skape nye ressursbehandlere, deretter bruke dem i malene
- Plugins: Nesten alle aspekter av Smarty styres gjennom bruk av plugins. De er vanligvis så enkelt som å slippe dem inn i plugin katalogen og deretter nevne dem i malen eller bruke dem i applikasjonskoden. Mange bruker-samfunnet bidrag er også tilgjengelig. (Se plugins delen av forumet og wiki.)
- Add-ons: Mange bruker-samfunnet bidratt Add-ons er tilgjengelige for eksempel paginering, Form Validation, drop down menyer, Calander Dato Pickers, etc. Disse verktøyene hjelper fremskynde utviklingen syklus, er det ikke nødvendig å re- oppfinne hjulet eller debug kode som allerede er stabilt og klart til bruk. (Se Add-ons delen av forumet og wiki.)
- Debugging:. Smarty leveres med en innebygd debugging konsollen, slik malen designer kan se alle de tildelte variabler og programmerer kan undersøke mal gjengivelse hastigheter
- Kompilering:. Smarty kompilerer maler i PHP-koden bak kulissene, eliminerer run-time analyse av maler
- Ytelse: Smarty utfører svært godt, til tross for sin enorme utvalg av funksjoner. De fleste av Smarty evner ligge i plugins som er lastet on-demand. Smarty leveres med en rekke presentasjonsverktøy, minimere søknaden din kode og resulterer i raskere, mindre utsatt for feil applikasjonsutvikling / distribusjon. Smarty maler bli kompilert til PHP-filer internt (en gang), eliminerer kost mal fil skanner og utnytte hastigheten på PHP op-kode akseleratorer.
Hva er nytt i denne versjonen:
- tilbake super global tilgang endringer, og i stedet stole på USE_SUPER_GLOBALS for sikkerhet
Hva er nytt i versjon 2.6.23:
- strippe backticks fra {matematiske} ligninger (mohrt)
- kaste feil når malen eksisterer, men ikke lesbar (mohrt)
Hva er nytt i versjon 2.6.22:
- Denne utgivelsen løser et problem som oppstår med Smarty 2.6 .21 utgivelse og en PCRE motor bug i PHP 5.2. Metoden kjeding er fjernet for å unngå feil. Metode kjeding vil dukke opp i Smarty 3.
Kommentarer ikke funnet