nicht angemeldet
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!