Seitenverwaltung über 'index.php' ohne (MySQL) DB
Gast
- php
0 Iapetos0 1UnitedPower0 Gast0 1UnitedPower0 Gast0 1UnitedPower0 Gast0 1UnitedPower0 dedlfix
Hallo!
Da ich mich lange nicht mehr mit diesem Thema beschäftigt habe, und bei Google aufgrund der wahrscheinlich falschen Suchbegriffe keinen brauchbaren Ergebnisse gefunden habe, möchte ich gerne hier im Forum nachfragen.
Ich habe eine kleine Website, die aus max. 20 Seiten besteht.
Jede Seite verfügt über eine "sprechende" URL und alles wird per mod_rewrite an meine 'index.php' Datei weiter- /umgeleitet.
Meine Frage beschränkt sich eigentlich im Wesentlichen darauf:
Wie "verwalte" ich (intern) meine entsprechenden Seitendaten, sprich die zu jeder Seite gehörenden individuellen Informationen (z.B. Seitentitel, META-Tag Texte etc.)?
Aufgrund des geringen Umfangs und da kaum mit größeren Änderungen & Ergänzungen zu rechnen ist, möchte ich auf eine Datenbank verzichten.
Stattdessen schwebte mir eher vor, die Daten in einem multidimensionalen Array zu speichern.
Oder hat jemand einen anderen/ besseren Vorschlag, bzw. Tipps zum Aufbau des Arrays?
Besten Dank im Voraus und einen freundlichen Gruß!
Tach,
Ich habe eine kleine Website, die aus max. 20 Seiten besteht.
Jede Seite verfügt über eine "sprechende" URL und alles wird per mod_rewrite an meine 'index.php' Datei weiter- /umgeleitet.
Bitte mal ein Beispiel, wie du dir das vorstellst (z.b. htaccess-Eintrag)
Meine Frage beschränkt sich eigentlich im Wesentlichen darauf:
Wie "verwalte" ich (intern) meine entsprechenden Seitendaten, sprich die zu jeder Seite gehörenden individuellen Informationen (z.B. Seitentitel, META-Tag Texte etc.)?Aufgrund des geringen Umfangs und da kaum mit größeren Änderungen & Ergänzungen zu rechnen ist, möchte ich auf eine Datenbank verzichten.
Stattdessen schwebte mir eher vor, die Daten in einem multidimensionalen Array zu speichern.
Es gibt in PHP keine multidimensionalen Arrays. Du willst vermutlich eine verschachtelte Array-Struktur anlegen. Keine schlechte Idee. Bitte mal das Beispiel oben.
grüße
Iapetos
Tach,
Ich habe eine kleine Website, die aus max. 20 Seiten besteht.
Jede Seite verfügt über eine "sprechende" URL und alles wird per mod_rewrite an meine 'index.php' Datei weiter- /umgeleitet.Bitte mal ein Beispiel, wie du dir das vorstellst (z.b. htaccess-Eintrag)
Das ist ja gar nicht meine Frage. ;-)
Aber ja, ich habe entsprechende RewriteRules in einer .htaccess, die alle Aufrufe auf die 'index.php' umleiten.
Meine Frage beschränkt sich eigentlich im Wesentlichen darauf:
Wie "verwalte" ich (intern) meine entsprechenden Seitendaten, sprich die zu jeder Seite gehörenden individuellen Informationen (z.B. Seitentitel, META-Tag Texte etc.)?Aufgrund des geringen Umfangs und da kaum mit größeren Änderungen & Ergänzungen zu rechnen ist, möchte ich auf eine Datenbank verzichten.
Stattdessen schwebte mir eher vor, die Daten in einem multidimensionalen Array zu speichern.
Es gibt in PHP keine multidimensionalen Arrays. Du willst vermutlich eine verschachtelte Array-Struktur anlegen.
Nicht!? Also Google findet haufenweise Seiten, die das anders sehen. Hier nur mal ein willkürlich herausgegriffen: http://webcheatsheet.com/PHP/multidimensional_arrays.php
Aber ob nun "multidimensional" oder "verschachtelt" ist mir ehrlich gesagt "wurscht".
Keine schlechte Idee. Bitte mal das Beispiel oben.
Im Prinzip möchte ich ein möglichst einfaches "System" à la MVC haben.
Mein Controller analysiert den Request, das Modell holt die passenden Daten und im View wird das Ganze dann schließlich "zusammen gebastelt" für die Ausgabe/ Anzeige.
Nur möchte ich meine Daten eben nicht in einer DB speichern, sondern bspw. in Dateien, und die erforderlichen sonstigen (Meta-)Daten halt in einem, oder mehreren Array(s).
MfG
Tach,
Ich habe eine kleine Website, die aus max. 20 Seiten besteht.
Jede Seite verfügt über eine "sprechende" URL und alles wird per mod_rewrite an meine 'index.php' Datei weiter- /umgeleitet.Bitte mal ein Beispiel, wie du dir das vorstellst (z.b. htaccess-Eintrag)
Das ist ja gar nicht meine Frage. ;-)
Aber ja, ich habe entsprechende RewriteRules in einer .htaccess, die alle Aufrufe auf die 'index.php' umleiten.
Du leitest alles auf eine Datei namens index.php weiter. Gut. Wie aber sieht das aus? Das ist _meine_ Frage. Wird der Querystring in PHP analysiert oder legst du ca. 20 Weiterleitungen in der htaccess an?
Meine Frage beschränkt sich eigentlich im Wesentlichen darauf:
Wie "verwalte" ich (intern) meine entsprechenden Seitendaten, sprich die zu jeder Seite gehörenden individuellen Informationen (z.B. Seitentitel, META-Tag Texte etc.)?
du sprachst von sprechenden URLs, also z.b. example.com/category/post
example.com/foo/bar
example.com/baz/quux
$pages = array(
"foo/bar" => array(
"meta_desc" => "some meta description",
"meta_keywords => "baz, foo, gumbo",
"page_title" => "this is the bar of a foo",
),
"baz/quux" => array(
"meta_desc" => "some meta description",
"meta_keywords => "baz, quux, tango",
"page_title" => "this is the quux of a baz",
),
);
Stattdessen schwebte mir eher vor, die Daten in einem multidimensionalen Array zu speichern.
Es gibt in PHP keine multidimensionalen Arrays. Du willst vermutlich eine verschachtelte Array-Struktur anlegen.
Man kann mit PHPs Key-Value-Map multidimensionale Arrays imitieren.
Tach,
Du leitest alles auf eine Datei namens index.php weiter. Gut. Wie aber sieht das aus? Das ist _meine_ Frage. Wird der Querystring in PHP analysiert oder legst du ca. 20 Weiterleitungen in der htaccess an?
Nein, keine Weiterleitungen in der htaccess. Dann würde ich doch nicht alles auf die 'index.php' umleiten ...! ;-)
Und ich "analysiere" den Request (Querystrings kommen bis jetzt keine vor).
Meine Frage beschränkt sich eigentlich im Wesentlichen darauf:
Wie "verwalte" ich (intern) meine entsprechenden Seitendaten, sprich die zu jeder Seite gehörenden individuellen Informationen (z.B. Seitentitel, META-Tag Texte etc.)?du sprachst von sprechenden URLs, also z.b. example.com/category/post
example.com/foo/bar
example.com/baz/quux
Jetzt verstehen wir uns ...! :-)
$pages = array(
"foo/bar" => array(
"meta_desc" => "some meta description",
"meta_keywords => "baz, foo, gumbo",
"page_title" => "this is the bar of a foo",
),
"baz/quux" => array(
"meta_desc" => "some meta description",
"meta_keywords => "baz, quux, tango",
"page_title" => "this is the quux of a baz",
),);
Genau das ist ein Beispiel dafür, was ich wissen wollte - danke!
Nämlich wie ich ggf. das/die Array(s) so anlege, dass es zwar einerseits "flexibel" (für mögliche Änderungen/ Erweiterungen) bleibt, aber andererseits nicht unnötig "kompliziert".
Den Pfad aus dem Request als Schlüssel zu verwenden, war auch meine erste Idee. Erscheint irgendwie am logischsten/ sinnvollsten/ einfachsten. Und wie ich sehe, scheine ja nicht nur ich das so zu sehen.
So möchte ich u.a. auch eine Möglichkeit haben, eine Weiterleitung (Redirect) anlegen zu können, für den Fall, dass sich später mal eine URL ändern sollte.
MfG
Moin!
$pages = array(
"foo/bar" => array(
"meta_desc" => "some meta description",
"meta_keywords => "baz, foo, gumbo",
"page_title" => "this is the bar of a foo",
),
"baz/quux" => array(
"meta_desc" => "some meta description",
"meta_keywords => "baz, quux, tango",
"page_title" => "this is the quux of a baz",
),
);
>
> Genau das ist ein Beispiel dafür, was ich wissen wollte - danke!
Dazu noch [PHP: Speichern und Lesen von Daten- Arrays in und aus Dateien](http://www.fastix.org/PHP-+Speichern+und+Lesen+von+Daten-+Arrays+in+und+aus+Dateien.htm) und das Grundgerüst steht.
Jörg Reinholz
Tach!
Es gibt in PHP keine multidimensionalen Arrays. Du willst vermutlich eine verschachtelte Array-Struktur anlegen.
Nicht!? Also Google findet haufenweise Seiten, die das anders sehen. Hier nur mal ein willkürlich herausgegriffen: http://webcheatsheet.com/PHP/multidimensional_arrays.php
Der Begriff "multidimensional" ist einfach zu handhaben und deshalb weit verbreitet - allerdings mehr in der PHP-Welt als anderswo, denn anderswo hat man spezialisierte Verwaltungsstrukturen mit speziellen Namen (zum Beispiel List, Dictionary, Tree) und macht nicht alles mit einer Universalstruktur namens "PHP-Array". Multidimensional im eigentlichen Wortsinne bedeutet, dass etwas in mehrere Richtungen verläuft und das zielstrebig macht. Die Zielstrebigkeit setzt voraus, dass man ein regelmäßiges Fortschreiten erkennen kann, also im allgemeinen fortlaufende Zahlen als Index hat. Bei einem Array mit Datensatz-Arrays hat man den fortlaufenden numerischen Schlüssel üblicherweise nur im Hauptarray, die Datensatz-Arrays hingegen haben Feldnamen als Schlüssel. Man kann mit PHP mehrdimensionale Arrays im eigentlichen Wortsinn mit Hilfe verschachtelter Arrays abbilden, aber das hat man eher selten und mehr bei mathematischen Problemen, die man eher nicht mit PHP und als Webanwendung löst.
Zur eigentlichen Frage: Als Alternative zu MySQL gibt es die kleine Variante SQLite, das ini-Format (in gewissen Grenzen schachtelbar), XML und Arrays im PHP-Code. Letzteres hat den Vorteil, dass es einfach aufzusetzen ist und sofort zur Verfügung steht, ohne erst noch mit weiterm Code eingelesen werden zu müssen. Nachteilig kann sein, dass ein Mindestmaß an PHP-Syntax notwendig ist, um gefahrlos Änderungen darin vornehmen zu können. Auch ist das eine Zu-Fuß-Angelegenheit, wenn man vermeiden möchte, dass ein Verwaltungsscript direkt PHP-Code erzeugt, statt lediglich die Daten in den jeweilgen anderen Strukturen abzulegen.
dedlfix.
Meine Herren,
Aufgrund des geringen Umfangs und da kaum mit größeren Änderungen & Ergänzungen zu rechnen ist, möchte ich auf eine Datenbank verzichten.
Stattdessen schwebte mir eher vor, die Daten in einem multidimensionalen Array zu speichern.
Was erhoffst du dir davon? Bestehende Datenbanken haben den Vorteil, dass sie viele bekannte Probleme der Datenverwaltung bereits implementieren, sie sind ausführlich getestet und werden ständig weiter entwickelt. Mit dem Verzicht auf ein fertiges Datenbanksystem machst du dir nur mehr Arbeit, weil du Probleme, die andere schon für dich gelöst haben, dann selber erneut lösen musst. Tue dir selber einen gefallen und wähle etwas fertiges.
Bei einer genügend kleinen Seite, die mit Sicherheit wenig Wartungsarbeit benötigt, könnte ich mir aber auf der anderen Hand auch eine rein statische Seite vorstellen. Aber das ist ohne die genaueren Umstände zu kennen nicht zu beantworten.
Hallo,
Aufgrund des geringen Umfangs und da kaum mit größeren Änderungen & Ergänzungen zu rechnen ist, möchte ich auf eine Datenbank verzichten.
Stattdessen schwebte mir eher vor, die Daten in einem multidimensionalen Array zu speichern.
Was erhoffst du dir davon? Bestehende Datenbanken haben den Vorteil, dass sie viele bekannte Probleme der Datenverwaltung bereits implementieren, sie sind ausführlich getestet und werden ständig weiter entwickelt. Mit dem Verzicht auf ein fertiges Datenbanksystem machst du dir nur mehr Arbeit, weil du Probleme, die andere schon für dich gelöst haben, dann selber erneut lösen musst. Tue dir selber einen gefallen und wähle etwas fertiges.
Sehe ich nicht so. Warum soll ich wegen den paar Seiten den ganzen "Overhead" einer Datenbankanbindung einbauen und mich obendrein noch einer Resource mehr "abhängig" machen?
Die ppar "variablen" Daten eben in einem oder mehreren Arrays abzuspeichern und ggf. noch eine "vernünftige" Caching-Variante einzubauen, dürfte imho völlig ausreichend sein.
Und welche "Probleme" siehst du denn da?
Was ich eigentlich "nur" wissen wollte ist, ob bspw. etwas für oder gegen die Verwendung von einem Array spricht, oder ob es vorteilhafter ist, mehrere Arrays zu verwenden, und wie ggf. eine geeignete Array-Struktur aussehen könnte?
Im <head> sind bspw. der <title> und die Meta-Tags für jede Seite unterschiedlich.
Ansonsten besitzen alle Seiten u.a. den gleichen Header und Footer. Und im Menü muss die jeweils aktuelle Seite entsprechend gekennzeichnet sein.
Und selbst wenn es abweichende Seiten geben sollte, kann ich ja dafür verschiedene Templates anlegen/ erstellen. Ich muss halt nur "irgendwo" vermerken, welche Seite welches Template verwenden soll.
MfG
Meine Herren,
Sehe ich nicht so. Warum soll ich wegen den paar Seiten den ganzen "Overhead" einer Datenbankanbindung einbauen
Um dir Arbeit zu ersparen.
und mich obendrein noch einer Resource mehr "abhängig" machen?
Eine Abhängigkeit von bspw. MySQL ist heute i.d.R. kein Problem mehr, weil sowieso fast überhall vorhanden, wo es auch PHP gibt.
Und welche "Probleme" siehst du denn da?
Allgemeine Probleme der Datenverwaltung: Relationen, Redundanzen, Rechteverwaltung, Backups....
Was ich eigentlich "nur" wissen wollte ist, ob bspw. etwas für oder gegen die Verwendung von einem Array spricht,
oder ob es vorteilhafter ist, mehrere Arrays zu verwenden, und wie ggf. eine geeignete Array-Struktur aussehen könnte?
Ein Beispiel: Wie würdest du eine nm-Relationen mit Arrays abbilden? Und wenn du jetzt einen festen Eintrag N löschen willst und damit alle dazugehörigen M, wie würdest du vorgehen? Ein recht simples und immer wiederkehrendes Problem von Datenbeständen.
Hallo!
Sehe ich nicht so. Warum soll ich wegen den paar Seiten den ganzen "Overhead" einer Datenbankanbindung einbauen
Um dir Arbeit zu ersparen.
Macht aber erstmal welche ...! ;-)
und mich obendrein noch einer Resource mehr "abhängig" machen?
Eine Abhängigkeit von bspw. MySQL ist heute i.d.R. kein Problem mehr, weil sowieso fast überhall vorhanden, wo es auch PHP gibt.
Und welche "Probleme" siehst du denn da?
Allgemeine Probleme der Datenverwaltung: Relationen, Redundanzen, Rechteverwaltung, Backups....
Die ersten drei Punkte treten nicht auf. Und Backups werden eher einfacher, da man "nur" die Dateien sichern muss und nicht zusätzlich auch noch eine DB. ;-)
Was ich eigentlich "nur" wissen wollte ist, ob bspw. etwas für oder gegen die Verwendung von einem Array spricht,
oder ob es vorteilhafter ist, mehrere Arrays zu verwenden, und wie ggf. eine geeignete Array-Struktur aussehen könnte?Ein Beispiel: Wie würdest du eine nm-Relationen mit Arrays abbilden? Und wenn du jetzt einen festen Eintrag N löschen willst und damit alle dazugehörigen M, wie würdest du vorgehen? Ein recht simples und immer wiederkehrendes Problem von Datenbeständen.
Hatte ich erwähnt, dass es sich im Prinzip um "statische" Seiten handelt!? :-P
Wenn das was zu ändern ist, muss das eh "zu Fuß" erledigt werden ...!
Ich glaube, du wähnst die Sache "zu groß". ;-)
MfG
Meine Herren,
Hatte ich erwähnt, dass es sich im Prinzip um "statische" Seiten handelt!? :-P
Wenn das was zu ändern ist, muss das eh "zu Fuß" erledigt werden ...!Ich glaube, du wähnst die Sache "zu groß". ;-)
Einmal sprichst du von MVC und Routing und ein anderes mal von statischen Seiten, das passt nicht zusammen. Hast du nun Models, die mit Hilfe von Controllern und Templates zu Views geschustert werden, oder hast du statische HTML-Seiten? Ich komme nicht mehr hinterher.
Hallo!
Hatte ich erwähnt, dass es sich im Prinzip um "statische" Seiten handelt!? :-P
Wenn das was zu ändern ist, muss das eh "zu Fuß" erledigt werden ...!Ich glaube, du wähnst die Sache "zu groß". ;-)
Einmal sprichst du von MVC und Routing und ein anderes mal von statischen Seiten, das passt nicht zusammen. Hast du nun Models, die mit Hilfe von Controllern und Templates zu Views geschustert werden, oder hast du statische HTML-Seiten? Ich komme nicht mehr hinterher.
Also entschuldige bitte, falls ich dich mit meinen Aussagen in die Irre geführt haben sollte - keine Absicht. ;-)
Der eigentliche Inhalt (Content) der ca. 20 Seiten ist mehr oder weniger "statisch". Und selbst wenn da mal etwas geändert werden muss, dann kann ich das bequem in der jeweiligen Datei machen.
Um jetzt aber den Aufwand mit den "sprechenden URLs" möglichst gering zu halten und dabei auch flexibel zu bleiben, leite ich alles auf meine 'index.php' um. Dort "arbeitet" es sich imho einfacher, als bspw. in einer .htaccess Datei.
Jetzt hat jede Seite aber neben dem eigentlichen Inhalt ja auch noch andere individuelle "Daten", wie bspw. die jeweiligen Meta-Daten. Jetzt kann ich ja bequem für die verschiedenen "Teile" einer Seite entsprechende Templates (Dateien) anlegen.
Wenn jetzt also ein Request in meiner 'index.php' landet, muss dieser "analysiert" werden (welche Seite wird verlangt), die entsprechenden Daten "irgendwoher" geholt werden, und schließlich die komplette Seite aus den einzelnen Templates zusammengesetzt und ausgegeben werden.
Entspricht das nicht dem MVC Prinzip?
Nach meiner Vorstellung schon. Nur dass das i.d.R. für "größere" Projekte, oder solche mit sich häufig ändernden Daten gedacht ist, und deshalb eigentlich immer auf eine DB-Lösung setzt.
Ich möchte das aber nur in "klein", sprich anstelle der DB möchte ich meine "Daten" direkt in meiner 'index.php' in einem oder mehreren Array(s) speichern.
MfG
Meine Herren,
Entspricht das nicht dem MVC Prinzip?
Jein, du mischst ein wenig MVC mit Routing und statischen Seiten. Im Idealfall würdest du dich für statisch oder MVC entscheiden und dann konsistent mit einem von beidem arbeiten. Bei rein statischen Seiten müsstest du dich nicht einmal um das Routing kümmern, weil die meisten Apache-Server so vorkonfiguriert sind, dass das Dateisystem unterhalb des Document-Root mit den URLs korrespondiert. Du machst aber einen einen wilden Mix aus beidem, der Hauptinhalt scheint bei dir aus HTML-Seiten zu stammen, Meta-Informationen dagegen versuchst du in der Route (Zuweisung von URL zu Ressource) zu speichern. Die drei Konzepte MVC, Routing und statischer Inhalt sind konzeptionell schon einander getrennt und das sollte sich auch in der Implementation wiederspiegeln. Das sind etablierte Design-Patterns, die man nutzen kann, aber natürlich nicht muss.
Meine Herren
Im Idealfall würdest du dich für statisch oder MVC entscheiden und dann konsistent mit einem von beidem arbeiten.
Bevor mir jemand einen Strick aus diesem Satz dreht, mach ich es lieber selber: Auch bei MVC-basierten Anwendungen gibt es natürlich statische Ressourcen, wie Stylesheets, Javascript-Dateien etc. Der Fokus lag hier auf den Hauptinhalt der Seite.
Tach!
Entspricht das nicht dem MVC Prinzip?
Wie 1UnitedPower schon sagte, mischst du hier etwas zusammen. MVC an sich ist nur das Muster, dass man einen Controller hat, der das Model und die View zusammenbringt. Wie der Controller angesprochen und ausgewählt wird, ist nicht Bestandteil des Musters. Da Code entsprechend diesem Muster allein aber nicht lebensfähig ist, braucht man noch diverse andere Muster. Das eine ist das Routing, das Daten eines Requests analysiert und daraufhin den entsprechenden Controller ermittelt. Wenn du einen gemeinsamen Einstieg für alle Requests erstellst, dann spricht man in der Regel von einem Front Controller (hat nichts mit dem MVC-Controller zu tun). MVC-basierende Systeme haben üblicherweise diese Dinge mit an Bord, deswegen sind sie aber kein Bestandteil des MVC-Musters an sich.
dedlfix.