[PHP] Opzet flexibel templatesysteem

[Verwijderd]

Hallo allemaal,

Zoals velen van jullie heb ook ik een eigen CMS geschreven. Momenteel ben ik bezig om mijn CMS te vernieuwen omdat ik de huidige ondersteuning voor uitbreiding van modulen, opties, instellingen en verschillende websites niet flexibel genoeg vind. Daarnaast wil ik naar een CMS toe wat gebruik maakt van AJAX door de jQuery library op verschillende punten te implementeren.

Een van de onderdelen welke ik goed wil aanpakken is het eenvoudig beheren van de website. In mijn huidige en vorige versies is de klant gebonden aan het ontwerp wat ik geleverd heb. Ik wil nu een templatesysteem gaan maken waarmee de klant eenvoudig middels drag and drop zijn pagina kan invullen. Omdat dit de eerste keer is dat ik zo'n dergelijke oplossing maak ben ik benieuwd naar jullie mening.

Ik zie voor me dat ik twee soorten templates in mijn systeem onderbreng; een website-template en een content-template. De website-templates gaan over de volledige weergave van de website waarin onder andere het menu, 'widgets' en de footer worden geplaatst (middels d&d). De content-templates zijn bedoeld voor de wijze waarop de klant de informatie wil weergeven, 1 kolom, 2 kolommen, 2 kollomen boven 1 brede eronder etc.

Het lijkt me dat er een soort structuur komt als volgt:

TEMPLATE_WEBSITE
id, int, PK,
title, varvchar(20),
sourceCode, text

TEMPLATE_WEBSITE_REGION
id, int, PK
fk_template_website, int, FK
regionId int

TEMPLATE_CONTENT
id, int, PK
fk_template_website
fk_page, int, FK

TEMPLATE_WIDGET
id, int, PK
fk_page, int, FK
fk_template_website_region, int, FK
sourceCode, text

Het TemplateWebsite object zal een verzameling van TemplateWidgets krijgen welke op dan op de betreffende template getoond zullen worden. Widgets kunnen dingen zijn als een aanbieding uit de webwinkel, aanmelden nieuwsbrief, laatste 3 nieuwsitems, etc..

Ik ben benieuwd wat jullie van deze opzet vinden, of jullie tips hebben of het volledig anders zouden aanpakken. Het gaat me er in dit topic niet om dat er oplossingen als Smarty zijn, of dat het schrijven van een eigen templatesysteem overbodig is. Daarover wordt al genoeg gediscussieerd

Groet,
Ben Fransen

[RobIII]

Verwijderd schreef op vrijdag 18 september 2009 @ 19:21:
Zoals velen van jullie heb ook ik een eigen CMS geschreven.

Dit is je eerste post op GoT? Hoe zouden velen van ons dat moeten weten?

OnTracK schreef op vrijdag 18 september 2009 @ 19:38:
Psst. hij zegt niet "zoals velen van jullie weten", maar "zoals velen van jullie (hebben gedaan)"

Goeiemorgen

Verwijderd schreef op vrijdag 18 september 2009 @ 19:21:
Ik ben benieuwd wat jullie van deze opzet vinden, of jullie tips hebben of het volledig anders zouden aanpakken.

Ik zou, persoonlijk, geen code in de DB stoppen maar daar kun je lang en breed over lullen; of je het nou op je FileSystem parkeert of in een DB mikkert... het moet toch ergens opgeslagen worden. Alleen het uitvoeren van de code is lastiger als het uit je DB komt. Verder zie ik weinig bijzonders en vraag ik me af waar je nou precies naar op zoek bent. Het ene systeem is het andere niet en zonder verdere kennis lijkt me dat we weinig zinnigs kunnen zeggen hierover.

[ Voor 23% gewijzigd door RobIII op 18-09-2009 19:43 ]

[OnTracK]

RobIII schreef op vrijdag 18 september 2009 @ 19:35:
[...]

Dit is je eerste post op GoT? Hoe zouden velen van ons dat moeten weten?

Psst. hij zegt niet "zoals velen van jullie weten", maar "zoals velen van jullie (hebben gedaan)"

[Verwijderd]

Dat was inderdaad mn eerste post. Ik denk dat je hem verkeerd gelezen hebt, want ik ging er van uit dat er hier veel mensen zijn die ook een CMS of dergelijk iets geschreven hebben. Ik suggereer niet of velen van jullie al weten dat ik een CMS geschreven heb

Anyway, back ontopic. Wat ik feitelijk wil is een mogelijkheid op per pagina aan te geven welke layout gebruikt moet worden en welke contentlayout gebruikt moet worden. Een globale layout heeft regions waar widgets/contentlayouts op geplaatst kunnen worden.

Wat ik probeer te bereiken is een eenvoudige wijze waarop mijn klant zijn website en weergave daarvan kan beheren.

[Gomez12]

Tja, het kan zo... maar het kan ook anders...

Het is veelal meer een kwestie van smaak etc. Omdat het uiteindelijk toch veelal lood om oud ijzer wordt.

Ik neem aan dat je die code uit de DB haalt en dan op het FS cached waardoor je qua code-ophalen geen dbase calls meer nodig hebt en het verschil tussen in DB opslaan en op FS cachen vs enkel op FS opslaan zo goed als nihil wordt.

Dbase heeft als voordeel dat er over het algemeen betere custom versioning etc in te bouwen is / makkelijker te distribueren / beheren.
FS heeft als voordeel dat het met meer tools te benaderen is.

Bij het maken van een template pak ik liever mijn favo-editor en verander ik iets rechtstreeks op de test-ftp, elke kleine verandering even op ctrl-s drukken en ik kan het uitproberen. Bij db ben ik of gebonden aan een door jou gemaakte editor ( evenaart nooit mijn favo-editor ) of ik moet ctrl-a / ctrl-c / ctrl-v / opslaan drukken voor ik het kan uittesten.

[Grijze Vos]

In de database opslaan met als groot risico dat mocht ern een injectie aanval of iets dergelijks mogelijk zijn dat er dan willekeurig executeerbare code door de webserver wordt uitgevoerd is een veel te groot risico. Dat risico moet je niet willen nemen.

[Verwijderd]

@Gomez: Cachen is idd de bedoeling. Over het punt van beheer van templates heb je gelijk, hoewel dit eigenlijk alleen voor mijzelf opgaat. De klant kiest uiteindelijk uit de door mij opgeleverde, werkende templates.

@Grijze Vos: dat risico hou je altijd, is het niet met een templatesource dan wel met een product wat uit de database wordt opgehaald. SQL injectie ga ik sowieso tegen.

[Duroth]

Wellicht de code van Smarty eens induiken? Hoewel ik zelf niet weg ben van dat soort templatesystemen (HTML inkloppen kan ik zelf wel, de designers waar wij 'gebruik' van maken gaan niet verder dan een photoshop bestandje), heeft Smarty het een en ander toch goed bekeken. Ook zijn de tags die je in je code plaatst, vrij makkelijk aan te passen middels een zelfgeschreven drag n' drop editor. Wellicht een nieuwe addon voor je favo WYSIWYG editor (tinyMCE, SPAW, etc) schrijven die dit mogelijk maakt.

Deze tags kan je vervolgens gewoon replacen. Smarty vervangt ze door de juiste PHP-equivalent, en schrijft het complete bestand, inclusief PHP, vervolgens naar een cache folder. Tenslotte zijn replaces (zeker regexp functies) niet overweldigend snel, die wil je dus niet al te vaak uitvoeren.

Daarom ook zou ik toch voor een file oplossing gaan, dit is uiteindelijk waarschijnlijk makkelijker, maar zeker sneller in het gebruik, dan alle templates in een database kegelen.

Daarnaast zal je iets van een CSS-editor moeten bouwen willen je klanten ook de kleuren, positionering, lettergrootte, etc aanpassen.

Tenzij je opdrachtgever zelf webdesigner is, of intern wat mensen rond heeft lopen, zal hun website al snel gereduceerd zijn tot een redelijk onoverzichtelijke constructie. De vraag die je jezelf dan ook moet stellen, is hoeveel vrijheid jij je klanten wilt geven. Als ze echt alles aan hun ontwerp willen veranderen, stop de template files dan in een aparte map, en geef ze een FTP-account waarop alleen die map vrij toegankelijk is ;-)

Edit: Als het de bedoeling is dat klanten enkel een vooraf gemaakte template uit kunnen kiezen, kan je deze altijd in een templates/ map knallen, en dan de directory uit laten lezen en van elke map een optie maken in het keuzescherm. Op die manier zou je een makkelijke bestandsstructuur houden waar je zonder enige moeite (en ook zonder database) nieuwe templates aan toe kunt voegen. Het enige dat dan nog wel in een database moet, is de naam van de template die de klant gekozen heeft.
Voor deze templates heb je dan niet eens een CMS nodig, behalve dan wellicht een WYSIWYG editor op de plek waar je klanten hun content aan kunnen passen. Een beetje een Cushy idee dus.

[ Voor 18% gewijzigd door Duroth op 18-09-2009 21:40 ]

[Gomez12]

Grijze Vos schreef op vrijdag 18 september 2009 @ 19:57:
In de database opslaan met als groot risico dat mocht ern een injectie aanval of iets dergelijks mogelijk zijn dat er dan willekeurig executeerbare code door de webserver wordt uitgevoerd is een veel te groot risico. Dat risico moet je niet willen nemen.

Mits goed opgezet is het risico imho niet groter dan dat iemand per ftp inbreekt of je ergens op je site een bestand op schijf wegschrijft.

Je source code dbase / tabel kun je simpelweg compleet read-only instellen voor de web-user, zelfs mysql ondersteunt dit.
Zolang je code read-only voor je web-user staat heb je enkel een risico dat iemand je mysqluser dbase zou kunnen uitlezen en daaruit een login/wachtwoord kan destilleren, maar dat risico is imho net zo groot als dat iemand toegang krijgt tot /etc/passwd

Je hebt enkel een mogelijk beveiligingsprobleem als je de user-identificatie ( op dit vlak ) enkel via eigen scripts laat lopen ( iedereen is web-user voor mysql ). Definieer meerdere gebruikers / rollen / rechten in mysql waarbij de webuser niet bij de code table kan en het risico is niet groter dan een willekeurige andere manier ( of er moet opeens een gigantisch lek in mysql gevonden worden )

Verwijderd schreef op vrijdag 18 september 2009 @ 20:07:
@Gomez: Cachen is idd de bedoeling. Over het punt van beheer van templates heb je gelijk, hoewel dit eigenlijk alleen voor mijzelf opgaat. De klant kiest uiteindelijk uit de door mij opgeleverde, werkende templates.

Als je gaat cachen is mijn persoonlijke voorkeur gewoon op FS opslaan en als je het in een db wilt hebben staan dan gewoon naar een db synchroniseren.

DB->FS cache leidt altijd tot minimaal 1 extra call om te zien of de cache nog vers is, bij een wat gecompliceerdere site leidt dit al snel tot meerdere extra calls ( in het geval van includes ) of tot ingewikkelder query's om de code op te halen ( in het geval dat je geen includes in je code wilt en deze via query's afhandelt )
Bij een kleine site maakt dit niet zoveel uit, maar bij 10.000 pageviews / 5.000 ajax-calls kan een klein performance verlies ( die ene extra call ) toch best zwaar gaan tellen.

Sowieso moet je al snel nadenken over een niet regulier caching schema voor je gehele website.
Zware sql-query's cachen wordt al ingewikkelder omdat je toch nog steeds een mysql-aanroep moet doen voor je code ( ik neem aan dat die niet 1 dag blind cached zonder dbase tussenkomst, omdat je dan niet tussentijds fixes kan uitbrengen zonder eerst de cache op FS te verwijderen, als je toch iets op FS moet doen ... ), dan kan je net zo goed het totaal ( code + sql-result ) cachen ipv losse cache voor code en losse cache voor sql-cache.
En als je zover bent, dan kan je net zogoed je cache gelijk wegschrijven als .html en serveren als static files en enkel je cache invalideren als je iets toevoegt / verandert.
1 .htaccess rule die ervoor zorgt dat een 404 error doorverwezen wordt naar een script wat de .html aanmaakt en dan een 301-header daarnaartoe doorstuurt.

En je hebt een statische site gecreerd die toch dynamisch gevoed wordt en die enkel veel I/O acties genereert.

Hoever wil je hiermee doorgaan?
Elke code-pagina opbouwen kost naast het reguliere apache->php verkeer ook altijd een mysql-call...

[mithras]

Ik zou überhaupt niet je gehele widgets in je database plempen. Je hebt een aantal widgets en een aantal container templates. Slechts de mapping plaats je in de database.

Die templates zijn je standaard templates voor een, twee, drie kolommen etc. Die laat je vervolgens registreren (bijv. via een configuratie bestand, het uitlezen van bestanden in een map, etc).
De widgets zijn bijv. een stukje tekst, een agenda overzicht, etc. Deze widgets zijn net als de template containers gewoon te registreren van tevoren. Jij zegt: deze en deze widgets zijn er beschikbaar.

De klant krijgt vervolgens een mechanisme waarin je kan zeggen: ik maak een pagina MyCustomPage aan. Deze maakt gebruik van de container TwoColumns. Deze TwoColumns kent twee content keys: left en right (welke dus de linker kolom vs rechter kolom vullen). In de left content key zitten achtereenvolgens de widgets Text, AgendaOverview, Text en in right zit BlogOverview, Text.

Je slaat uiteindelijk alleen de mapping op welke widgets op welke key zitten van een bepaalde template. Dan hoef je nooit de code in de database op te slaan (imho toch wel een zeer belangrijk punt). Je kan ook de widgets nog parameters meegeven. Zo kan je de widget Text een TextId meegeven. Dit id komt dan weer overeen met een entry in je database voor een stukje tekst, wat uiteraard de gebruiker zelf kan vullen.

[ Voor 8% gewijzigd door mithras op 18-09-2009 22:27 ]

[Verwijderd]

@Duroth: Dat is een goede tip Ik heb Cushy net even bekeken maar dat is niet helemaal vergelijkbaar met de situatie die ik voor ogen heb. Hetgeen Gomez beschrijft komt vrijwel volledig overeen met wat ik wil.

@Gomez, daar heb je inderdaad gelijk in. Het gaat sowieso om volledig door mij opgestelde en geuploadde templates. De klant kan zelf geen templates wijzigen, op verzoek kunnen er uiteraard altijd extra templates worden ontwikkeld etc. Dus ik zie er vanaf om de templates als TEXT veld op te slaan in een database maar gewoon als phtml-files weg te schrijven in een mappenstructuur waarin global templates en content templates mappen aanwezig zijn.

Iedereen super bedankt voor de uitgebreide reacties! Als er nog meer tips, do's of vooral don't's zijn dan hoor ik het graag!

P.s. CushyCMS zag er wel lekker flexibel uit maar lijkt me handiger als blog- of minisite beheertool:)

Edit; toen ik deze reply aan het typen was had Mitrhas al gereageerd:

Bedankt voor je bijdrage! Zeker goede punten waarin nog eens helder de structuur wordt beschreven. Na vele ERD diagrammetjes geschetst te hebben heb ik nu een redelijk duidelijk beeld van hoe de structuur gaat worden.

Het enige nadeel is eigenlijk dat het PageObject het diepst genest zit in deze constructie, dus je moet min of meer recursief uitlezen om bij de template te komen. Of zie ik dit verkeerd?

[ Voor 21% gewijzigd door Verwijderd op 18-09-2009 22:57 ]

[Gomez12]

mithras schreef op vrijdag 18 september 2009 @ 22:24:
Ik zou überhaupt niet je gehele widgets in je database plempen. Je hebt een aantal widgets en een aantal container templates. Slechts de mapping plaats je in de database.

Waarom niet? Mits je de juiste caching gebruikt is er toch geen verschil?

Een blinde caching van een jaar ( dus zonder checks naar de dbase of de code nog vers is ) levert 99,99999% dezelfde performance op zolang de cache bestaat. Je hebt enkel nog 1 extra FS-check of je bestandje bestaat, desnoods kan je dit laten afhandelen door apache door een 404 error een nieuwe cache aan te laten maken. Dan heb je 100% dezelfde performance.

Je slaat uiteindelijk alleen de mapping op welke widgets op welke key zitten van een bepaalde template.

Of je nou om te achterhalen welke widgets er zijn een dbase call doet of om te achterhalen of je gecachete code ( inclusief ingebakken widgets ) nog vers is, er moet toch 1 dbase call plaatsvinden.
Waarschijnlijk is je 2e query moeilijker ( vanwege de ingebakken widgets ) maar theoretisch valt dit ook weer in je dbase op te vangen door je code-tabel via triggers te laten vullen.

Zolang je maar goed cached is er enkel een verschil in beheer, en als je al een uitermate goed dbase beheer systeem hebt, waarom dan niet...
Enkel als je geen uitermate goed dbase beheer systeem hebt, dan denk ik dat het makkelijker is om een FS systeem op te bouwen, puur vanwege alle caching uitzonderingen / bewerk uitzonderingen etc waar je anders tegenaan gaat lopen en wat bij FS vanaf scratch simpeler te regelen is ( er is meer tooling voor )

Het enige wat je bij het afwijken van de standaard in gedachten moet houden is dat de standaard om een reden de standaard is geworden, dit is veelal niet puur toeval oid geweest.
Veel standaard tooling zal je al moeten hebben of moeten schrijven als je wilt afwijken van de standaard ( en dit kan veel en veel meer zijn dan je denkt , een gebruiker die met Frontpage wil werken ( aargh ) zal wel overweg kunnen met FS-opslag ( via ftp ) maar niet met DB-opslag ( zonder een scheduler die de bestandjes periodiek oppakt of zelfs een custom ftp-server die opslaat in DB schrijven ))

Imho is een van de grootste pitfalls bij code in DB dat je gebruikers/jezelf alle standaard tools zo ongeveer ontzegd. Maar als jij / je gebruikers hiermee kunnen leven zie ik er weinig op tegen ( en zijn er zelfs enkele voordelen )

[Gomez12]

Verwijderd schreef op vrijdag 18 september 2009 @ 22:51:
@Gomez, daar heb je inderdaad gelijk in. Het gaat sowieso om volledig door mij opgestelde en geuploadde templates. De klant kan zelf geen templates wijzigen, op verzoek kunnen er uiteraard altijd extra templates worden ontwikkeld etc. Dus ik zie er vanaf om de templates als TEXT veld op te slaan in een database maar gewoon als phtml-files weg te schrijven in een mappenstructuur waarin global templates en content templates mappen aanwezig zijn.

Als je voor templates al gaat afwijken dan zou ik me erg gaan afvragen of je de code nog wel in de dbase wilt hebben.

Blijkbaar heb je niet zo 1-2-3 de tooling om de templates makkelijk te beheren, waarom denk je dan wel de tooling te hebben om de code te beheren?

Een andere mogelijkheid is namelijk om gewoon een vaste mappenstructuur te gebruiken, hieroverheen caching te leggen ( dus ipv db-call doe je nu een fs-call ) waarbij de web-user enkel naar de gecachede bestanden zit te kijken.
SVN / CVS gebruiken voor versioning op je vaste mappenstructuur, 1 script wat je files verspreidt en gaan met die banaan.

Dan heb je volgens mij alle voordelen van een standaard dbase afgedekt, maar nog steeds alle voordelen van standaard tooling.

[Verwijderd]

Hoe bedoel je dat ik afwijk van templates? En wat bedoel je precies met tooling? Notepad++, ZendStudio e.d.?

Maar uiteindelijk hou je nog steeds een dbcall om de page-data met gerelateerde objecten (meta, author, (related), (reactions) etc) op te halen. Die zet je dan toch in je FS template en een bezoeker kijkt dan naar de cache.

Is het dan trouwens verstandig om per uniek IP-adres een nieuwe cache te genereren en de huidige te overschrijven zodat meerdere bezoekers elkaar 'voorzien' van de meest nieuwe versie van de content? Of gaat dan het cachingprincipe niet echt meer op?

[mithras]

Gomez12 schreef op vrijdag 18 september 2009 @ 22:52:
[...]

Waarom niet? Mits je de juiste caching gebruikt is er toch geen verschil?

Een blinde caching van een jaar ( dus zonder checks naar de dbase of de code nog vers is ) levert 99,99999% dezelfde performance op zolang de cache bestaat. Je hebt enkel nog 1 extra FS-check of je bestandje bestaat, desnoods kan je dit laten afhandelen door apache door een 404 error een nieuwe cache aan te laten maken. Dan heb je 100% dezelfde performance.

Jawel: flexibiliteit

Ik zie een widget als een dynamisch onderdeel. Leuk dat je text kan opslaan, dat kan inderdaad met jouw methode ook. Maar wat als je agenda's, blogs, eigenlijk alles in je widget structuur wil vangen. Ik neem aan dat als je aan een dergelijk template systeem gaat, je ook alles daarin wil vangen. Slechts een selectie van je pagina's onderbrengen in dit template systeem gaat een onhoudbare situatie opleveren.

Als je over caching gaat praten: cache de complete output van de template. Dan ben je meteen klaar en hoef je niets aan widgets te regelen. Daarmee ben je zeer snel bij weinig veranderende pagina's.

[...]

Of je nou om te achterhalen welke widgets er zijn een dbase call doet of om te achterhalen of je gecachete code ( inclusief ingebakken widgets ) nog vers is, er moet toch 1 dbase call plaatsvinden.
Waarschijnlijk is je 2e query moeilijker ( vanwege de ingebakken widgets ) maar theoretisch valt dit ook weer in je dbase op te vangen door je code-tabel via triggers te laten vullen.

Zolang je maar goed cached is er enkel een verschil in beheer, en als je al een uitermate goed dbase beheer systeem hebt, waarom dan niet...
Enkel als je geen uitermate goed dbase beheer systeem hebt, dan denk ik dat het makkelijker is om een FS systeem op te bouwen, puur vanwege alle caching uitzonderingen / bewerk uitzonderingen etc waar je anders tegenaan gaat lopen en wat bij FS vanaf scratch simpeler te regelen is ( er is meer tooling voor )

Je legt de focus (en daarmee constraint) teveel op de caching. Dat is niet het punt. TS wil een flexibel systeem, niet een systeem waarin je kan cachen. De flexibiliteit is een uitgangspunt, dus dat moet je dan natuurlijk wel doen. Je kan vervolgens in de optimalisatie het idee van caching meenemen. Maar er is meer dan file based cache. Apc en memcache zijn ook caching mechanismen. Er kan veel meer!

Het enige wat je bij het afwijken van de standaard in gedachten moet houden is dat de standaard om een reden de standaard is geworden, dit is veelal niet puur toeval oid geweest.
Veel standaard tooling zal je al moeten hebben of moeten schrijven als je wilt afwijken van de standaard ( en dit kan veel en veel meer zijn dan je denkt , een gebruiker die met Frontpage wil werken ( aargh ) zal wel overweg kunnen met FS-opslag ( via ftp ) maar niet met DB-opslag ( zonder een scheduler die de bestandjes periodiek oppakt of zelfs een custom ftp-server die opslaat in DB schrijven ))

Imho is een van de grootste pitfalls bij code in DB dat je gebruikers/jezelf alle standaard tools zo ongeveer ontzegd. Maar als jij / je gebruikers hiermee kunnen leven zie ik er weinig op tegen ( en zijn er zelfs enkele voordelen )

Hier verlies ik je echt Standaard, Frontpage? Daar heb ik het niet over. Het gaat hier om een principe en een manier waarop je de code structureert. Ik ga, door mijn vele werk in het Zend Framework tegenwoordig, veel uit van MVC principes. Dit systeem valt er prima in te meten, waardoor het (imho) meteen ook zeer goed is te onderhouden en te begrijpen voor anderen.

[Verwijderd]

Koop eerst een goed boek over design patterns. Daarna praten we verder.

[Verwijderd]

Heb wel een pdfje 'liggen' (PHP Architect Guide to PHP Design Patterns 2005). Maar het MVC pattern is bijzonder geschikt voor mijn situatie, eigenlijk vrijwel alle webbased applicaties.

[Gomez12]

mithras schreef op vrijdag 18 september 2009 @ 23:10:
[...]
Jawel: flexibiliteit

Ik zie een widget als een dynamisch onderdeel. Leuk dat je text kan opslaan, dat kan inderdaad met jouw methode ook. Maar wat als je agenda's, blogs, eigenlijk alles in je widget structuur wil vangen. Ik neem aan dat als je aan een dergelijk template systeem gaat, je ook alles daarin wil vangen. Slechts een selectie van je pagina's onderbrengen in dit template systeem gaat een onhoudbare situatie opleveren.

Als je over caching gaat praten: cache de complete output van de template. Dan ben je meteen klaar en hoef je niets aan widgets te regelen. Daarmee ben je zeer snel bij weinig veranderende pagina's.

In caching heb je ook nog wel enkele varianten, maar idd full-page caching is het meest efficient en zoals ik de TS lees gaat het hier niet over een igoogle pagina die continu per user verandert, maar meer over een algemene website met een standaard template waar zo af en toe een nieuw bericht op komt dus is imho full-page caching gewoon haalbaar.

[...]
Je legt de focus (en daarmee constraint) teveel op de caching. Dat is niet het punt. TS wil een flexibel systeem, niet een systeem waarin je kan cachen. De flexibiliteit is een uitgangspunt, dus dat moet je dan natuurlijk wel doen. Je kan vervolgens in de optimalisatie het idee van caching meenemen. Maar er is meer dan file based cache. Apc en memcache zijn ook caching mechanismen. Er kan veel meer!

Tja, zolang php niet vanuit dbase / memory kan runnen ( zonder gare trucs oid ) heb je toch echt een file op je FS nodig. Standaard is deze er.
Wil je code in je db opslaan zal deze toch voor het uitvoeren op disk terecht moeten komen, dit kan je per aanroep doen ( overhead van hier tot tokio ) of je kan het cachen. Afaik haalt een APC / memcache nog steeds niet de limiet weg dat de code op disk moet staan.

De flexibiliteit zie ik ook niet echt vanuit gebruikersoogpunt ( widgets etc ) maar meer vanuit beheersoogpunt ( makkelijk nieuwe code verspreiden over x doelen )
De klant/gebruikersflexibiliteit is wmb al gelimiteerd door enkel je eigen templates aan te leveren zonder aanpassingsmogelijkheden.

[...]
Hier verlies ik je echt Standaard, Frontpage? Daar heb ik het niet over. Het gaat hier om een principe en een manier waarop je de code structureert. Ik ga, door mijn vele werk in het Zend Framework tegenwoordig, veel uit van MVC principes. Dit systeem valt er prima in te meten, waardoor het (imho) meteen ook zeer goed is te onderhouden en te begrijpen voor anderen.

MVC is een totaal ander principe, wat hier niets mee te maken heeft imho. Dit gaat gewoon puur over waar sla je je code op. Op een FS ( standaard ) of in een DB.

Verwijderd schreef op vrijdag 18 september 2009 @ 23:05:
Hoe bedoel je dat ik afwijk van templates?

Je wilt je templates blijkbaar niet meer in je DB opslaan, daarmee wijk je dus af van je 1e opzet met code / templates in DB

En wat bedoel je precies met tooling? Notepad++, ZendStudio e.d.?

In simpele vorm wel, in uitgebreidere vorm omvat dit ook version control systems / 3rd party library's etc.
Een ultraedit ( zend studio ook dacht ik ) heeft gewoon een mogelijkheid om een bestand via ftp op te halen, te bewerken en weer via ftp op te slaan. Met db-opslag verlies je deze mogelijkheid.

3rd party library's zijn wel code, maar heb je niet altijd de bron van, deze vallen dus alweer buiten je db ( of je moet er ook binary bestanden in willen opslaan )

Maar uiteindelijk hou je nog steeds een dbcall om de page-data met gerelateerde objecten (meta, author, (related), (reactions) etc) op te halen. Die zet je dan toch in je FS template en een bezoeker kijkt dan naar de cache.

Ja, maar dan praat je over normale cache ( die voor veel toepassingen al gratis en voor niets in je OS / Dbase zit ingebouwd ).
Code is meestal redelijk statisch en levert met eigengemaakte code-caching ( vanuit een db bijv ) enkel extra cache-calls op. Een site met 1.000 pageviews per dag en code in de DB gecached op het FS en 1x per maand een code-wijziging levert 30.000 extra cache-calls op versus dezelfde site met code gewoon op het FS.
Wil je naast je code ook je db-resultaten gaan cachen dan praat je al snel over full-page caching en dan maakt het idd niet veel meer uit waar je code vandaan komt ( uit db of uit FS ), als het eenmaal geladen is dan is het toch compleet gecached.

Is het dan trouwens verstandig om per uniek IP-adres een nieuwe cache te genereren en de huidige te overschrijven zodat meerdere bezoekers elkaar 'voorzien' van de meest nieuwe versie van de content? Of gaat dan het cachingprincipe niet echt meer op?

Caching is redelijke tricky business als je het zover wilt doorvoeren. Als je 600.000 cache files in 1 directory stouwt heb je grote kans dat je FS langer bezig is met het ophalen uit cache dan dat het genereren van die pagina kost ( nog even daargelaten wat het aan overbodige ruimte kost om 600.000x dezelfde header / footer etc op te slaan )

Bedenk je trouwens wel goed dat het cachen zelf extra tijd kost ( het kost gewoon tijd om iets weg te schrijven ) en dat een cache per definitie oud is.

Ik meen me trouwens uit mijn hoofd te herinneren dat een gemiddelde cache pas bij een 15e hit op de cache effectief begint te worden, omdat daarvoor het aanmaken van de cache / het controleren van de cache / het invalidaten van de cache het hele nut van de cache ongedaan maakt.

Performance gewijs is full-page caching het beste ( 1 cache call per page view ), maar vanuit user oogpunt gezien heeft full-page caching zowat geen nut ( 1 goedendag mr. ... invalidate al je full-page caching ) en dan is component / widget caching weer het beste ( refreshende bezoeker levert 5 cache calls op ( zijn naam is in de cache bekend ), nieuwe bezoeker levert 4 cache calls en 1 dbase call op ( zijn naam moet opgezocht worden ) )

[mithras]

Gomez12 schreef op vrijdag 18 september 2009 @ 23:55:
[...]
[knip]

Ik geloof dat je het overzicht een beetje kwijt bent. Er staat gemiddeld drie keer het woord caching in elke zin, maar de achterliggende gedachte van mijn posts mis je geloof ik een beetje (nofi!). TS vroeg niet om caching. Natuurlijk handig, maar als ik een biefstuk bij de slager bestel hoef ik niet uitgelegd te krijgen dat ze lekkere belegde broodjes hebben

Ik zeg:

mithras schreef op vrijdag 18 september 2009 @ 22:24:
Ik zou überhaupt niet je gehele widgets in je database plempen. Je hebt een aantal widgets en een aantal container templates. Slechts de mapping plaats je in de database.

[knip]

Je slaat uiteindelijk alleen de mapping op welke widgets op welke key zitten van een bepaalde template. Dan hoef je nooit de code in de database op te slaan (imho toch wel een zeer belangrijk punt). Je kan ook de widgets nog parameters meegeven. Zo kan je de widget Text een TextId meegeven. Dit id komt dan weer overeen met een entry in je database voor een stukje tekst, wat uiteraard de gebruiker zelf kan vullen.

Je wil dat de klant in een voorgedefinieerde template zelf een samenstelling kan maken van widgets. Daar ga je zelf niet meer tussen zitten, dit moet de klant zelf kunnen bewerkstelligen.

Dus zeg ik: maak standaard templates (1, 2, 3 kolommen etc) en standaard widgets (text, blog, agenda, gallery, contact etc). Deze map je n:m naar een pagina. Deze mapping staat in de database, de widgets en containers zijn natuurlijk gewoon php scripts (waarin imho een widget een goed model is, een template een mooie view). De inhoud van die widget is natuurlijk een andere zaak, maar daar ging het in dit topic niet om

[Gomez12]

mithras schreef op zaterdag 19 september 2009 @ 00:14:
[...]
Je wil dat de klant in een voorgedefinieerde template zelf een samenstelling kan maken van widgets. Daar ga je zelf niet meer tussen zitten, dit moet de klant zelf kunnen bewerkstelligen.

Dus zeg ik: maak standaard templates (1, 2, 3 kolommen etc) en standaard widgets (text, blog, agenda, gallery, contact etc). Deze map je n:m naar een pagina. Deze mapping staat in de database, de widgets en containers zijn natuurlijk gewoon php scripts (waarin imho een widget een goed model is, een template een mooie view). De inhoud van die widget is natuurlijk een andere zaak, maar daar ging het in dit topic niet om

Tja en ik zeg dat het niet uitmaakt of de pagina nou vanuit FS of DB komt ( mits je de juiste ... hanteert om de extra overhead van de db-call op te vangen )

Als jij een perfecte db hebt met een perfect db distributie systeem en een perfect db beheersysteem dan maakt die extra overhead voor het aanmaken van een file vanuit DB niet meer uit, je beheersvoordelen stijgen hier ruimschoots boven uit.

Heb je niet een perfect db-systeem dan kost dit gewoon extra performance, op zich valt dit wel weer redelijk op te vangen ( door ... ) waardoor het geen ene fluit meer uitmaakt waar je pagina vandaan komt ( FS of DB->FS )

In de simpelste vorm ( zoals het in TS staat ) gaat het idd niet over caching, maar heb je gewoon een gigantische overhead als je elk php-script eerst uit de db wilt halen en daarna op schijf schrijven en daarna pas uitvoeren.
Je moet echt een perfect bestaand systeem hebben wil je deze overhead enigszins overbruggen zonder caching. En ik gok uit TS niet dat deze een perfect bestaand systeem heeft, dus probeer ik hem uit te leggen hoe het toch enigszins kan werken...

[.oisyn]

Gomez12 schreef op zaterdag 19 september 2009 @ 00:26:
maar heb je gewoon een gigantische overhead als je elk php-script eerst uit de db wilt halen en daarna op schijf schrijven en daarna pas uitvoeren.

Waarom zou je ze uitschrijven? Als ik het systeem zo zou ontwerpen dan zou ik gewoon eval() gebruiken. Waarom moet het eerst naar disk, om vervolgens weer van disk ingelezen te worden in het geugen (goed, in een degelijk OS beland het waarschijnlijk niet eens op disk, maar het wordt sowieso gekopiëerd naar de disk cache en weer terug) waarna er exact dezelfde parser overheen gaat?

Maar ik zou het niet zo ontwerpen, want er is nog een ding wat vergeten wordt, en dat zijn eventuele code optimizers, die helemaal niet gaan werken bij eval'd code of temporary files. Je wilt die dingen dus sowieso permanent op disk hebben.

[ Voor 15% gewijzigd door .oisyn op 19-09-2009 00:45 ]

[Gomez12]

.oisyn schreef op zaterdag 19 september 2009 @ 00:42:
[...]

Waarom zou je ze uitschrijven? Als ik het systeem zo zou ontwerpen dan zou ik gewoon eval() gebruiken. Waarom moet het eerst naar disk, om vervolgens weer van disk ingelezen te worden in het geugen (goed, in een degelijk OS beland het waarschijnlijk niet eens op disk, maar het wordt sowieso gekopiëerd naar de disk cache en weer terug) waarna er exact dezelfde parser overheen gaat?

Eval schijnt om de een of andere toch wel zwaar te zijn en toch wel redelijk misbruikt te zijn.
Dan heb je de write-to-disk call geelimineerd maar een zwaardere call gebruikt, tja het is net wat je wil.

Maar ik zou het niet zo ontwerpen, want er is nog een ding wat vergeten wordt, en dat zijn eventuele code optimizers, die helemaal niet gaan werken bij eval'd code of temporary files. Je wilt die dingen dus sowieso permanent op disk hebben.

Aaaaargggghhh. Een bestand wat een maand op disk staat ( ook al is er een extra db-call nodig om te evalueren of het vers is ) presteert / optimized net zo goed als een ander bestand wat op disk staat.
Daarom schrijf je het juist naar disk en je cached het juist weer om het op schijf te laten staan ( waardoor je gelijk profiteert van alle andere voordelen van vanaf schijf gelezen bestanden )

Dat probeer ik juist de hele tijd te zeggen, als je vanuit DB->FS goed cached dan heb je enkel 1 call meer en voor de rest heb je tijdens gebruik alle voordelen van FS.

Of ik een index.php nu via ftp upload, of via een DB-sync naar DB schrijf en daarna vanuit DB->disk maakt geen ene reet uit zolang je maar regelmatig controleert of je vanuit je DB een nieuwe index.php moet schrijven...

[.oisyn]

Gomez12 schreef op zaterdag 19 september 2009 @ 00:53:
Aaaaargggghhh.

Nee, niet "aaaargghhh". Ik onderschrijf wat jij zegt, een geef wat extra argumenten. Het feit dat er een quote in mijn post staat die uit jouw post komt impliceert niet meteen dat ik het overal mee oneens ben.

[ Voor 26% gewijzigd door .oisyn op 19-09-2009 14:24 ]