Blog | Artikler | Projekter | CV

Denne artikel omhandler det overordnede design af Patch CMS, herefter refereret til som Patch. Patch er det system, der driver denne side. Patch er kodet i PHP og benytter teknologier som SQL, XHTML, CSS og XSLT. Hvordan de forskellige teknologier hænger sammen med Patch, kommer jeg ind på løbende.

Overordnet opbygning af Patch CMS med MVC

Patch er opbygget over MVC designmønsteret.

Hvad er MVC

MVC (Model View Control) er et designmønster, der ofte bruges til at opbygge GUI programmer. Det benyttes også i nogle tilfælde til webapplikationer som her. Da webapplikationer virker på en fundamental anderledes måde end et GUI program, betyder det, at der er enkelte ændringer.

Et kort eksempel på et MCV design

Vi har en model, som er vores temperatur. Den kan vi så vise i forskellige views, her grader Celsius og Fahrenheit, man kunne også tilføje Kelvin. Hvis der på et tidspunkt kommer en ny skala, kan vi implementere et nyt view i stedet for at skrive hele systemet om. Controldelen er den del, der sørger for, at temperaturen er opdateret, dvs. man kan have en person eller et elektronisk termometer til at aflæse temperaturen og indlæse den i vores control, der så opdaterer de forskellige views. For mere information om MCV se Google

MVC i Patch

I Path genererer modellen XML over det data, vi har i systemet. Her modsvarer vores XML temperaturen i det forrige eksempel. Vores view overtager nu og laver dette XML om til noget, der kan vises i en browser. Det smarte i systemet er, at vi kan have mange forskellige views, der er optimeret til forskellige ting. Et view til ældre browsere, der ikke understøtter det nyeste XHTML og CSS, et view til nyere browsere, der gør og et utal af forskellige andre views, fx RSS feeds, XUL, pdf osv.

Model og Control i Patch

I en webapplikation er det ikke nødvendigt for control at opdatere de forskellige views. Dette bunder i, at hele systemet oprettes, hver gang der bliver forespurgt en side, så views har altid den nyeste information fra systemet, og den information kan ikke ændres, uden at der bliver forespurgt en ny side. Model/Control delen i Patch består af elementerne i figuren:

Denne figur kræver nok lidt forklaring. I midten har vi Core, som binder alle undersystemerne sammen, Database, Log, Session og Plugin. Som tidligere sagt outputter vores model XML. Pluginundersystemet har ansvaret for at samle XML fra de forskellige plugins (med sort i figuren). Når alle plugins har afleveret deres XML, sender Pluginundersystemet det generede XML videre til vores View, mere om det senere. Alle plugins har mulighed for at kommunikere med undersystemerne direkte, dvs. de kan hente fra databasen, logge og hente sessionsoplysninger. Eksemplet kan være en nyhedsplugin, der vil hente alle nyhedernes data fra databasen. Pluginet kan også logge, hvis der ikke er nogle nyheder, eller noget går galt. Den skal også kunne tilgå sessionssystemet for at finde ud af, om der er en bruger logget ind. I MCV regi vil alle undersystemerne være en del af model, og de forskellige plugins vil have både model og control. Undersystemerne modtager ikke noget input fra brugeren direkte og behøver derfor ikke at have nogen controldel. For at tage et eksempel med plugins. En nyhedsplugin har en modeldel, der sørger for, at der bliver genereret XML over dens data, og en controldel, der gør det muligt for en bruger at ændre i nyhederne.

Undersystemer

Fordelen ved undersystemerne er, at de lægger et vist niveau af abstraktion ind i systemet.

Database:

Patch benytter MySQL som database backend, men fordi interfacet til databasen er et undersystem, kan man uden problemer skifte til en anden backend, som fx PostgreSQL eller Oracle. Hvis man har rigtigt mange besøgende på ens side, er det også muligt at få undersystemet til at bruge master/slave princippet med databaser, hvor ændringer skrives til master, og data trækkes ud fra flere forskellige slavedatabaser for at fordele presset på serverne. Alt sammen helt gennemsigtigt for plugins, der bruger systemet.

Log:

Når man har så stort et system, kan det være omfattende at spore, hvor der er noget, der er gået galt. Derfor bør man have et system, der kan logge fejl i systemet. Når der sker en kritisk fejl, kan systemet i stedet for at gå ned og vise brugeren en uforståelig fejlmeddelelse genere en fejlside og give web-masteren besked om problemet. Ved mindre kritiske fejl er det også en god ide at kunne slå systemet i debug mode, så den logger alt, hvad der sker, så det er muligt at se, hvor det går galt. Logsystemet bliver derfor brugt af både plugins og de andre undersystemer.

Session:

Er ansvarlig for at opretholde en session med brugeren. Plugins kan så, hvis de ønsker det, gemme sessionsorienteret data og få det frem igen ved næste sideforespørgsel. Et eksempel er brugersystemet, der opretter en bruger objekt med information om brugerens rettigheder. Sessionsdata er delte, så andre plugins også kan tilgå data, dette betyder, at nyhedspluginen fra før ikke behøver at have sit eget brugersystem, men kan bruge det system, som brugersystem pluginen allerede har oprettet. [b]Plugin:[/b] Dette undersystem har ansvaret for, at de forskellige plugins bliver initialiseret, kørt og lukket ned. En plugin har mulighed for at dele objekter via sessionssystemet, når de bliver initialiseret. Når objektet er delt, har andre plugins inklusiv den selv mulighed for at benytte dette objekt, når pluginen bliver kørt. Når en plugin har kørt, samler pluginsystemet det XML, der er blevet genereret. Efter alle plugins er kørt, bliver alt XML samlet og videregivet til vores View gennem Core.

Plugins

Som man nok kan gætte fra beskrivelsen af de forskellige undersystemer, kan Patch ikke rigtig noget uden plugins. Dette giver et utroligt niveau af fleksibilitet i og med, at vi kan skrotte alle plugins og lave et helt andet system samtidig med, at vi beholder den stærke backend. Plugins står derfor for alt i Patch. Af funktioner i plugins kan nævnes, banner skifter, billede galleri, tagwall, bbl tekst parser, brugersystem og mange andre.

View i Patch

Når alle plugins har kørt, og alt XML er genereret, skal vores view lave noget, som brugeren kan se, dette "noget" er så XHTML/CSS. Måden, det bliver genereret på, er ved hjælp af en XSLT fil. XSLT er beregnet til at lave XML om til en anden form for XML, i dette tilfælde XHTML. De fleste XSLT systemer kan dog indstilles til at generere HTML 4.1 i stedet for. I stedet for XSLT kan man benytte XSL, der kan generere næsten hvad som helst, bl.a. billeder eller pdf data. Så repræsentationen af data er fuldstændigt uafhængigt af selve kernen i systemet.

Konklusion

Patch kan tilpasses mange forskellige scenarioer, og viewdelen er meget rettet imod browser-understøttelse af fremtidige teknologier. Pluginunderstøttelsen gør, at man kan benytte Patch som et framework til næsten alle typer af webapplikationer. På et tidspunkt bliver XSLT transformation på klientsiden sandsynligvis mere stabilt, end det er nu. Når det sker, kan man flytte XSLT transformationen til klienten og derved spare en del server-ressourcer. Man har også mulighed for at bruge CSS til at præsentere ens XML med, så man helt kan undgå XSLT og derved spare en del båndbrede. Men både CSS og XSLT metoderne har indtil videre samme problemer. De er ikke understøttet i andet end de nyeste browsere, og understøttelsen er ikke helt ens.

Frederik Sørensen 15/01-2005