Smarty er faktisk ikke en "Skabelon Engine", ville det være mere præcist kan beskrives som en "skabelon / Præsentation Framework". Det vil sige, det giver programmøren og skabelon designer med et væld af værktøjer til at automatisere opgaver almindeligvis behandles ved præsentationen lag af en ansøgning. Jeg understreger ordet Framework fordi Smarty er ikke en simpel tag-udskiftning skabelon motor. Selv om det kan bruges til sådan en simpel formål, dens fokus på hurtig og smertefri udvikling og implementering af din ansøgning, og samtidig opretholde høj ydeevne, skalerbarhed, sikkerhed og fremtidig vækst.
Så er Smarty rigtige for dig? Hvad det kommer ned til, er at bruge det rigtige værktøj til jobbet. Hvis du vil have enkel variabel udskiftning, kan du ønsker at se på noget enklere, eller endda rulle din egen. Hvis du ønsker en robust templating ramme med en lang række værktøjer til at hjælpe dig som din ansøgning udvikler sig i fremtiden, Smarty sandsynligvis et godt valg.
Hvorfor bruge det?
Et af Smartys primære design mål er at lette adskillelsen af applikationskode fra præsentationen. Typisk ansøgningen koden indeholder forretningslogik i din ansøgning, skrevet og vedligeholdt i PHP kode. Denne kode vedligeholdes af programmører. Præsentationen er den måde dit indhold præsenteres for slutbrugeren, der er skrevet og vedligeholdes i skabelonfiler. Skabelonerne vedligeholdes af skabelon designere.
I sin mest grundlæggende funktion, ansøgningen koden indsamler indhold, tildeler den til skabelonen motor og viser det. Indholdet kan være noget som overskriften, tagline, forfatter og liget af en avisartikel. Ansøgningen koden har ingen bekymring, hvordan dette indhold vil blive præsenteret i skabelonen. Skabelonen designer har ansvaret for præsentationen. De redigere skabelon filer, tilføjer markup og bringe det til afslutning. Dette involverer typisk ting som HTML-tags, cascading style sheets og andre værktøjer, som skabelonen motor.
Dette paradigme tjener flere formål:
) Designere kan ikke bryde programkode. De kan rode med de skabeloner, alt, hvad de ønsker, men koden forbliver intakt. Koden vil være strammere, mere sikker og nemmere at vedligeholde.
) Fejl i skabelonerne er begrænset til de Smartys fejlhåndtering rutiner, hvilket gør dem så enkelt og intuitivt som muligt for designeren.
) Med præsentation på sit eget lag, kan designere ændre eller helt redesign det fra bunden, alle uden indgriben fra programmøren.
) Programmører er ikke rode med skabeloner. De kan gå om at opretholde ansøgningen kode, ændrer den måde, indholdet er erhvervet, gøre nye forretningsregler mv uden at forstyrre præsentationen lag.
) Skabeloner er en tæt repræsentation af hvad det endelige resultat vil være, hvilket er en intuitiv tilgang. Designere er ligeglad, hvordan indholdet kom til skabelonen. Hvis du har uvedkommende data i skabelonen som en SQL-sætning, dette åbner risiko for at bryde ansøgning kode ved utilsigtet sletning eller ændring af designeren.
) Du er ikke åbne din server til udførelse af vilkårlig PHP-kode. Smarty har mange sikkerhedsfunktioner indbygget, så designere vil ikke bryde sikkerhed, uanset om tilsigtet eller utilsigtet. De kan kun gøre, hvad de er begrænset til i skabelonerne.
Selvom programkode er adskilt fra præsentationen, betyder det ikke nødvendigvis, at logikken er adskilt. Ansøgningen koden har tydeligvis logik, men skabeloner kan have logik baseret på den betingelse, at det kun er til præsentation. For eksempel, hvis designeren ønsker at skifte tabelrække farver eller store bogstaver nogle tildelt indhold, kan de. Dette er præsentation logik, noget programmøren bør ikke være bekymret med. Hvor tit har du haft nogle præsentationen vises i en enkelt kolonne, og så ønskede det i to eller tre kolonner, så ansøgningen koden skal justeres for at imødekomme dette? En bedre fremgangsmåde er at tildele indholdet i et enkelt array, og lad skabelonen håndtere præsentationen. Dette vil forenkle din ansøgning og holde dine skabeloner fleksibel. Smarty leverer værktøjer til at håndtere denne type situation.
Dette betyder ikke, at Smarty forhindrer dig i at sætte ansøgning logik i skabelonen, er du nødt til at have lidt af selvdisciplin. Her er et eksempel på at integrere forretningslogik i skabelonen (det er rigtigt, undgå at gøre dette, hvis det overhovedet er muligt):
{If $ smarty.session.user og ($ user_type eq "editor" eller $ user_type eq "admin")}
rediger
{/ If}
De logiske kontrollerer, om brugeren er logget ind, og de er enten en redaktør eller administrator, så de får lov til at redigere denne så afkrydsningsfeltet redigering dukker op. Det er logik, der hører til i ansøgningen kode. Skabelonen er ligeglad hvad legitimationsoplysninger denne bruger har, det bare brug for at vide, om redigeringsfeltet vises eller ej! Så lad os se på et mere passende fremgangsmåde:
{If $ edit_flag}
rediger
{/ If}
Det er op til ansøgningen programmør at tildele $ edit_flag, en enkel og nem at forstå variabel i skabelonen. Denne måde skabelonen ikke længere afhængige af din underliggende datastruktur. Hvis formatet af sessionen datastruktur nogensinde ændrer sig, skal justeres i skabelonen ingenting.
Nu skal vi se på et par ting, du kan gøre med Smarty. En ting det kan gøre er brugerdefinerede funktioner. Disse er tags i skabelonen, der udfører en bestemt opgave. Eksempel:
{Html_image file = "masthead.gif"}
Her har vi en funktion kaldet "html_image". Denne funktion tager billedet givet i "fil" attribut, og gør alt arbejdet er nødvendigt for at komme op med følgende HTML-kode:
Billedet funktion gjorde opgave for at finde ud af højden og bredden og leverer standard grænsen flag. Selvfølgelig kunne man bare bruge den statiske HTML-tag i skabelonen i stedet, men dette viser, hvordan en brugerdefineret funktion kan anvendes til at forenkle en meget almindelig opgave. Designeren kan fokusere på design og mindre på de tekniske ting. Desuden, hvis designeren beslutter at falde i en anden størrelse mastetop billede, skabelonen ikke behøver justering.
html_image er en funktion, der kommer med Smarty. Du kan også lave dine egne brugerdefinerede funktioner. Her er et andet eksempel på, hvad man kunne se ud:
{Html_link type = "artikel" id = "abc123" text = "Fire tager ud Hotel"}
Dette er ved hjælp af en brugerdefineret funktion kaldet "html_link". Det kommer op med følgende HTML-kode:
Fire tager ud Hotel
Hvad betyder dette udrette? For én, er designeren ikke behøver at være bekymret med formatet af en webadresse til en artikel. Med hårdt kodet URL'er, hvad der sker, hvis det en dag programmøren beslutter at rydde tingene op, og ændrer URL-syntaks fra /display_article.php?id=abc123 til / KUNST / abc123? Vi ville have til at redigere hver skabelon med en artikel URL. Dette er blot endnu et eksempel på, hvordan en skabelon funktion kan gøre skabeloner nemmere at vedligeholde.
Nu til en smule på programmører og skabeloner. Tidligere blev det nævnt, at programmøren har ingen pleje for hvad skabelonerne gøre med indholdet. På det begrebsmæssige plan dette er sandt, men i den virkelige verden, du ikke kommer til at forvente, at skabelonen designer til at nødt til at konstruere alle skabelonerne ud af den blå luft. Efter alt, forretningslogik gør bestemme, hvad indholdet er tildelt skabelonerne. Så programmøren vil typisk setup skelet skabeloner til designeren til at starte med. Dette indeholder som regel de rå elementer som indhold variabler og afsnit loops, og måske et par enkle markup tags, så de ikke begynder med indholdet i et stort rod. Her er et eksempel på et skelet skabelon, sløjfer gennem en liste over artikler og viser dem i en tabel:
| {$ artiklen [kunst] .headline} | {$ artiklen [kunst] .date} | {$ artiklen [kunst] .author} |
Udgangen kan se noget som dette:
| Hvordan Vesten blev vundet | Dec 2, 1999 | John Wayne | |||
| Team taber, Coach afsluttes | Feb 2, 2002 | John Smith | |||
| Gourmet Cooking | Jan 23, 1954 | Betty Crocker |
Nu til nogle almindelige spørgsmål:
Hvorfor bruge skabeloner på alle? Hvad er så hård at skrive I stedet for {$ title}?
At gøre tingene lettere at læse var ikke et design mål, men mere af en bivirkning. Ved hjælp af skabeloner har store fordele, hvoraf mange er blevet forklaret ovenfor. Da vi er i en skabelon miljø anyways, {$ title} er mindre uvedkommende end
Skabelon tager tid at analysere, hvilket gør applikationer meget langsommere.
Det kan være rigtigt i nogle tilfælde, men med Smarty det ikke langsommere end udførelse af en PHP script. På den første henrettelse af en skabelon, Smarty konverterer skabelon filer til PHP-scripts (kaldet skabelon kompilering.) Derefter PHP script netop inkluderet. Par dette med en PHP accelerator, og du virkelig har en hurtig templating miljø med minimal overhead.
Smarty er for kompliceret, hvordan kan det være, at hurtigt?
Smarty kerne er temmelig magert overvejer, hvad det er i stand til. De fleste af dens funktionalitet ligger i plugins. Dette plugin arkitektur er designet således, at kun de nødvendige plugins er indlæst på efterspørgslen. Med denne ramme vil tilføje endda hundredvis af nye plugins ikke påvirke ydeevnen. Dette gør Smarty hurtig, skalerbar og fleksibel.
Smarty har også caching funktioner, som dynamisk kan genopfriske og holde dele af siden uncached på din smag. Caching gemmer output de indsamlede skabeloner, sparer behovet for at udføre dem på hver påkaldelse.
Al denne snak om acceleratorer, hvordan Smarty køre uden en?
Faktisk er det kører ganske godt uden en. Smarty kræver ikke en accelerator, men skabelonen filer selv vil benytte sig af en, noget, der er unikt for Smarty (AFAIK). Hvis du ikke har en accelerator, skabelon udførelse er ikke så hurtig, men ikke langsom på nogen måde, da de ikke er parset! Du også bevarer alle de andre fordele og funktioner i Smarty. Også, da acceleratorer er frit tilgængelige der ikke er virkelig en undskyldning for at ikke skal bruge en. De vil hjælpe ydeevne med alle PHP apps, bruger Smarty eller ej.
Hvordan kan det være lettere at vedligeholde?
Nogle ting kan ikke forklares, men kun opleves. Fordelen ved adskillelse af ansøgningen logik fra præsentationen kan ikke understreges nok. Smarty har også nogle nice fejlhåndtering funktioner og en indbygget debugging konsol, så du kan se skabelonen hierarkiet og tildelte variabler på et øjeblik. Tilføjelse brugerdefinerede funktioner til Smarty er så let som at droppe dem i plugin mappen og nævne dem i skabelonen.
Den skabelon tags er ikke XML baseret, Min redaktør kan ikke lide det.
De {} afgrænsere er blot en standard, de er nemme at få øje på blandt HTML-tags. Hvis du ikke kan lide dem, ændre dine afgrænsere til eller måske noget mere XMLish ligesom Der er også masser af brugernes bidrag til Dreamweaver og lignende, give dem et kig i contribs området.
Det er Smarty i en nøddeskal, forhåbentlig kan du tilføje den til dit arsenal af værktøjer til web-applikation bygning. For virkelig at lære mere, læse manualen top til bund, slutte sig til de fora og se, hvad folk diskuterer
Funktioner :.
- Caching: Smarty giver finkornet caching funktioner til caching hele eller dele af en afsmeltet webside, eller forlader dele uncached. Programmører kan registrere skabelon fungerer som cacheable eller ikke-mulige at mellemlagre gruppe cachede sider i logiske enheder for lettere administration osv.
- Konfiguration Files: Smarty kan tildele variabler trukket fra konfigurationsfiler. Skabelon designere kan opretholde værdier er fælles for flere skabeloner i ét sted uden indgriben fra programmøren, og config variabler kan nemt deles mellem programmerings- og præsentation dele af programmet.
- Sikkerhed: Skabeloner indeholder ikke PHP kode. Derfor er en skabelon designer ikke udløst med den fulde effekt af PHP, men kun den delmængde af funktionalitet til rådighed for dem fra programmøren (ansøgning kode.)
- Nem at bruge og vedligeholde: Web sidedesignere ikke beskæftiger sig med PHP kode syntaks, men i stedet en let-at-bruge templating syntaks ikke meget anderledes end almindelig HTML. Skabelonerne er en meget tæt gengivelse af det endelige output, dramatisk forkorte design cyklus.
- Variabel Modifiers: Indholdet af tildelte variabler kan nemt justeres ved display-tid med modifikatorer, såsom visning i alle store bogstaver, html-undslap, formatering datoer, beskærer tekstblokke, tilføjer mellemrum mellem tegn, etc. Igen Dette opnås med ingen intervention fra programmøren.
- Skabelon Funktioner: Mange funktioner er tilgængelige for skabelon designer til at håndtere opgaver såsom at generere HTML-kode segmenter (dropdowns, borde, pop-ups, etc.), der viser indhold fra andre skabeloner i-line, looping i arrays af indhold , formatering tekst til e-mail-output, cykling om farver osv.
- Filtre:. Programmøren har fuld kontrol over skabelon output og kompileret indhold skabelon med præ-filtre, post-filtre og output-filtre
- Ressourcer:. Skabeloner kan trækkes fra et vilkårligt antal kilder ved at oprette nye handlere ressource, og derefter bruge dem i skabelonerne
- Plugins: Næsten ethvert aspekt af Smarty styres gennem anvendelse af plugins. De er generelt så nemt som at slippe dem ind i plugin mappen og derefter nævne dem i skabelonen eller bruge dem i ansøgningen kode. Mange bruger-community bidrag er også tilgængelige. (Se plugins sektion af forum og wiki.)
- Add-ons: Mange bruger-community bidrog Tilføjelser er tilgængelige, såsom sideinddeling, Form Validering, rullemenuerne, Calander Dato Plukkere etc. Disse værktøjer hjælper fremskynde udviklingen cyklus, er der ingen grund til at re- opfinde hjulet eller debug kode, der er allerede er stabil og klar til implementering. (Se Tilføjelsesprogrammer sektion af forum og wiki.)
- Debugging:. Smarty leveres med en indbygget debugging konsol, så skabelonen designeren kan se alle de tildelte variabler og programmøren kan undersøge skabelon rendering hastigheder
- Kompilering:. Smarty samler skabeloner i PHP-kode bag scenen, fjerne run-time parsing skabeloner
- Ydelse: Smarty udfører særdeles godt, på trods af sin enorme feature sæt. De fleste af Smarty evner ligge i plugins, der er indlæst on-demand. Smarty kommer med talrige præsentationsværktøjer, minimere din ansøgning kode og resulterer i hurtigere, mindre fejlbehæftet applikationsudvikling / implementering. Smarty skabeloner bliver kompileret til PHP-filer internt (en gang), hvilket eliminerer dyre skabelon fil scanninger og udnytte hastigheden af PHP op-kode acceleratorer.
Hvad er nyt i denne udgivelse:
- tilbage super globale ændringer adgang, og i stedet stole på USE_SUPER_GLOBALS for sikkerhed
Hvad er nyt i version 2.6.23:
- bånd backticks fra {matematiske} ligninger (mohrt)
- kast fejl, når skabelonen findes, men ikke læses (mohrt)
Hvad er nyt i version 2.6.22:
- Denne version løser et problem, med Smarty 2.6 .21 frigivelse og en PCRE motor fejl i PHP 5.2. Metode kæde er blevet fjernet for at undgå fejlen. Metode kæde vises igen i Smarty 3.
Kommentarer ikke fundet