Templates: XML, DB oder/und PHP für Linkliste, Newsübersicht etc

[[MuhTuhls.}]

hi community,
ich hätte da mal 'ne Frage. Ich programmiere schon seit zwei Jahren PHP - auch OOP5 - und wollte jetzt mal ein richtig sauberes Projekt - OO, mit Framework (kohana, oder was meint ihr? - mir geht's vor allem um ein sauberes (OO)-Konzept [Features kann man ja nachrüsten] - aber zurück zum eigentl. Thema), MVC etc. - auf die Beine stellen, weil ich endlich mal "zeitdrucklos" bin, d.h. ein netter Auftraggeber ;-)

Naja, wenn ich schon mal Zeit hab, will ich auch gleich besondere Features bieten, klar. Ich dachte mir da mal:
*1 CURIEs (ein Prefix für interne Links, ein Prefix für externe Links)
*2 Visitenkarten (werden automatisch in die xHTML-Mitarbeiterseite eingefügt - halt um Info und [HTML]-Formatierung zu trennen) - ich könnte mir auch vorstellen ein paar andere Infos nicht direkt als HTML zu schreiben.
*3 Links (eine Liste handerlesener [vielleicht zusätzlich auch eine Liste generierter] Links, die zu weiterführenden)
Wie ihr ja sicher schon bei *2 bemerkt habt, tu' ich mir schwer: Ich halte es für unmöglich bzw. schaffe es nicht ;-), M und V eines MVC - oder hMVC, wie's jetzt in Kohana3 heißt ;-) - richtig zu trennen - ich meine, in Prinzip ist doch jeder Text in einer Webseite eine Information, d.h. es würde dann folglich zumindest theoretisch in das M gehören - anderseits muss ich ja den Text - gleich dort wo er gespeichert ist, sonst wird es unübersichtlich ;-) - formatieren (<b> [oder <strong> , wie es in "NeuHTMLisch" heißt ;-)], <p>), was meines Erachtens ein klarer V-Fall ist - also wohin damit?

Ich denke, das es wohl das Sinnvollste ist, Texte und andere menschenbestimmte semi- bis unstruktierten Daten in den View "auszulagern", weil die ja eh nur für die Präsentation (auch nur für Menschen) brauchbar sind, und nur strukturierten Einzug ins M zu gewähren. Was uns zur Frage bringt: Ab wann sind Daten strukturiert? Ich werde mich eben auf die Bücherauflistung, die News, die Linklisten und die Visitenkarten (sonst nur Texte, Lebensläufe, Publikationsangaben-Auflistungen) beschränken - alle einverstanden?

Nun aber zur eigentlichen Frage: Wie macht man das so bei Frameworks - mit den strukturierten Daten?
Meine Vorschläge:
Extremmodell Datenbank: Ich schmeiße alles (News, Linklisten, Visitenkarten - und au) in Tabellen - alles voll MVC.
Extremmodell XML: Ich schreibe XML-Dateien für News (in Atom), Linklisten (xLink) etc. und binde die via xInclude in den V ein. Dann unterziehe ich das alles XSLT. Via role-Attribute gebe ich an, in welcher Beziehung die XML-Daten zum V stehen - je nachdem verhält sich XSLT anders. Für den lesenden bzw. schreibenden Zugriff durch PHP auf die XML-Daten (wenn sie nicht für die Präsentation, sondern für die int. Verarbeitung benötigt werden) hinterlege ich xQueries bzw. xUpdate-Informationen - alles voll XML-Style :-)
Hybridmodell Datenbank: Ich verwende zwar zum einfacheren Ändern bzw. Schreiben der Daten durch den Administrator (bin NICHT ich, sondern ein Basis-HTML-Mensch, kein Programmierer, der Änderungen halt so einfach wie möglich haben will) XML, parse das dann gleich und schreibe's in die Datenbank. PHP liest (wenn PHP kein Analphabet ist ;-) ) nur mehr aus der Datenbank - auch für die Präsentation.
Hybirdmodell XML: Das XML wird vom direkt Modell angesprochen (ohne DB dazwischen) - sonst halt wie das andere Hybridmodell.
Auch Alternativmodelle sind mir als MVC-Anfänger recht.

Randbemerkung: Ich habe oben sehr zur Vorgeschichte geschrieben, damit Anfangsdenkfehler oder Fehlschlüsse, wie es zu dieser Frage kam, vielleicht mir gleich offenbaren könnt. Danke, dass ihr euch meinen Roman durchlest! ;-)

So, danke für alle Antworten, für Gegenfragen bin ich immer zu haben und lgMuhTuhls.

[hotti]

hi,

Nun aber zur eigentlichen Frage: Wie macht man das so bei Frameworks - mit den strukturierten Daten?

Nunja, das MVC Konzept sieht ja vor, Daten, Eingaben und ihre Darstellung nicht als Einheit zu betrachten.

Beim Lesen dieses Artikels ist mir mal wieder klar geworden, wie dogmatisch so mancher Betrachtungsweise ist. Entweder Oder? Nö!

Warum nicht "Daten+Eingaben+Ergebnis" als eine Einheit und nur die "Darstellung" ist eine andere Geschichte? Das vereinfacht ne ganze Menge und der Code wird extrem übersichtlich, erst kürzlich habe ich das mal hier aufgeschrieben, leben tu ich das schon länger.

Wesentlich: die Datenstruktur ist so beschaffen, dass damit verschiedene Darstellungen möglich sind (HTML, Ajax-Responses) und einer Transformation in andere Datenstrukturen (XML, proprietäre Formate...) nichts im Wege steht.

Eine darauf aufgesetzte gut durchdachte Klassenhierarchie ist sowohl für Einzelgänger als auch für die Team-Kollegen interessant: Letztere kriegen einfach eine Klasse in die Hand gedrückt und können sich auf das Wesentliche konzentrieren, sie arbeiten lediglich mit einer Instanz der Klasse, die im Hintergrund eine DB-Anbindung realisiert, Raketen zum Mond schickt oder U-Boote versenkt...

Nur malso als Anregung,
Hotti

[dedlfix]

Hi!

Nunja, das MVC Konzept sieht ja vor, Daten, Eingaben und ihre Darstellung nicht als Einheit zu betrachten.

Eingaben sind auch Daten und es ist keineswegs eine Trennung von Eingabe und anderen Daten vorgesehen. Wenn überhaupt, dann ergibt sich das aufgrund der verschiedenen Herkunftsorte von Eingabedaten und solchen aus einer Datenhaltung. Letzlich ist es aber für die einzelnen Module unerheblich, woher die Daten kommen. Idealerweise schreibt man sie so, dass sie die Daten in einer generischen Form bergeben bekommen, so dass man auch mal die Quelle wechseln kann, ohne die verarbeitenden Module ändern zu müssen.

Beim Lesen dieses Artikels ist mir mal wieder klar geworden, wie dogmatisch so mancher Betrachtungsweise ist. Entweder Oder? Nö!

Es ist manchmal nicht verkehrt. Außerdem gibt es eine Menge Leute, die die Ordnung eines Dogmas einer "freien Kreativität" vorziehen.

Warum nicht "Daten+Eingaben+Ergebnis" als eine Einheit und nur die "Darstellung" ist eine andere Geschichte? Das vereinfacht ne ganze Menge und der Code wird extrem übersichtlich, erst kürzlich habe ich das mal hier aufgeschrieben, leben tu ich das schon länger.

Für kleinere Projekte ist es durchaus legitim, mehr oder weniger alles in einem Topf zu kochen. Aber wenn es darauf ankommt, dass man die einzelnen Teile automatisch testen lassen können möchte, muss man die Module unabhängig voneinander schreiben. Test Driven Development ist gerade für größere Projekte wichtig für die Qualität, denn je größer ein Projekt wird, desto schwieriger wird es, den Übersicht über alle Abhängigkeiten zu bewahren. Nicht nur um diese Abhängigkeiten übersichtlich zu gestalten, sondern eben auch, um die Module einzeln testen zu können, ist eine Trennung sehr wohl sinnvoll.

Lo!

[hotti]

moin,

Für kleinere Projekte ist es durchaus legitim, mehr oder weniger alles in einem Topf zu kochen. Aber wenn es darauf ankommt, dass man die einzelnen Teile automatisch testen lassen können möchte, muss man die Module unabhängig voneinander schreiben. Test Driven Development ist gerade für größere Projekte wichtig für die Qualität, denn je größer ein Projekt wird, desto schwieriger wird es, den Übersicht über alle Abhängigkeiten zu bewahren. Nicht nur um diese Abhängigkeiten übersichtlich zu gestalten, sondern eben auch, um die Module einzeln testen zu können, ist eine Trennung sehr wohl sinnvoll.

Natürlich besteht auch bei voneinander abhängigen Modulen die Gefahr des Verlust der Übersicht, da hast Du schon recht. Forster (Perl Module) empfiehlt dazu, die Hierarchie nicht von "oben" nach "unten" zu designen, sondern genau andersherum, also mit den abgeleiteten Klassen zu beginnen.

Damit lassen sich die Aufgaben genausogut verteilen, wie im Falle voneinander unabhängiger Klassen, besser noch: Es greift Eines ins Andere, Schnittstellen sind einheitlich definiert und der Code bleibt übersichtlich sowie modular. Beispiel:

date
date::calc
date::calc::html

Der (die) Entwickler von 'date::calc::html' designen nur die Darstellung, fehlt z.B. css, ist das nur eine Angelegenheit von 'date::calc::html'. Fehlt jedoch beispielsweise ein Datenfeld in der übergeordneten Instanz (z.B. der Wochentag), liegt die Zuständigkeit in 'date::calc'. Gäbe es keine Hierarchie, müssten sich die html-Designer mit einer Formel rumplagen, die den Wochentag berechnet.

Es ist mit OOP wie mit anderen Dingen: Sinnvoll und zweckbestimmend einsetzen.

Grüße an Alle,
Hotti

[dedlfix]

Hi!

Ich programmiere schon seit zwei Jahren PHP - auch OOP5 - und wollte jetzt mal ein richtig sauberes Projekt - OO, mit Framework (kohana, oder was meint ihr? - mir geht's vor allem um ein sauberes (OO)-Konzept [Features kann man ja nachrüsten] - aber zurück zum eigentl. Thema), MVC etc. - auf die Beine stellen, weil ich endlich mal "zeitdrucklos" bin, d.h. ein netter Auftraggeber ;-)

Selbst ohne Zeitdruck, darf angezweifelt werden, ob du gleich beim ersten Wurf ein "sauberes" Ergebnis erzeugen kannst. Üblicherweise fängt man ja nicht erst dann zu programmieren an, wenn man sich "komplett" in ein neues System eingearbeitet hat. Dafür juckt es dann doch in den Fingern, und Theorie will durch Praxis bestätigt werden. Dazu erst ein Testprojekt aufsetzen, wenn man doch vielleicht gleich auf das Ergebnis des Lernprozesses für die eigentlich gplante Anwendung aufbauen kann ...?

Naja, wenn ich schon mal Zeit hab, will ich auch gleich besondere Features bieten, klar. Ich dachte mir da mal:
*1 CURIEs (ein Prefix für interne Links, ein Prefix für externe Links)

Davon lese ich gerade zum ersten Mal. Du meinst sicher W3Cs CURIE-Syntax. Aber abgesehen von meiner Unkenntnis diesbezüglich kann vermutlich auch kein anderer bewerten, was du dir dabei gedacht hast, wenn du die Anforderungen an das Projekt nicht beschreibst.

*2 Visitenkarten (werden automatisch in die xHTML-Mitarbeiterseite eingefügt - halt um Info und [HTML]-Formatierung zu trennen) - ich könnte mir auch vorstellen ein paar andere Infos nicht direkt als HTML zu schreiben.

Siehe oben.

*3 Links (eine Liste handerlesener [vielleicht zusätzlich auch eine Liste generierter] Links, die zu weiterführenden)

Dieser Satz ist nicht
Ansonsten, siehe oben. Welche Aufgabenstellung soll damit erfüllt werden?

Wie ihr ja sicher schon bei *2 bemerkt habt, tu' ich mir schwer: Ich halte es für unmöglich bzw. schaffe es nicht ;-), M und V eines MVC - oder hMVC, wie's jetzt in Kohana3 heißt ;-) - richtig zu trennen - ich meine, in Prinzip ist doch jeder Text in einer Webseite eine Information, d.h. es würde dann folglich zumindest theoretisch in das M gehören

Handelt es sich um statischen Text für das Seitengerüst oder um Inhalte, die aus einer Datenhaltung geholt werden? Manche Texte können auch gleich im von der View verwendeten Template stehen. Das musst du mit Erfahrung und unter Beachtung der Aufgabenstellung abschätzen, was wohin gehört. Um diese Erfahrung zu sammeln, wirst du hauptsächlich aus deinen Fehlern und Erfolgen lernen müssen. Selbst wenn du anderswo etwas abschaust, das sich dort bewehrt hat, heißt das noch lange nicht, dass das auch auf deinen Fall zutrifft.

• anderseits muss ich ja den Text - gleich dort wo er gespeichert ist, sonst wird es unübersichtlich ;-) - formatieren (<b> [oder <strong> , wie es in "NeuHTMLisch" heißt ;-)], <p>), was meines Erachtens ein klarer V-Fall ist - also wohin damit?

Auch <b> ist mittlerweile wieder neuHTMLisch, aber sei's drum. Die Frage ist, ob es für dich zum Inhalt zählt oder zur Struktur. Texte in einem CMS sind Inhalt und mitunter auf irgendeine Weise vorformatiert, vielleicht mit HTML-Elementen, vielleicht mit einer anderen Syntax (z.B. Wiki), die erst noch geparst und umgesetzt werden muss.

Ich denke, das es wohl das Sinnvollste ist, Texte und andere menschenbestimmte semi- bis unstruktierten Daten in den View "auszulagern", weil die ja eh nur für die Präsentation (auch nur für Menschen) brauchbar sind, und nur strukturierten Einzug ins M zu gewähren. Was uns zur Frage bringt: Ab wann sind Daten strukturiert?

Egal ob strukturiert oder nicht, veränderliche Daten sind die, die man üblicherweise mit einem M abfragt. Es muss übrigens für einen Request nicht immer nur genau ein M, ein V und ein C verwendet werden. Ein C kann durchaus auch mehrere Ms befragen, oder der Request wird von mehreren Cs bedient, die jeweils ein Anzeigemodul mit Inhalt füllen (lassen). Den Kombinationsmöglichkeiten sind da keine Grenzen gesetzt.

Ich werde mich eben auf die Bücherauflistung, die News, die Linklisten und die Visitenkarten (sonst nur Texte, Lebensläufe, Publikationsangaben-Auflistungen) beschränken - alle einverstanden?

Ohne Wissen über die Anforderungen keine konkrete Meinung meinerseits.

Nun aber zur eigentlichen Frage: Wie macht man das so bei Frameworks - mit den strukturierten Daten?

Mach es, wie du es für sinnvoll und praktikabel hältst. Deine Ms sind nicht auf eine Technik beschränkt. Jedes M darf auch andere Datenquellenarten anzapfen. Das ist ja der Vorteil der Kapslung in das M, dass der C seine Daten bekommt, egal woher die Ms sie holen.

Randbemerkung: Ich habe oben sehr zur Vorgeschichte geschrieben, damit Anfangsdenkfehler oder Fehlschlüsse, wie es zu dieser Frage kam, vielleicht mir gleich offenbaren könnt. Danke, dass ihr euch meinen Roman durchlest! ;-)

Dein Ziel hast du nicht beschrieben, du philosophierst gerade nur über den Weg.

Lo!

[[MuhTuhls.}]

hi,

Selbst ohne Zeitdruck, darf angezweifelt werden, ob du gleich beim ersten Wurf ein "sauberes" Ergebnis erzeugen kannst. Üblicherweise fängt man ja nicht erst dann zu programmieren an, wenn man sich "komplett" in ein neues System eingearbeitet hat. Dafür juckt es dann doch in den Fingern, und Theorie will durch Praxis bestätigt werden. Dazu erst ein Testprojekt aufsetzen, wenn man doch vielleicht gleich auf das Ergebnis des Lernprozesses für die eigentlich gplante Anwendung aufbauen kann ...?

Selbstverständlich werde ich mich vor dem eigentlichen Programmierbeginn ein bisschen in mein Framework "einfühlen". Ich hab mir aber gedacht, dass ich das Konzept zuerst auf dem "Reisnagelbrett" designen will, damit ich gleich etwas ähnliches - natürlich vereinfacht - ausprobieren kann. Erfahrungsgemäß stoße ich dann oft auf Probleme in der Architektur, die ich dann in der "echten" Anwendung vermeiden/umgehen kann.

*1 CURIEs (ein Prefix für interne Links, ein Prefix für externe Links)

Davon lese ich gerade zum ersten Mal. Du meinst sicher W3Cs CURIE-Syntax.

Der sind hinter meinen lieben CURIEs ist, will ich mit Hilfe eines Beispiels erläutern - sollte die Verwendung für meine Zwecke als sinnlos eingestuft werden, dann bitte ich um Aufklärung ;-)

Ich verlinke auf eine Seite einer Universität - MEHRFACH - von meiner Seite aus. Universitäten werden ja (zumindest in Österreich) ständig umstrukturiert, somit kann es schnell sein, dass ein Institut zu einer Abteilung wird => Seite hat eine neue URI. Jetzt geht's ans Überarbeiten aller href-Attribute - Freude kommt auf :-)
Jetzt will ich nur so etwas wie <a xmlns:extern="http://www.example.com/" href="extern:unigraz"></a> (http://www.example.com/ [ja, ich weiß, dass es von diese Seite neuerdings auf http://www.iana.org/domains/example/ umleitet ;-)] wäre in diesem Beispiel der Namensraum für CURIEs für externe Sites) schreiben, an einer zentralen Stelle wäre dann aufgelistet, welche CURIE für welche URL eines externen Links steht. So ähnlich würde ich das dann auch mit den internen Links machen.

Aber abgesehen von meiner Unkenntnis diesbezüglich kann vermutlich auch kein anderer bewerten, was du dir dabei gedacht hast, wenn du die Anforderungen an das Projekt nicht beschreibst.

Naja, es ist ein Projekt mit Anforderungen der Marke "nichts besonderes". Damit meine ich:
* Muss einfach zu warten sein.
* Muss keine besondere Performance haben, da nur ca. 120 visitors daily.
* Ich habe "lebenslange Haftung" für diese Seite und muss die Site gegebenfalls erweitern, reparieren oder umstrukturieren, d.h. eine unsaubere, halb funktionstüchtige Site produzieren und flüchten gibt's nicht ;-)
* Die meisten Inhalte der Seite sind textuell (also normales HTML), sonst gibt's noch:
 - Mitarbeiter-Personalien, also E-Mail, Telefon und Fax der einzelnen Mitarbeiter
 - Auflistung von Publikationsangaben zu Publikationen der einzelnen Unternehmensmitarbeiter
 - Eine Auflistung von Produkten (d.h. Büchern), die vom Unternehmen stammen
 - Ein paar Formulare zum Ausdrucken (als PDF)
 - Eine Seite mit den aktuellsten News - die News bestehen aus Text und (optional) weiterführenden Links
 - Häufig am Fuß der einzelnen (textuellen) Inhalten: "Weiterführende Links", das sind Links (können intern oder extern sein) zu Seiten, auf denen man ähnliche bzw. weiterführende Infos findet - kannst du dir so vorstellen wie das "Weblinks"-Kapitel am Ende fast jedes Wikipedia-Artikels.
 - Ein paar Bilder sind auch zu finden; z.B. Fotos der einzelnen Mitarbeiter

*2 Visitenkarten (werden automatisch in die xHTML-Mitarbeiterseite eingefügt - halt um Info und [HTML]-Formatierung zu trennen)

Dazu gibt's sonst nicht mehr viel zu sagen: Daten wie Emailadresse, Fax und Tel werden halt nicht direkt in HTML auf den einzelnen Mitarbeiterseiten angeführt, sondern (ich weiß eben nicht, wohin am Besten, deshalb ja meine Frage) in Datenbank, XML oder ähnlichem gespeichert - eben als M des MVCs. Dann werden die Daten automatisch in das HTML der Seite eingegliedert, d.h. ansprechend präsentiert.
Dadurch will ich erreichen, dass ich die HTML-Präsentation und Emailadressen etc. unabhängig von einander ändern kann. Außerdem muss ich das HTML nicht in jeder Mitarbeiterseite extra "reinkopieren" und gegebenfalls bei Änderungen anpassen, sondern schreibe das HTML einmal. Das HTML wird halt mit richtiger Emailadresse etc. aufgefüllt und in die richtige Mitarbeiterseite eingebunden. Also mit einem (langen) Wort: Präsentation-Struktur-Trennung.

*3 Links
Welche Aufgabenstellung soll damit erfüllt werden?

Das sind die "weiterführenden Links", genaueres dazu habe ich schon weiter oben geschrieben. Jedenfalls können die wie die "Weblinks" am Ende von Wikipedia-Artikeln auch bei mir am Ende von einzelnen Seiten stehen, um auf weiterführende Infos zu referenzieren.

Wie ihr ja sicher schon bei *2 bemerkt habt, tu' ich mir schwer: Ich halte es für unmöglich bzw. schaffe es nicht ;-), M und V eines MVC - oder hMVC, wie's jetzt in Kohana3 heißt ;-) - richtig zu trennen - ich meine, in Prinzip ist doch jeder Text in einer Webseite eine Information, d.h. es würde dann folglich zumindest theoretisch in das M gehören

Handelt es sich um statischen Text für das Seitengerüst oder um Inhalte, die aus einer Datenhaltung geholt werden? Manche Texte können auch gleich im von der View verwendeten Template stehen. Das musst du mit Erfahrung und unter Beachtung der Aufgabenstellung abschätzen, was wohin gehört. Um diese Erfahrung zu sammeln, wirst du hauptsächlich aus deinen Fehlern und Erfolgen lernen müssen. Selbst wenn du anderswo etwas abschaust, das sich dort bewehrt hat, heißt das noch lange nicht, dass das auch auf deinen Fall zutrifft.

• anderseits muss ich ja den Text - gleich dort wo er gespeichert ist, sonst wird es unübersichtlich ;-) - formatieren (<b> [oder <strong> , wie es in "NeuHTMLisch" heißt ;-)], <p>), was meines Erachtens ein klarer V-Fall ist - also wohin damit?

Auch <b> ist mittlerweile wieder neuHTMLisch, aber sei's drum. Die Frage ist, ob es für dich zum Inhalt zählt oder zur Struktur.

Lasst mich flennen ;-)

Texte in einem CMS sind Inhalt und mitunter auf irgendeine Weise vorformatiert, vielleicht mit HTML-Elementen, vielleicht mit einer anderen Syntax (z.B. Wiki), die erst noch geparst und umgesetzt werden muss.

Bei mir ist die Wahl auf HTML gefallen, weil mein Admin das halt schon beherrscht und jetzt nicht groß eine neue Sprache lernen will.

Ich denke, das es wohl das Sinnvollste ist, Texte und andere menschenbestimmte semi- bis unstruktierten Daten in den View "auszulagern", weil die ja eh nur für die Präsentation (auch nur für Menschen) brauchbar sind, und nur strukturierten Einzug ins M zu gewähren. Was uns zur Frage bringt: Ab wann sind Daten strukturiert?

Egal ob strukturiert oder nicht, veränderliche Daten sind die, die man üblicherweise mit einem M abfragt.

Naja, alles ist veränderlich, ja auch die Präsentation, sogar die HTML-Tags in der Präsentation. Aber würdest du jetzt z.B. einen Lebenslauf (mit <b> und <i>, sonst Text) als V oder M ansehen. Allgemeiner gefragt, wo gehören alle die HTML-formatierten Texte hin, die es so massenhaft auf meiner Site gibt? Wenn das alles auch ins M kommt, bleibt ja aber für den V überhaupt nichts mehr. Allerdings werden ja vieler solcher Texte wie Lebenslauf und Publikationsangaben-Auflistungen häufig editiert - andere HTML-formatierte Texte wie Unternehmensprofil wieder weniger.

Dein Ziel hast du nicht beschrieben, du philosophierst gerade nur über den Weg.

Mein Ziel ist eine erweiterbare, durchdachte und vorallem leicht aktualisierbare Website.

lg.

PS: Sollten noch weitere Gegenfragen auftauchen, nur her damit. Danke für alle die sich die Mühe machen, sich mit meinem Problem zu befassen.

[dedlfix]

Hi!

Ich verlinke auf eine Seite einer Universität - MEHRFACH - von meiner Seite aus. Universitäten werden ja (zumindest in Österreich) ständig umstrukturiert, somit kann es schnell sein, dass ein Institut zu einer Abteilung wird => Seite hat eine neue URI. Jetzt geht's ans Überarbeiten aller href-Attribute - Freude kommt auf :-)
Jetzt will ich nur so etwas wie <a xmlns:extern="http://www.example.com/" href="extern:unigraz"></a> (http://www.example.com/ [...] wäre in diesem Beispiel der Namensraum für CURIEs für externe Sites) schreiben, an einer zentralen Stelle wäre dann aufgelistet, welche CURIE für welche URL eines externen Links steht. So ähnlich würde ich das dann auch mit den internen Links machen.

Einfach gesagt willst du also im Text einen Platzhalter und an anderer Stelle eine Datenhaltung, aus der die URL entnommen werden kann und die, wenn notwendig, mit einem Handgriff zu ändern geht. Klingt sinnvoll und auch das Aufwand-Nutzen-Verhältnis scheint mir dafürzusprechen.

* Die meisten Inhalte der Seite sind textuell (also normales HTML), sonst gibt's noch:

Allein dafür wäre die Verwendung eines ausgewachsenen MVC-Frameworks nicht unbedingt notwendig. Aber dann kommen noch deine anderen Anforderungen dazu, die nicht nur aus Daten ein paar Frontend-Seiten produzieren, sondern auch das Backend, um diese Daten zu verwalten. Und dann kommt eine Aufgabe zur anderen hinzu und eine Strukturierung des Programmcodes wird immer sinnvoller. Zumindest ein Template-System wird sich deutlich abheben und die View-Komponente bilden. M und C kann man (wenn man unter anderem keinen großen Wert auf automatische Testbarkeit legt) zur Not zusammenlegen, wenn man zumindest eine Datenbankabstraktion hat, die die grundlegenden RUDI-Operationen für einen einfachen Zugriff kapselt, so dass man nicht immer Statement formulieren, Prepare, Datenbindung, Execute und Fetch zu Fuß ausführen muss.

*2 Visitenkarten (werden automatisch in die xHTML-Mitarbeiterseite eingefügt - halt um Info und [HTML]-Formatierung zu trennen)
Dazu gibt's sonst nicht mehr viel zu sagen: Daten wie Emailadresse, Fax und Tel werden halt nicht direkt in HTML auf den einzelnen Mitarbeiterseiten angeführt, sondern (ich weiß eben nicht, wohin am Besten, deshalb ja meine Frage) in Datenbank, XML oder ähnlichem gespeichert -

Datenbank ist wohl das beste. XML ist eher ein Austauschformat und weniger für ständige Änderungen geeignet.

eben als M des MVCs. Dann werden die Daten automatisch in das HTML der Seite eingegliedert, d.h. ansprechend präsentiert.

Das M ist nicht die Datenhaltung selbst sondern das Holen und Wegschreiben der Daten aus der und in die Datenhaltung (inklusive Ansprechen von externen Quellen (RSS-Feeds) und Senken (APIs irgendwelcher Dienste)).

Also mit einem (langen) Wort: Präsentation-Struktur-Trennung.

Ist sinnvoll, wird man aber auch ohne den Einsatz eines MVC-Frameworks auf ähnliche Weise trennen.

*3 Links
Welche Aufgabenstellung soll damit erfüllt werden?
Das sind die "weiterführenden Links", genaueres dazu habe ich schon weiter oben geschrieben. Jedenfalls können die wie die "Weblinks" am Ende von Wikipedia-Artikeln auch bei mir am Ende von einzelnen Seiten stehen, um auf weiterführende Infos zu referenzieren.

Also einfach nur eine weitere Sammlung von Daten, die auf Platzhalter oder nach festen Regeln in einige der Seiten eingefügt werden sollen.

Texte in einem CMS sind Inhalt und mitunter auf irgendeine Weise vorformatiert, vielleicht mit HTML-Elementen, vielleicht mit einer anderen Syntax (z.B. Wiki), die erst noch geparst und umgesetzt werden muss.
Bei mir ist die Wahl auf HTML gefallen, weil mein Admin das halt schon beherrscht und jetzt nicht groß eine neue Sprache lernen will.

Hier ist besondere Aufmerksamkeit auch seitens des Bearbeiters gefragt, denn es darf durch seine selbst eingefügten Code-Teile zu keinem Syntaxfehler kommen. Du kannst am Ende nur bei den dann noch einzufügenden Daten selbst den Kontextwechsel beachten. Wenn er jedoch irgendwo ein Element offen lässt, dem ein Platzhalter folgt, ist man mit den einzufügenden Daten bereits im Anweisungsmodus und kann auch ohne HTML-eigenen Zeichen zu verwenden, die ja maskiert werden würden, in gewissen Grenzen Code einfügen.

Ich denke, das es wohl das Sinnvollste ist, Texte und andere menschenbestimmte semi- bis unstruktierten Daten in den View "auszulagern", weil die ja eh nur für die Präsentation (auch nur für Menschen) brauchbar sind, und nur strukturierten Einzug ins M zu gewähren. Was uns zur Frage bringt: Ab wann sind Daten strukturiert?
Egal ob strukturiert oder nicht, veränderliche Daten sind die, die man üblicherweise mit einem M abfragt.
Naja, alles ist veränderlich, ja auch die Präsentation, sogar die HTML-Tags in der Präsentation.

Das Template ändert üblicherweise ein Techniker und das relativ selten. Die einzufügenden Daten werden ständig und von 0815-Mitarbeitern gepflegt. Deswegen kann man das Template getrost zum feststehenden Teil zählen.

Aber würdest du jetzt z.B. einen Lebenslauf (mit <b> und <i>, sonst Text) als V oder M ansehen.

Das ist Inhalt, also Datenhaltung. Das M kommt ins Spiel, um auf die Daten zuzugreifen. Wenn man das gesamte System nur in M, V und C einteilen will, sind die Daten Bestandteil des Ms, aber genauer hingesehen würde ich das M auch wieder trennen und in ihm nur den Zugriff sehen, die eigentliche Ablage ist ein eigenständiges System.

Allgemeiner gefragt, wo gehören alle die HTML-formatierten Texte hin, die es so massenhaft auf meiner Site gibt? Wenn das alles auch ins M kommt, bleibt ja aber für den V überhaupt nichts mehr.

Die Trennung ist nicht sinnvoll in HTML-Text und explizit als Daten zu erkennende Teile vorzunehmen. Genauso, wie der Datenpfleger am Programmcode keine Änderungen vornehmen kann, trennte ich das vielmehr nach vom Techniker änderbaren Templates der Seitengerüste (quasi wie Code anzusehen) und den eigentlichen Inhalten.

Allerdings werden ja vieler solcher Texte wie Lebenslauf und Publikationsangaben-Auflistungen häufig editiert - andere HTML-formatierte Texte wie Unternehmensprofil wieder weniger.

Die Häufigkeit ist nicht das Kriterium sondern eher wer es sinnvollerweise machen kann/soll - technisches Personal oder Mitarbeiter der fachlichen Abteilungen.

Dein Ziel hast du nicht beschrieben, du philosophierst gerade nur über den Weg.
Mein Ziel ist eine erweiterbare, durchdachte und vorallem leicht aktualisierbare Website.

Das ist noch zu allgemein formuliert, denn das wollen fast alle, die eine Website erstellen. Wichtig sind die Punkte, die eine besondere Behandlung seitens des Systems erfordern, wie beispielsweise: Mitarbeiter soll in einem Kalender Termine pflegen. Diese Anforderungen formulierst du am besten aus der Sicht der Anwender und nicht nur deine Gedanken zur technischen Umsetzung. Denn aus Letzterer kann man nicht unbedingt entnehmen, was der Mitarbeiter eigentlich will, denn das kann möglicherweise mit einer anderen technischen Lösung besser realisiert werden. Nur mit Kenntnis der Anwenderanforderung kann man deine technischen Überlegungen richtig bewerten. - Durch deine anderen Ausführungen sind jedenfalls die Haupt- und Nebenziele schon deutlicher geworden.

Lo!

[[MuhTuhls.}]

hi,

Allein dafür wäre die Verwendung eines ausgewachsenen MVC-Frameworks nicht unbedingt notwendig.

Da du überlegst, ob ein MVC-Framework "unbedingt notwendig" ist: Gebe es denn irgendetwas, dass gegen einen Framework sprechen würde?

Datenbank ist wohl das beste. XML ist eher ein Austauschformat und weniger für ständige Änderungen geeignet.

Aber wäre denn folgendes sinnvoll?:
Alle Daten werden von Adminstrator in Form von XML-Dateien verwaltet, d.h. es werden Teile gelöscht, hinzugefügt und eingefügt. Danach spielt der Admin alle geänderten Daten via FTP aus den Server. Zusätzlich kopiert er noch eine Datei rüber, an der der mein System erkennen kann, dass die Datenbank aktualisiert werden muss. Beim nächsten Aufruf meiner Seite erfolgt die besagte Datenbankaktualisierung, d.h. alle Informationen aus den XML-Dateien werden nun in die Datenbank eingetragen. Alle weiteren Zugriffe auf die Informationen erfolgen via Datenbank bzw. die XML-Dateien werden am dann nicht mehr beachtet.

Bei mir ist die Wahl auf HTML gefallen, weil mein Admin das halt schon beherrscht und jetzt nicht groß eine neue Sprache lernen will.
Hier ist besondere Aufmerksamkeit auch seitens des Bearbeiters gefragt, denn es darf durch seine selbst eingefügten Code-Teile zu keinem Syntaxfehler kommen. Du kannst am Ende nur bei den dann noch einzufügenden Daten selbst den Kontextwechsel beachten. Wenn er jedoch irgendwo ein Element offen lässt, dem ein Platzhalter folgt, ist man mit den einzufügenden Daten bereits im Anweisungsmodus und kann auch ohne HTML-eigenen Zeichen zu verwenden, die ja maskiert werden würden, in gewissen Grenzen Code einfügen.

Das mit dem offenen Element in Kombination mit einem "Platzhalter" verstehen ich nicht vollständig. Nur um ein mögliches Verständnisproblem aus dem Weg zu räumen: Ich verwende keine klassischen Platzhalter im Sinne von <div><!--{{TEXT.LINKLISTE}}--></div> oder Smarty(artiges), sondern normalen - eben für die Darstellung bestimmten - PHP-Code, wie von Kohana vorgesehen.

Das ist Inhalt, also Datenhaltung. Das M kommt ins Spiel, um auf die Daten zuzugreifen. Wenn man das gesamte System nur in M, V und C einteilen will, sind die Daten Bestandteil des Ms, aber genauer hingesehen würde ich das M auch wieder trennen und in ihm nur den Zugriff sehen, die eigentliche Ablage ist ein eigenständiges System.

Würdest du hier den Lebenslauf als eigenes "Inhaltselement" sehen oder würdest du es in eine Mitarbeiterseite eingliedern? Ich gehe davon aus, dass du die ganze Mitarbeiter-Seite zur "Datenhaltung" zählen würdest.

Allerdings werden ja vieler solcher Texte wie Lebenslauf und Publikationsangaben-Auflistungen häufig editiert - andere HTML-formatierte Texte wie Unternehmensprofil wieder weniger.
Die Häufigkeit ist nicht das Kriterium sondern eher wer es sinnvollerweise machen kann/soll - technisches Personal oder Mitarbeiter der fachlichen Abteilungen.

In beiden Fällen der "fachliche Mitarbeiter".

[...] Wichtig sind die Punkte, die eine besondere Behandlung seitens des Systems erfordern [...]

Naja, prinzipiell werden alle Inhalte vom in diesem Thread bereits berühmt-berüchtigten Admin mit HTML-Kenntnissen gepflegt. Eine Ausnahme dazu stellen die Mitarbeiterseiten und die Newsseite dar. Die Mitarbeiter sollen über eine graphische Oberfläche folgendes tun können:

• Termine hinzufügen/entfernen
• Publikationen hinzufügen/entfernen
• Lebenslauf erweitern/editieren
• News erstellen/(die eigenen News) editieren
  Die News werden allerdings nicht direkt auf der Mitarbeiterseite angezeigt, sondern auf einer eigenen Newsseite (gleichzeitig auch unsere Startseite). Außerdem: Auch wenn nur z.B. ein Termin hinzugefügt wird, wird dazu automatisch eine News auf der Startseite gezeigt, nach dem Motto "Mitarbeiter XY hat YZ hinzugefügt."

Danke für deine Hilfe.
lg MuhTuhls.

[dedlfix]

Hi!

Allein dafür wäre die Verwendung eines ausgewachsenen MVC-Frameworks nicht unbedingt notwendig.
Da du überlegst, ob ein MVC-Framework "unbedingt notwendig" ist: Gebe es denn irgendetwas, dass gegen einen Framework sprechen würde?

Natürlich, wenn Aufwand und Nutzen in einem ungünstigen Verhältnis stehen. So ein Framework ist zwar üblicherweise so flexibel, dass alle Teile einzeln getauscht werden können. Wenn dir der Router nicht zusagt, nimmst du einen anderen. Wenn du nur etwas Funktionalität hinzufügen willst, kannst du ein Plugin ankoppeln. Zum Beispiel diese Pluginverwaltung, die ja bei jedem Scriptaufruf zumindest ermitteln muss, ob Plugins auszuführen sind, kostet ein wenig Zeit. Und so läppert sich eins zum anderen. Für die Wartung ist das zwar alles schön strukturiert, aber auf Kosten der Performance. Du kannst am Ende nur weniger Requests bearbeiten als mit einem Geradeaus-Script ohne optionale Wenns und Abers.

Du willst jedoch unbedingt ein Framework kennenlernen - also mach das! Der Nutzen ist dann auch der Lerneffekt.

Datenbank ist wohl das beste. XML ist eher ein Austauschformat und weniger für ständige Änderungen geeignet.
Aber wäre denn folgendes sinnvoll?:
Alle Daten werden von Adminstrator in Form von XML-Dateien verwaltet, d.h. es werden Teile gelöscht, hinzugefügt und eingefügt. Danach spielt der Admin alle geänderten Daten via FTP aus den Server. Zusätzlich kopiert er noch eine Datei rüber, an der der mein System erkennen kann, dass die Datenbank aktualisiert werden muss. Beim nächsten Aufruf meiner Seite erfolgt die besagte Datenbankaktualisierung, d.h. alle Informationen aus den XML-Dateien werden nun in die Datenbank eingetragen. Alle weiteren Zugriffe auf die Informationen erfolgen via Datenbank bzw. die XML-Dateien werden am dann nicht mehr beachtet.

Denkbar ist das. Wie genau stellst du dir die Datenbankaktualisierung vor? Du brauchst dazu Insert- und Update-Elemente in deiner XML. Und um diese aus deinem lokalen Datenbestand zu ermitteln, benötigst du eine Kennzeichnung der Änderungen, die du beim Erstellen der XML-Datei zurücksetzen musst. Das ist aufwendig und mit einem Dump wesentlich einfacher zu regeln, wenn du in beiden Systemen immer die gleichen Daten hast (sogar für einzelnen Tabellen, wenn du nicht gerade referenzeielle Integrität vom DBMS überwachen lässt). Du wirst im CMS ja nicht gerade mehr als eine Handvoll MB verwalten.

Die Aktualisierung sollte der Administrator einspielen, denn sonst hast du bei jedem Scriptaufruf eine Prüfung auf zu erledigende Änderungen. Das kostet und wenn was schief lief, bekommt es keiner mit, bis sich ein Besucher beschweren kommt.

[Bei HTML im Content] ist besondere Aufmerksamkeit auch seitens des Bearbeiters gefragt, denn es darf durch seine selbst eingefügten Code-Teile zu keinem Syntaxfehler kommen. [...] Wenn er jedoch irgendwo ein Element offen lässt, dem ein Platzhalter folgt, ist man mit den einzufügenden Daten bereits im Anweisungsmodus und kann auch ohne HTML-eigenen Zeichen zu verwenden, die ja maskiert werden würden, in gewissen Grenzen Code einfügen.
Das mit dem offenen Element in Kombination mit einem "Platzhalter" verstehen ich nicht vollständig. Nur um ein mögliches Verständnisproblem aus dem Weg zu räumen: Ich verwende keine klassischen Platzhalter im Sinne von <div><!--{{TEXT.LINKLISTE}}--></div> oder Smarty(artiges), sondern normalen - eben für die Darstellung bestimmten - PHP-Code, wie von Kohana vorgesehen.

Dann ist immer noch HTML/CSS/JS-Injection möglich, egal ob da PHP-Code die Daten einfügt oder Platzhalter ersetzt werden. Beispiel: Der Admin vergisst ein <div class="foo" zu schließen, und danach sollen Daten eingefügt werden. Dann können Daten, die aussehen wie attribut=wert, im Code-Teil statt im <div class="foo">Inhaltsbereich</div> landen. HTML-eigene Zeichen <>&" würden durch dein htmlspecialchars() behandelt. Wenn du vergisst, dabei ENT_QUOTES zu setzen, stehen dem Ausnutzer wenigstens noch die '' zur Verfügung und er kann Attributwerte besser abgrenzen.

Würdest du hier den Lebenslauf als eigenes "Inhaltselement" sehen oder würdest du es in eine Mitarbeiterseite eingliedern? Ich gehe davon aus, dass du die ganze Mitarbeiter-Seite zur "Datenhaltung" zählen würdest.

Definiere "ganze Seite". Du meinst sicher den Teil ohne das allgemeine Gerüst oder kann jeder Mitarbeiter komplett eigengestaltete Seiten haben?

Allerdings werden ja vieler solcher Texte wie Lebenslauf und Publikationsangaben-Auflistungen häufig editiert - andere HTML-formatierte Texte wie Unternehmensprofil wieder weniger.
Die Häufigkeit ist nicht das Kriterium sondern eher wer es sinnvollerweise machen kann/soll - technisches Personal oder Mitarbeiter der fachlichen Abteilungen.
In beiden Fällen der "fachliche Mitarbeiter".

Ja, aber im Gegensatz dazu wird das Seitengerüst wohl eher vom technischen Personal betreut. Das ist dann Template-Datei und kein Content wie die obigen Beispiel.

Lo!

[[MuhTuhls.}]

hi,

Alle Daten werden von Adminstrator in [...] XML-Dateien verwaltet.
[...] Das ist [...] mit einem Dump wesentlich einfacher zu regeln [...]

Was verstehst du unter einem "Dump"? Ich kenne Dumps nur als SQL-Dateien zu Datensicherungszwecken - meinst du was in der Art?

Die Aktualisierung sollte der Administrator einspielen, denn sonst hast du bei jedem Scriptaufruf eine Prüfung auf zu erledigende Änderungen. Das kostet und wenn was schief lief, bekommt es keiner mit, bis sich ein Besucher beschweren kommt.

Du meist, der Admin solle nach dem Seiten-Upload ein PHP-Script ausführen, dass alle Änderungen übernimmt.

Ich verwende [...] Platzhalter im Sinne von [...] PHP-Code [...].
Dann ist [...] HTML/CSS/JS-Injection möglich.

Allerdings wird meine Seite die Administratoren-Eingaben 1. validieren und 2. wird für alle Seiten, an denen der Admin "herumarbeiten" darf, kein Zusatzcode aus Benutzereingaben generiert.

[...] Du meinst sicher den Teil ohne das allgemeine Gerüst [...]

Ich spreche nur von den von uns erstellten Mitarbeiterseiten. Und dort meine ich den "Teil ohne Gerüst".

[...] kann jeder Mitarbeiter komplett eigengestaltete Seiten haben?

Ein Mitarbeiter kann wählen: Entweder er erstellt sich seine Seite komplett selber und wir verlinken sie von der Unternehmensseite aus oder wir erstellen eine Seite, die er über eine graphische Oberfläche editieren kann. (War nicht meine Idee.)

lgMuhTools.

[dedlfix]

Hi!

Alle Daten werden von Adminstrator in [...] XML-Dateien verwaltet.
[...] Das ist [...] mit einem Dump wesentlich einfacher zu regeln [...]
Was verstehst du unter einem "Dump"? Ich kenne Dumps nur als SQL-Dateien zu Datensicherungszwecken - meinst du was in der Art?

Genau das. Auf dem Entwurfssystem den Dump erstellen und in das Produktivsystem nach einem Tabellenleeren einspielen.

Die Aktualisierung sollte der Administrator einspielen, denn sonst hast du bei jedem Scriptaufruf eine Prüfung auf zu erledigende Änderungen. Das kostet und wenn was schief lief, bekommt es keiner mit, bis sich ein Besucher beschweren kommt.
Du meist, der Admin solle nach dem Seiten-Upload ein PHP-Script ausführen, dass alle Änderungen übernimmt.

Ja, schon aus Qualitätssicherungsgründen. Er muss ja sichergehen, dass die Änderungen korrekt übernommen wurden.

[...] kann jeder Mitarbeiter komplett eigengestaltete Seiten haben?
Ein Mitarbeiter kann wählen: Entweder er erstellt sich seine Seite komplett selber und wir verlinken sie von der Unternehmensseite aus [...]

Wenn ihr sie auch hostet und sie dafür in eurem CMS haben wollt, dann ist sie komplett Inhalt. Extern gehostet wäre es ja egal.

Lo!

[[MuhTuhls.}]

hi,
sry, dass ich erst jetzt antworte. Mein NoteBook ist ma im Urlaub eingegangen; somit hatte ich erst jetzt nach meinem Urlaub wieder Internetzugang.

[...] Auf dem Entwurfssystem den Dump erstellen und in das Produktivsystem nach einem Tabellenleeren einspielen.

muss dann aber dann der Administrator die Tabellen- bzw. Datenbankstruktur kennen - oder habe ich deine Dumpidee falsch verstanden? Und eine normalisierte Datenbank händisch zu aktualisieren ist - gerade für Leute, die die Arbeit mit Datenbanken nicht gewöhnt sind - immer schwierig.

Um ein mögliches Missverständnis zu beseitigen: In meiner XML-Datei sollen keine Informationen hinterlegt werden, die besagen, welche Daten gelöscht, hinzugefügt oder upgedatet werden sollen - kein xUpdate oder derartiges. Viel mehr sollen dort alle Daten aufgelistet werden. Das System vergleicht die Version der Daten aus der XML-Datei mit der Datenbank-Version der Daten. Es entscheidet dann selbst, ob Daten gelöscht, hinzugefügt oder upgedatet werden sollen.

Meiner Meinung nach hat XML gegenüber von Datenbanktabellen den Vorteil, dass die Daten in keine so harte Struktur gezwungen werden (muss). Wofür ich in Datenbanken X Tabellen brauche, kann ich in XML meist mit nur ein paar (verschachtelten) Elementen lösen. Außerdem kann ich XML-Dateien ganz einfach via Editor editieren. Oder bringt XML in diesem Anwendungsgebiet irgendwelche starken Nachteile mit sich?

Du hast mir bisher schon sehr weiter geholfen, danke!

lg[MuhTuhls.}

[dedlfix]

Hi!

[...] Auf dem Entwurfssystem den Dump erstellen und in das Produktivsystem nach einem Tabellenleeren einspielen.
muss dann aber dann der Administrator die Tabellen- bzw. Datenbankstruktur kennen - oder habe ich deine Dumpidee falsch verstanden? Und eine normalisierte Datenbank händisch zu aktualisieren ist - gerade für Leute, die die Arbeit mit Datenbanken nicht gewöhnt sind - immer schwierig.

Der Admin muss nicht zwangsläufig die DB-Interna kennen, wenn der Programmierer ihm ein Werkzeug liefert. Komfortabelerweise reicht ein Klick und das Programm fragt die Daten des Entwurfssystems ab und spielt sie in das Produktivsystem. Wenn das im Ganzen und nicht als Delta passiert ist das quasi wie ein Dump anzusehen. Auch zu Fuß muss der Admin nichts kennen, denn es gibt Dump-Werkzeuge für Kommandozeile oder auch im phpMyAdmin und ähnlichen Oberflächen. Einmal den Vorgang beschreiben, der die gesamte Datenbank (nicht das gesamte DBMS sondern nur die eine mit den CMS-Daten) dumpt (inklusive Struktur und DROP TABLE) und wie man dieses File am Zielsystem einliest.

Um ein mögliches Missverständnis zu beseitigen: In meiner XML-Datei sollen keine Informationen hinterlegt werden, die besagen, welche Daten gelöscht, hinzugefügt oder upgedatet werden sollen - kein xUpdate oder derartiges. Viel mehr sollen dort alle Daten aufgelistet werden. Das System vergleicht die Version der Daten aus der XML-Datei mit der Datenbank-Version der Daten. Es entscheidet dann selbst, ob Daten gelöscht, hinzugefügt oder upgedatet werden sollen.

Je mehr Daten desto aufwendiger wird der Vorgang gegenüber einem extra gepflegtem Delta.

Meiner Meinung nach hat XML gegenüber von Datenbanktabellen den Vorteil, dass die Daten in keine so harte Struktur gezwungen werden (muss). Wofür ich in Datenbanken X Tabellen brauche, kann ich in XML meist mit nur ein paar (verschachtelten) Elementen lösen. Außerdem kann ich XML-Dateien ganz einfach via Editor editieren. Oder bringt XML in diesem Anwendungsgebiet irgendwelche starken Nachteile mit sich?

Für ein CMS, das alle paar Tage mal die Daten ändert, mag XML aus Datenpflege-Sicht ausreichend sein. Aber bei Requests ständig die gesamte XML-Datei einlesen zu müssen, damit man an die gewünschten paar Daten gelangt, ist aufwendiger als gezielt etwas vom DBMS suchen zu lassen, das einige Optimierungen wie Index mitbringt. Alternativ ginge auch noch ein NoSQL-DBMS, das üblicherweise Dinge speichert, ohne sich großartig für die Struktur zu interessieren. Wenn du dich darüber informierst, achte mal darauf, wie in einer unstrukturierten Datensammlung gezielt gesucht werden kann. Meist muss man da ein eigenes Script mitliefern, das der Suchprozess auf jeden Eintrag anwendet.

Lo!

[[MuhTuhls.}]

hi,

Wenn das im Ganzen und nicht als Delta passiert ist das quasi wie ein Dump anzusehen.

Pardon, was versteht man unter "Delta"?

[...] In meiner XML-Datei sollen [...] alle Daten aufgelistet werden. [...]
Je mehr Daten desto aufwendiger wird der Vorgang gegenüber einem extra gepflegtem Delta.

Sry.

[...] bei Requests ständig die gesamte XML-Datei einlesen zu müssen [...] ist aufwendig[...]

Naja, mein Plan wäre auch gewesen, die Daten aus XML einmalig nach jeder Aktualisierung (wahrscheinlich in eine Datenbank) zu übertragen und dann nur noch mit dieser Version der Daten zu arbeiten.

[...] Alternativ ginge auch noch ein NoSQL-DBMS[...]

An NoSQL habe ich auch schon gedacht. Ich werde mich damit mal genauer beschäftigen, bis jetzt hab ich nur in ein paar Blogs von NoSQL und CouchDB gelesen. Ich druck mir jetzt ma gleich was dazu aus.

lg[MuhTuhls.}\

[dedlfix]

Hi!

Wenn das im Ganzen und nicht als Delta passiert ist das quasi wie ein Dump anzusehen.
Pardon, was versteht man unter "Delta"?

Das ist eine Flussmündung. Nein, falscher Kontext. Ein Delta ist der Unterschied zwischen zwei Zuständen. In dem Fall steht drin, welche Datensätze hinzukommen, welche gelöscht werden sollen und welche sich inhaltlich ändern.

[...] bei Requests ständig die gesamte XML-Datei einlesen zu müssen [...] ist aufwendig[...]
Naja, mein Plan wäre auch gewesen, die Daten aus XML einmalig nach jeder Aktualisierung (wahrscheinlich in eine Datenbank) zu übertragen und dann nur noch mit dieser Version der Daten zu arbeiten.

Achja, das erwähntest du ja schon. Die Frage ist, warum du da den Weg über XML gehen willst? Stattdessen kannst du auch die SQL-Statements erzeugen, die den neuen Datenbestand entweder komplett oder als Delta in das Produktivsystem einpflegen. Das ist auf der einen Seite ein ungefähr gleicher Aufwand zur XML-Lösung aber auf der anderen ein deutlich geringerer.

Lo!

[[MuhTuhls.}]

hi,

[...] Ein Delta ist der Unterschied zwischen zwei Zuständen. [...]

Thx - man lernt eben daily dazu.

[...] warum du da den Weg über XML gehen willst? [...]

Stelle dir folgendes Szenario vor: Ich habe eine Personendatenbank. Zu jeder Person wird gespeichert:

• Vorname
• Nachname
• Namen der Haustiere
  Um diese Daten normalisiert in einer relationale Datenbank zu speichern, würde ich wie folgt vorgehen:
• Tabelle "Person"
• • Schlüssel "Person"
• • Spalte "Vorname"
• • Spalte "Zuname"
• Tabelle "Haustier"
• • Schlüssel "Haustier"
• • Spalte "Name"
• Tabelle "Haustiere_Besitzer"
• • Schlüssel "Haustiere_Besitzer"
• • Spalte "Tier"
• • Spalte "Person"
    Das ist noch ein relativ kleines Beispiel. Und trotzdem ist es nicht gerade einfach, die Datenbank hündisch (d.h. via SQL) zu aktualisieren.

In XML lässt sich das Ganze denk ich recht einfach darstellen - soartig halt (xmlns' habe ich der Einfachkeit halber weggelassen - xi=xInclude):

  
<root>  
  <person vorname="Homer" zuname="Simpson">  
    <haustier name="Ruprecht" xml:id="r12" />  
  </person>  
  <person vorname="Marge" zuname="Simpson">  
    <xi:include xpointer="r12">  
  </person>  
</root>  

Natürlich könnte man ein schöneres Format designen. Trotzdem: Gerade, da die Webseite dem Anspruch "einfach wartbar" gerecht werden sollte, denke ich, XML ist die richtige Lösung. Oder was meinst du?

Sollte ich mich schlussendlich wirklich für XML entscheiden, hab ich mir gedacht, ich könnte doch die Daten gleich in einer XMLDBMS speichern und komplett auf MySQL bzw. andere RDBMS' verzichten. Somit könnte ich die Vorteile einer Datenbank wie einfache Durchsuchbarkeit und bessere Performance als bei einfachem Dateihandling nutzen und müsste meine XML-Daten nicht extra in das relativ strikte relationale Format pressen bzw. umwandeln. Good idea?

Danke, dass du mich auf NoSQL gebracht hast. Sonst wäre ich vielleicht garnicht auf die XMLDBMS-Idee gekommen.

lg[MuhTuhls.}\