[Berti]

Hallo ich habe mittlerweile alle Tutorials zur Erstellung von CMSen durchgelsen und rumprobiert.

Ich habe jetzt die ersten Grundfunktionen meines CMS fertig. Was sind denn die besten Möglichkeiten um Module (Gästebuch, Kontaktformular, etc) einzubinden? Bei manchen CMSen geht es über die URL (Joomla!) und bei anderen wird es im Content der Datenbankinhalte eingebunden (contentNow).

Was ist denn da die beste Möglichkeit und wo gibts evtl. einen Tutorial dazu?

[dr.e.]

Hallo Berti,

ich pflege das über Tags innerhalb des Contents zu regeln, denn da hab ich

a) die Kontrolle darüber, wo genau das Modul platziert wird (bzw. der
Redakteur)
b) eine einheitliche Parser-Struktur für alle Seiten

Was ist denn da die beste Möglichkeit und wo gibts evtl. einen Tutorial dazu?

An sich ist das kein großes Hexenwerk. Du musst ein Modul erstellen, das dir den Inhalt aus einem File / einer Datenbank ausliest und den Inhalt einer Seite interpretiert. Wichtig ist dabei vor Allem, dass man definiert, wie die Tags gefunden und mit Inhalten des Moduls gefüllt werden. Im Endeffekt ist das aber nur eine Kombination aus strpos() und str_replace(), bzw. preg_replace(), falls man mit generischen Parametern eines Tags arbeitet. Wenn du Quelltext sehen möchtest sag Bescheid, dann schicke ich dir meinen CMSContentParser. Anregungen zu einem GUI-Modell einer Applikation und zu Modulen findest du auf der Seite in meiner Fußnote.

[Basti]

Hi "Berti".

Sag uns doch erstmal, was genau die Anforderungen sind. Es gibt viele Wege, sowas umzusetzen. Den Weg, den Christian vorschlägt, benutze ich, wenn es darum geht, Bilder, Audio- oder Video-Player in einen Text einzubinden (ist noch in Arbeit).

Für andere Module bzw. Einsatzbereiche taugt mir das nicht, denn Autoren sollen Inhalte schrieben können, dürfen jedoch nichts an den Vorgaben ändern, welche Module wie eingebunden werden sollen. Hier definiere ich für jeden Seitentyp, welche Module mit welchen Optionen in welcher Reihenfolge in welche Container gepackt werden.

Vielleicht reicht es auch, ein Modul je Seite einzubinden. Dann notierst du einfach je Seite das Modul in der Datenbank.

Die Info, welches Modul oder welche Module auf einer Seite eingebunden werden, haben jedoch bei all diesen Wegen nie etwas im URL verloren. Der URL zeigt auf bestimmte Inhalte. Die Info, mit welchen Technologien diese Inhalte zusammengestellt werden hab da nichts verlogen, denn diese können sich ja ändern.

Basti

[dr.e.]

@Basti:

Für andere Module bzw. Einsatzbereiche taugt mir das nicht, denn Autoren sollen Inhalte schrieben können, dürfen jedoch nichts an den Vorgaben ändern, welche Module wie eingebunden werden sollen.

Das lasse ich auch nicht zu, die Module konfiguriere ich zuvor und stelle dem Redakteur nur eine Liste von Modulen zur Verfügung, die er dann einbinden kann. Er kann lediglich sagen, welche Bildergalerie er anzeigen lassen möchte, konfigurieren, wie diesea ngezeigt wird kann er jedoch nicht.

[Berti]

Hallo also ich habe es jetzt wie folgt gelöst:

Ich habe eine Tabelle `content` in der ich für jede Seite, die Inhalte speichern kann. In dieser Tabelle kann ich ebenfalls definieren, welchen Inhaltstyp ich für jeden Datensatz haben will (Normaler Text oder eben ein Modul). Wenn ich ein Modul als Inhaltstyp haben will, dann gebe ich hier die Modul-ID an, die ich aus einer weiteren Tabelle entnehme, in der alle Module hinterlegt werden. So kann ich die Module dort positionieren, wo ich sie haben will und den Redakteuren nur eine gewisse Handlsungfreiheit lassen!

[Basti]

Zitat von dr.e.

@Basti:

Das lasse ich auch nicht zu, die Module konfiguriere ich zuvor und stelle dem Redakteur nur eine Liste von Modulen zur Verfügung, die er dann einbinden kann. Er kann lediglich sagen, welche Bildergalerie er anzeigen lassen möchte, konfigurieren, wie diesea ngezeigt wird kann er jedoch nicht.

Dann hab ich dein Konzept noch nicht verstanden. Du schreibst doch, dass die Module durch Tags im "Content" definiert werden. Dann doch von den Autoren und nicht von den Redakteuren, oder? Und wie kannst du nun definieren, dass ein bestimmtes Modul immer eingebunden sein und z.B. immer am Fuß der Seite angezeigt werden muss?

Basti

[Berti]

Das habe ich auch so. Ich habe einen bestimmten bereich auf der Website den die Redakteure bearbeiten können. Das außenherum kann nur ich bearbeiten!

[dr.e.]

Hallo Basti,

vielleicht habe ich mich etwas unglücklich ausgedrückt. Das Konzept ist, dass es einen editierbaren Bereich / mehrere editierbare Bereiche gibt und in diesem / diesen können Redakteure Content pflegen und per Tags ihnen vorkonfigurierte Anwendungen einblenden (Gästebuch, Kommentar-Funktion, ...). Feste Bereiche kann nur ich, bzw. der Entwickler beeinflussen. Die Einbindung der Module passiert dabei auf zwei unterschiedliche Arten:

- Der Redakteur binden ein Modul per "Pseudo-Tag" ein (z.B. "[Guestbook
No=123]"). Dieses wird vom CMSContentParser geparst und an der Stelle
wird der Objektbaum mit einem weiteren Element, nämlich dem Knoten des
Moduls Gästebuch erweitert.
- Die festen Module werden mit der üblichen "<core:importdesign
/>"-Anweisung eingebunden und bilden einen Teilbereich der GUI, die vom
Redakteur nicht beeinflusst werden kann.

Sollte es noch immer nicht klar geworden sein, kann ich auch ein bischen Code posten.

[Basti]

Das heißt, die Autoren können nichts selbst einbinden, sondern nur die Redakteure. Und du kannst als Administrator festlegen, welche Tags die Redakteure zur Verfügung haben. Ich verstehe noch nicht so ganz, wie die Redakteure ihre Daten dann eingeben. Haben die auch ein Textfeld so wie die Autoren? Und können die dann dort fixen Text eingeben, den die Autoren nicht editieren dürfen? Trifft diese "Zwischenschicht" wirklich gängige Anforderungen?

Also bei mir stellen die Site-Verwalter alles ein, was die Autoren eingeben dürfen (welche Module sie benutzen können) und … wenn die Workflows dann in ein paar Wochen drinnen sein werden, werden die Redakteure ausschließlich den Job haben, sich den Mist der Autoren anzuschauen und abzusegnen oder mit einer entsprechenden Meldung erstmal abzuweisen. Um bestimmte Vorlagen anzubieten bzw. Vorgaben geben zu können, gibt es eben die Definition von Seitentypen, aber das ist in meinen Augen ein Werkzeug, dass besser in die Hände der Verwaltung als in die Hände der Redakteure passt, oder?

Braucht der Redakteur die Möglichkeit, dem Autor strukturelle Vorgaben machen zu können, die über die Vorgaben der Ebene darüber hinausgehen? Und warum reicht es dann dort nicht, einfach eine Reihenfolge der zulässigen Module anzugeben, sondern muss das in [hier kannst du ein Bild reinsetzen] einen Text eingebettet [hier kannst du einen Text reinsetzen] werden?

Den Text schreiben doch die Autoren, nicht die Redakteure.

Basti

[dr.e.]

Hallo Basti,

Den Text schreiben doch die Autoren, nicht die Redakteure.

jetzt weiß ich, warum das Konzept nicht rüberkam: ich verwende Redakteur zu Autor synonym und unterscheid hier nicht. Der "Site-Verwalter" ist quasi der Template-Entwickler, der vorgibt (durch Konfiguration), welche Tags vom Redakteur/Autor eingebunden werden können.

Die Module an sich kann der Autor/Redakteur dann in der entsprechenden Maske pflegen (e.g. Termindatenbank) und diese dann per "[TerminDatenbank]" einbinden.

[Basti]

Hi Christian.

Zitat von dr.e.

jetzt weiß ich, warum das Konzept nicht rüberkam: ich verwende Redakteur zu Autor synonym und unterscheid hier nicht.

Vielleicht der richtige Zeitpunkt, das zu überdenken, denn diese Rollen existieren ja in den "Systemen" der Kunden und in den Anforderungsdefinitionen.

Aber dein System klingt interessant. Für mich, da ich eben ähnlich umsetzen muss und will und da auch schon konkrete Vorstellungen habe, die aber alle nicht so ganz … das gelbe vom Ei sind.

- Kann dem Autor zugemutet werden, diese Tags einzubauen? Natürlich kann man das Buttons einbinden die den Tag wie hier im Forum an der Cursorposition einfügen. Andererseits finde ich das doch nicht ganz so handlich, siehe z.B. die Wordpress-Erweiterung "Podpress".

- Wie mit Aktualisierungen umgehen? Der benutzer schreibt erst den Tag und erwartet dann eine Eingabe-maske des Moduls.

- Wie überhaupt mit "Fehlern" umgehen? ein Tag wird gelöscht - verschwindet dann auch das Modul? Muss es explizit gelöscht werden und verschwindet dann der Tag?

- Wie lassen sich ältere Versionen wiederherstellen. Ich vergebe jeder Komponente/jedem konkreten Modul in jeder version eine eigene ID, kann also jedes Modul je Seite einzeln wieder auf eine vorige version zurücksetzen etc. Wie geht das mit diesen Tags?

Alles natürlich lösbar, aber mein Fokus liegt bislang auf einer extrem einfachen Benutzeroberfläche (in sofern das möglich ist) und so macht mir das ein wenig … Enge im Kopf.

Liebe Grüße,
Basti

[dr.e.]

Hallo Basti,

hier die Antworten auf deine Fragen:

- Kann dem Autor zugemutet werden, diese Tags einzubauen? Natürlich kann man das Buttons einbinden die den Tag wie hier im Forum an der Cursorposition einfügen. Andererseits finde ich das doch nicht ganz so handlich, siehe z.B. die Wordpress-Erweiterung "Podpress".

Ja, darin sehe ich kein Problem. Man muss dem Benutzer nur eine Auswahl an Tags bereitstellen, und falls diese konfiguriert werden müssen einen Wizzard dafür bereitstellen, der entsprechende Hilfetexte bereithält. Wir praktizieren das bei der Messe München im CMS so und das hat sich bewährt.

- Wie mit Aktualisierungen umgehen? Der benutzer schreibt erst den Tag und erwartet dann eine Eingabe-maske des Moduls.

Nein. Für jedes Modul (e.g. Pressemeldungen, Termindatenbank) gibt es ein eigenes Backend (des Moduls) und in diesem pflegt der Redakteur seine Meldungen. Der Tag dient nur der Einbindung in die Seite und zwar da, wo es der Red. gerne hätte. Bei vielen Modulen möchte er ja einen Einleitungstext dazuschreiben und damit bleibt er sehr flexibel.

- Wie überhaupt mit "Fehlern" umgehen? ein Tag wird gelöscht - verschwindet dann auch das Modul? Muss es explizit gelöscht werden und verschwindet dann der Tag?

Nein. Das Modul besteht aus Code, Bildern, Datenbank-Einträgen, oder was auch immer und das Tag ist quasi nur der Repräsentant des Moduls in der GUI. Verändert man den Quelltext des Tags oder löscht man diesen, wird er einfach nicht mehr ausgeführt, weil der Contentparser diesen nicht findet. In diesem Fall eignen sich XML-/HTML-ähnliche Tags dabei am meisten, da diese dann nicht angezeigt werden. Schwierig ist dabei aber auch, dass bei Veränderung auch Teile "verschluckt" werden, bis der Browser den nächsten schließenden Tag findet. Ich verwende deshalb Pseudo-Tags der Form "[TagName]" bzw. "[TagName Param=Value]" usw.

- Wie lassen sich ältere Versionen wiederherstellen. Ich vergebe jeder Komponente/jedem konkreten Modul in jeder version eine eigene ID, kann also jedes Modul je Seite einzeln wieder auf eine vorige version zurücksetzen etc. Wie geht das mit diesen Tags?

Tags repräsentieren Module und die Versionsverwaltung muss vom Modul bereitgestellt werden, wie auch immer das darin dann funktioniert. Bei einer Terminverwaltung kann das ein Papierkorb oder ein Archiv sein.

Alles natürlich lösbar, aber mein Fokus liegt bislang auf einer extrem einfachen Benutzeroberfläche (in sofern das möglich ist) und so macht mir das ein wenig … Enge im Kopf.

So wild ist das nicht. Biete dem Redakteur eine hübsche GUI mit einer Auswahl an Tags an und gib ihm dazu noch ein paar ausführliche Erklährungen, dann ist das ganz einfach.

[Basti]

Hi Christian.

Danke für deine Ausführungen.

Zitat von dr.e.

Nein. Für jedes Modul (e.g. Pressemeldungen, Termindatenbank) gibt es ein eigenes Backend (des Moduls) und in diesem pflegt der Redakteur seine Meldungen. Der Tag dient nur der Einbindung in die Seite und zwar da, wo es der Red. gerne hätte. Bei vielen Modulen möchte er ja einen Einleitungstext dazuschreiben und damit bleibt er sehr flexibel.

Schon klar, nur taugt mir das alles für mich noch nicht so recht - zumindest die No-JavaScript-Version, in der eben erst ein Modul erstellt werden muss und dann der Tag in den Text eingebracht werden muss taugt mir überhaupt nicht, da er nicht dem natürlichen Fluß entspricht - meine ich.

Mal sehen...

Nein. Das Modul besteht aus Code, Bildern, Datenbank-Einträgen, oder was auch immer und das Tag ist quasi nur der Repräsentant des Moduls in der GUI. Verändert man den Quelltext des Tags oder löscht man diesen, wird er einfach nicht mehr ausgeführt, weil der Contentparser diesen nicht findet.

Also muss man Module womöglich auch an zwei Stellen löschen. Ich denke, falls der Benutzer nur den Tag löscht wäre eine Meldung beim speichern gut, ob die nicht mehr verwendeten Module gelöscht werden sollen (diese können dann ja immer noch dezent zur Wiederherstellung angeboten werden)

Tags repräsentieren Module und die Versionsverwaltung muss vom Modul bereitgestellt werden, wie auch immer das darin dann funktioniert. Bei einer Terminverwaltung kann das ein Papierkorb oder ein Archiv sein.

Was ich meine ist einfach, dass die Verzahnung ja einen Schritt komplexer ist. Wenn ich von meinen Text eine ältere Version wiederherstelle kann ich nicht automatisch von einer integren Version der Seite ausgehen, da ja inzwischen ein Modul gelöscht worden sein kann - aber gut, das Problem besteht ja eh immer - zumindest was die Inhalte angeht.

So wild ist das nicht. Biete dem Redakteur eine hübsche GUI mit einer Auswahl an Tags an und gib ihm dazu noch ein paar ausführliche Erklährungen, dann ist das ganz einfach.

Ja, eben diese "ausführlichen Erklärungen" sind es, die mich abschrecken. Mein Anspruch ist eigentlich ein System ohne "Hilfe-Seiten" und ich muss einfach aufpassen, dass ich mich mit der Implementierung dieser für mich notwendingen Funktionen nicht in die Richtung unzählicher anderer CMS bewege, die man einem technisch unversierten, uninteressierten Kunden bzw. einem Kunden mit ebensolchen Autoren nicht mehr verkaufen kann.

Dank dir.

Basti