CMS Schreiben

[monocult]

Hallo zusammen,

ich weiß CM Systeme gibt es eigentlich genug. Aber ich habe wirklich schon mit einigen gearbeitet und bin doch immer wieder an grenzen gestoßen. Oder das cms ist einfach zu groß zu kompliziert(für den Redakteur) etc.

Ich möchte daher etwas selber schreiben. Dazu einige Ideen Technischer Natur.

-es sollen vom Konzept keine Einschränkungen für einen späteren Ausbau bestehen. (auch wenn am Anfang noch nicht alles genutzt wird. betrifft wahrscheinlich hauptsächlich den DB Aufbau.)

-möglichst vielseitig einsetzbar (CGI, mod_python, fastcgi, verschiedene Datenbanken z.b. sqllight, mysql, etc)

-caching der Seiten (nicht nur Template caching als python Code sondern statischen HTML Code entweder aus einer Datei alternativ aus der DB)

-Plugin Schnittstelle

-Einfach zu bedienen (ja ja das sagt sich so leicht)

Zusätzlich würde ich gerne ein paar neue Ideen einbauen zb. alternative Content Zuordnung über Tags. Ich würde da gerne einfach mal was neues Ausprobieren.

Wenn ihr Ideen hab oder Dinge die ihr an anderen CMS gut findet, würde ich mich freuen wenn hier einige Anregungen entstehen würden. Gerne auch vollkommen unkonventionelle Vorschläge.

Zum schluß noch etwas zur Technik bisher habe ich meist auf den Einsatz von externen frameworks oder Template Systemen verzichtet. Hauptsächlich um unabhängig zu bleiben und weil es für mich einfacher ist den eigenen Code anzupassen als mich dann in ein fremdes Programm einzuarbeiten. Wahrscheinlich werde ich aber bezüglich der Templates und der DB Schnittstelle nicht an anderen Projekten vorbeikommen. Vielleicht habt ihr ja auch da noch eine Idee oder Erfahrungs berichte.

gruß Daniel



-

[jens]

ich weiß CM Systeme gibt es eigentlich genug. Aber ich habe wirklich schon mit einigen gearbeitet und bin doch immer wieder an grenzen gestoßen. Oder das cms ist einfach zu groß zu kompliziert(für den Redakteur) etc.

Genau deswegen habe ich mit PyLucid CMS angefangen, siehe: http://pylucid.org/index.py/Genesis/

Generell würde ich dir davon abraten was ganz neues Anzufangen. In Python gibt es zwar wenige CMS Systeme, aber das Rad nochmals neu zu erfinden ist einfach super Aufwendig. Da spreche ich aus eigener Erfahrung. Ich arbeite an PyLucid schon fast zwei Jahre und es gibt immer noch einen riesigen Haufen Arbeit.

Alternativ gibt es noch http://orangoo.com/skeletonz/ CMS, was allerdings IMHO nicht so ohne weiteres als CGI läuft. Dafür ist es allerdings Buzzword kompatibel, weil es viel auf AJAX setzt.
Alle anderen CMS System die in Python geschrieben sind, brauchen Zope und/oder sind dicke Dinger.

Hier mal deine Punkte in bezug auf PyLucid beantwortet:

-es sollen vom Konzept keine Einschränkungen für einen späteren Ausbau bestehen. (auch wenn am Anfang noch nicht alles genutzt wird. betrifft wahrscheinlich hauptsächlich den DB Aufbau.)

Einschränkungen wird es wohl immer geben. In PyLucid versuche ich deswegen in ersterlinie das Basissystem möglichst schlank zu halten und alles andere über Plugins zu realisieren.
Das ist allerdings auch nur eingeschränkt möglich, bzw. immer mit Mehraufwand verbunden.
z.B. ist das tinyTextile Markup, der Syntaxhighlighter Pygments und das Template System Jinja, fester Bestandteil und nicht wirklich über Plugins austauschbar. Das könnte man natürlich ändern, ist aber mit dem momentanen Plugin-System so nicht machbar, also mit mehraufwand verbunden.

Wichtiger ist mir jedoch, das man in der Ausgabe alle Freiheiten hat. Also, wie die generierten Seiten hinterher aussehen. Da ist PyLucid recht flexibel. Man kann nahezu alle Ausgaben selber ändern, wenn man möchte.

-möglichst vielseitig einsetzbar (CGI, mod_python, fastcgi, verschiedene Datenbanken z.b. sqllight, mysql, etc)

Das ist PyLucid so halb. Theoretisch ist es dank [wiki]WSGI[/wiki] sehr flexibel gestaltet. Praktisch ist es aber so, das es bisher nur einwandfrei als CGI läuft. Ich habe es zwar auch schon einmal mit fastCGI am laufen gehabt, aber da gibt es noch Probleme.
z.Z. ist PyLucid auf MySQL festgelegt. Nicht weil ich spezielle Features nutzte, die nur MySQL bietet. Viel mehr deswegen, weil die Installation mit einem SQL-Dump funktioniert und der nicht direkt in SQLite rein passen mag (Die CREATE TABLE Statements müßten umgeschrieben werden). Es ist allerdings der Einsatz von SQLAlchemy geplant, damit ist man DB unabhängiger.

-caching der Seiten (nicht nur Template caching als python Code sondern statischen HTML Code entweder aus einer Datei alternativ aus der DB)

Statischen Code rausschreiben hab ich mir auch schon mal überlegt. Das ist im Grunde das, was die Jungs von daucms.de realisieren wollen. daucmd soll später mal ein PyLucid Plugin werden.
Ansonsten gibt es bisher nur ein Object-Cache system, siehe: http://pylucid.org/index.py/DbCache/

-Plugin Schnittstelle

Gibt es in PyLucid schon lange: siehe u.a.: http://pylucid.org/index.py/ModuleManager/

-Einfach zu bedienen (ja ja das sagt sich so leicht)

Das ist PyLucid nur bedingt. Es ist nicht Dummuser tauglich. Allerdings finde ich das es auch nicht sonderlich kompliziert ist, wenn man sich erstmal eingefunden hat. Zumindest nicht so kompliziert, wie die großen CMS Systeme...

Zusätzlich würde ich gerne ein paar neue Ideen einbauen zb. alternative Content Zuordnung über Tags. Ich würde da gerne einfach mal was neues Ausprobieren.

Mit PyLucid-Plugins läßt sich da einiges machen. Zum Thema Tags: Da hatte ich mal die Idee, das über die HTML-Keywords zu machen.


Würde mich freuen wenn du dir mal PyLucid ansiehst und vielleicht dabei mithilftst. Wir können weitere Entwickler gut gebrauchen, siehe http://pylucid.org/index.py/Developer/

[mitsuhiko]

Alternativ gibt es noch http://orangoo.com/skeletonz/ CMS, was allerdings IMHO nicht so ohne weiteres als CGI läuft.

Klar tut es das. Skeletonz ist eine WSGI Anwendung

Dafür ist es allerdings Buzzword kompatibel, weil es viel auf AJAX setzt.

AJAX hat mit Buzzwords sehr wenig zu tun. Irgendwie hab ich das Gefühl, dass hier jeder JavaScript verteufelt.

-möglichst vielseitig einsetzbar (CGI, mod_python, fastcgi, verschiedene Datenbanken z.b. sqllight, mysql, etc)

Das ist PyLucid so halb. Theoretisch ist es dank [wiki]WSGI[/wiki] sehr flexibel gestaltet. Praktisch ist es aber so, das es bisher nur einwandfrei als CGI läuft. Ich habe es zwar auch schon einmal mit fastCGI am laufen gehabt, aber da gibt es noch Probleme.

Das geht auch praktisch so, wenn du keine Threading issues einbaust. Das heißt keine globalen Variablen, die nicht auf threading.local objekte gebunden sind etc. Skeletonz, alle django Anwendungen, pocoo, MoinMoin, trac sind genug Python Webanwendungen die Dank WSGI ohne weitere Arbeit auf jedem Interface laufen.

daucmd soll später mal ein PyLucid Plugin werden.

NEIN!

@Threadstarter: Da hast du dir etwas größeres vorgenommen. Und zwar wegen dem Plugin Zeug. Vielleicht willst du dir mal das django Framework ansehen, ideal für CRUD. Ansonsten rate ich dir zwecks CMS einmal Paste bzw Pylons genauer anzusehen. Das sind verhältnismäßig dünne Aufsätze für WSGI und momentan sehr im Rennen.

@jedie: Gibt es eigentlich einen Thread von dir ohne pylucid Werbung? PyLucid stufe ich momentan als nicht mit anderen CMS Systemen vergleichbar ein. Die Codebase hat bereits die Drupal Codebase überschritten, der Quellcode ist ein deutsch/englisch gemisch. Wer soll da dem Team beitreten? Es sind Features drin die niemanden etwas bringen (md5 login). Ein System im Umfang von PyLucid kann man mit django an einem Nachmittag schreiben. Sogar mit Plugins.

[BlackJack]

AJAX ist sehr wohl ein Buzzword. Das hat nichts damit zu tun ob man JavaScript verteufelt oder nicht, sondern das AJAX überall erwähnt und eingesetzt wird, weil es "hip" ist und nicht nur nach rationalen Gesichtspunkten. Buzzword eben.

Und was die "Werbung" angeht: Es gibt auch Leute, die das Kürzel WSGI nicht oft genug schreiben können.

[birkenfeld]

AJAX hat mit Buzzwords sehr wenig zu tun. Irgendwie hab ich das Gefühl, dass hier jeder JavaScript verteufelt.

Gerade bei Jens würde ich mir da keine Sorgen machen...

[EnTeQuAk]

Nu hört aba ma auf, immer auf Jens einzuschlagen.

blackbird hat schon recht, das PyLucid sehr schwer zu verstehen ist und der Code (nichts gegen dich Jens) an manchen Stellen schwer durchschaubar ist.

Das würde ich aber auf die Entwicklungszeit/dauer etc. anwenden. Ich weiß net, ob Jens damals auch schon so viel Ahnung von python hatte, wie heute... und da kommen halt neue Begriffe gerne dazu

Des weiteren ist mir schon aufgefallen, das PyLucid teils alten Schrott dabei hat... ich für meinen Teil wollte mithelfen und tue das indem ich mit Mr_Snede dauCMS entwickle (UND das war keine Werbung ) und das später als Plugin für PyLucid bereit stehen soll.

Vorerst ist es aber ein eigenständiges Projekt.


Ich habe es ja schonmal bei Jens versucht, nochmal alles zu überdenken und neu anzufangen (gute Sachen können ja ruhig übertragen werden).
Das würde im Enddefekt die komplette Überarbeitung für die Datenbankumstellung, die Codeüberarbeitung usw. sparen. Damals hat er mich aber erfolgreich abgeblockt... (warum weiß ich grad net mehr )...

Skeletonz... hmm blackbird, das kommt/kam aber auch oft von dir
Kommt es mir nur so vor oder wird da seit ewigkeiten nichts dran gemacht. Zumindest kenne ich bisher NUR die Version 1.0beta und das schon seit einer langen Zeit...

Mir persönlich sind aber kaum in Python realisierte CMS bekannt.

Ansich währe ich dafür, einen neuen "Versuch" zu wagen. Gleich von Anfang an auf WSGI + Datenbankunabhängigkeit dank SQLAlchemy (oder einem anderen OEM) und guter Pluginschnittstelle setzen.

Gute Sachen aus PyLucid können ja gerne übernommen werden.

vielleicht schaut man, ob man eventuell auf pocoo aufbauen kann (oder einzelnen Komponenten). Die Pluginschnittstelle gefällt mir jedenfall sehr und ich denke, das ließe sich eventuell auf ein CMS umbiegen. (und mit der verwandschaft zu pocoo ließe sich später auch ein Forensystem mit einfügen lassen )

MfG EnTeQuAK

[Leonidas]

Ein System im Umfang von PyLucid kann man mit django an einem Nachmittag schreiben. Sogar mit Plugins.

Habe ich schon erwähnt, dass es Ellington gibt, welches ein Django-basiertes CMS ist. Aber es ist "etwas" größer und "etwas" teuer. Aber immerhin bin ich mir ziemlich sicher, dass man für das Geld auch ein hochqualitatives Stück Code bekommt - ist von den Django-Entwicklern geschrieben.

[Leonidas]

Kommt es mir nur so vor oder wird da seit ewigkeiten nichts dran gemacht. Zumindest kenne ich bisher NUR die Version 1.0beta und das schon seit einer langen Zeit...

Es gibt die SVN-Version. Außerdem kann man sich jederzeit an amix wenden, den sehe ich manchmal im IRC und hab ihn zusammen mit blackbird überredet Skeletonz WSGI-kompatibel zu machen.

Gute Sachen aus PyLucid können ja gerne übernommen werden.

Was genau? (Ernst gemeint, das würde mich wirklich interessieren, was man aus PyLucid übernehmen könnte)

[apollo13]

Ein System im Umfang von PyLucid kann man mit django an einem Nachmittag schreiben. Sogar mit Plugins.

Habe ich schon erwähnt, dass es Ellington gibt, welches ein Django-basiertes CMS ist. Aber es ist "etwas" größer und "etwas" teuer. Aber immerhin bin ich mir ziemlich sicher, dass man für das Geld auch ein hochqualitatives Stück Code bekommt - ist von den Django-Entwicklern geschrieben.

Warum die Suite nicht billiger ist, als beide zusammen, soll mal wer verstehen
[ot]
BTW: Django hat beim Google Summer of Code ein paar Projekte laufen, unter anderem auch, dass man auf der Adminseite nur Einträge ändern kann die einem (bzw. der Gruppe) gehören
[/ot]

[EnTeQuAk]

Also, wer 10.000 $ mal so eben parat hat und mir das kaufen kann, der melde sich

Es hört sich jedenfalls sehr schön an, was es alles kann. Aber ich meine guter Code hin und oder her... die Funktionen sind auch super... aber der ein Preis von 10.000$ ??? -- Sorry, das mag ich net verstehen.

€dit

Was genau? (Ernst gemeint, das würde mich wirklich interessieren, was man aus PyLucid übernehmen könnte)

hmm -- kA vielleicht die Dynamischkeit, das ein Plugin verschiedene Ausgabemethoden verwenden kann (verschiedene TemplateEngines).
Ansonsten ... ich stecke nicht so extrem in der Materie drinne -- aber der JS-MD5-Login ist denke ich nicht von schlechten Eltern (auch, wenn in meinen Augen ein klein wenig übertrieben...)

MfG EnTeQuAk

[apollo13]

Man muss aber auch sagen, dass Ellington bis jetzt mehr oder weniger das einzige CMS ist und die Enterpriselösung schlechthin ist.

Wenn das Opensource wäre *lechz*
@EnTeQuAk: Stimmt beim Preis spinnen die sich etwas aus^^

[Leonidas]

Also, wer 10.000 $ mal so eben parat hat und mir das kaufen kann, der melde sich

Ist ja auch nicht für Endnutzer gedacht sondern für Corporate-Kunden und dort ist der Preis sicher nicht einmal so überhöht.

Aber ich meine guter Code hin und oder her...

Nein, es gibt kein hin und her. Guter Code ist essentiell für ein brauchbares Projekt. Sonst erstellt man ein Monster mit Sicherheitslücken, welches schwer erweiterbar, schwer wartbar ist, schwer verständlich ist. Das willst du dir nicht antun, schon gar nicht in einer Firma.

die Funktionen sind auch super... aber der ein Preis von 10.000$ ??? -- Sorry, das mag ich net verstehen.

Das ist der Preis seiner gut getesteten, Corporate-Ready Software. Man kann mit guter, freier Software auch gut Geld verdienen - wenn Ellington nicht wäre, würde Django sicher nicht solches Momentum haben. Denn die Ellington-Entwickler haben ein sehr persönlcihes Interesse, dass Django so gut wie möglich funktioniert und so flexibel wie möglich ist - sich selbst zuliebe und auch den Nutzern von Ellington.

[Leonidas]

hmm -- kA vielleicht die Dynamischkeit, das ein Plugin verschiedene Ausgabemethoden verwenden kann (verschiedene TemplateEngines).

Ist mit Buffet auch kein Problem - ich denke das TGs Widgets das ebenso können.

Ansonsten ... ich stecke nicht so extrem in der Materie drinne -- aber der JS-MD5-Login ist denke ich nicht von schlechten Eltern (auch, wenn in meinen Augen ein klein wenig übertrieben...)

Unsicher und löst ein Problem welches nicht wirklich existiert. Aber zumindest kann man das auch wieder abschalten.

[EnTeQuAk]

Ja gut, aus Sicht von Enterpriselösung und Firmen habe ich nun nicht geschaut Die haben meißtens ein klein wenig mehr Geld, als ich hier @ home


Und das mit dem Code war nicht so gemeint. Guter Code ist essentiell, um ein Projekt weiterzubringen. Das ist mir klar und darauf treffe ich jetzt schon bei dauCMS. Da bin ich auch gerade dabei alles etwas umzuschreiben, um alles etwas "haltbarer" zu machen. Einfach eine klare Struktur reinzubringen. Bisher war es ja nur ein "ich mach mal das. Ohh, das funktioniert FERTIG!" ;D
Das versuche ich nun etwas auszubauen und klare Linien reinzubringen. Schon, damit Mr_Snede es etwas einfacher hat, sich in meinen Code reinzuarbeiten. Denn das ganze ist ja als Lernprojekt an den Start gegangen. Und da ich einfach mehr Zeit habe schriebe ich auch mehr, als Mr_Snede und daher hängt er meißt etwas zurück.

Klarer Code ist wichtig und hat man ihn nicht ist es argh schwierig, überhaupt in angemessener Zeit Umbauten oder allgemein Erweiterungen einzubauen.
Das ist mir schon klar.

[mitsuhiko]

AJAX ist sehr wohl ein Buzzword. Das hat nichts damit zu tun ob man JavaScript verteufelt oder nicht, sondern das AJAX überall erwähnt und eingesetzt wird, weil es "hip" ist und nicht nur nach rationalen Gesichtspunkten. Buzzword eben.

Ich gebe zu AJAX wird mometan fast überall verwendet aber es werden auch schon Dinge AJAX genannt die mit AJAX nichts zu tun haben. Seiteneffekte sind kein AJAX Ich persönlich finde AJAX bzw AJAJSON eine tolle Sache. Es macht Webanwendungen unglaublich flexibel und angenehmer für den Anwender.

Und was die "Werbung" angeht: Es gibt auch Leute, die das Kürzel WSGI nicht oft genug schreiben können.

Ich bekenne mich schuldig. Aber ich fürchte WSGI ist noch zu wenig Buzzword. Aber hey. Vor 2 Jahren als mir Leonidas das erste mal das PEP gezeigt hat war ich irgendwie der einzige, der von WSGI überzeugt war. Jetzt schaut die Situation eindeutig schon besser aus

[jens]

Ihr habt ja recht, die Codebasis von PyLucid ist nicht die beste, das hab ich auch nie behauptet.
Und es stimmt, es sind teilweise noch code aus den Anfangstagen drin. Klar dürfte auch sein, das ich in den Anfangstagen es auch nicht besser weiß. Aber nicht nur das, ich bin weiß heute bei weitem auch nicht alles. Ganz im Gegenteil, ich bin kein Informatiker und werde das wohl auch nie werden

Vielleicht sollte ich wirklich mal darüber nachdenken, den Unterbau komplett zu tauschen. Vielleicht wirklich ein django Projekt draus machen. Hätte den Vorteil, das ich weniger um den Unterbau kümmern muß und mehr schönere Dinge erledigen kann, wie nette Plugins zu schreiben Denn irgendwie machen Sachen nur dann richtig Spaß, wenn man ein Endergebnis sieht.

[apollo13]

Vielleicht sollte ich wirklich mal darüber nachdenken, den Unterbau komplett zu tauschen. Vielleicht wirklich ein django Projekt draus machen. Hätte den Vorteil, das ich weniger um den Unterbau kümmern muß und mehr schönere Dinge erledigen kann, wie nette Plugins zu schreiben Denn irgendwie machen Sachen nur dann richtig Spaß, wenn man ein Endergebnis sieht.

Daran arbeite ich gerade Ist aber bei ein paar Dingen noch etwas kompliziert, da ich gerne so weit wie möglich das vorhandene Admininterface verwenden möchte, das wäre durch ordentliche ACL auch um einiges besser (aber was noch nicht ist wird schon noch^^)

[birkenfeld]

wenn Ellington nicht wäre, würde Django sicher nicht solches Momentum haben.

Ich nominiere Leonidas hiermit zum Anglizisten des Monats.

[jens]

Daran arbeite ich gerade Ist aber bei ein paar Dingen noch etwas kompliziert, da ich gerne so weit wie möglich das vorhandene Admininterface verwenden möchte, das wäre durch ordentliche ACL auch um einiges besser (aber was noch nicht ist wird schon noch^^)

Ein richtige Userverwaltung gibt es in PyLucid eh noch nicht, siehe: http://pylucid.org/phpBB2/viewtopic.php?t=113

Weitere Überlegungen für ein PyLucid@django: http://pylucid.org/phpBB2/viewtopic.php?p=573

[monocult]

erstmal danke für die rege Beteiligung. Ich hatte mir pylucid schon angeschaut.

Das ein CMS viel Arbeit ist ist mir klar da ich schon eins geschrieben habe. Doch stehe ich dort an einem ähnlichen Problem wie du (schwer durchschaubarer Code etc.) bzw. stoße an die grenzen des DB Designs .Hier könnt ihr euch mal einen optischen Eindruck des Backends machen.

http://www.flickr.com/photos/39722708@N ... 540645022/

Features bisher sind.
-Frontend und Content Templates
-beliebige Content Zonen
-Navi Templates
-User Verwaltung(keine ACL)
-Frontend Login
-Einfache Zugriffs Statistik
-wysiwyg Editor
-Datei und Media Manager (Grafik, flash, Videos,etc.)
-plugins (Termin Kalender, Formulare, etc)
-Massen Mailer

das ganze ist mit mod_python und mysql umgesetzt.

Momentan versuche ich einfach Konzeptionell den Rewrite vorzubereiten. (Der dann auch unter der GPL stehen soll) Wo ich mich schwer tue ist immer die Verwendung von anderen frameworks auf deren Entwicklung ich keinen Einfluss habe. Es ist schade das man bei python anders als bei Php ja schon fast darauf angewiesen ist eins zu verwenden.

Der Punkt der mich auch interessiert ist wie man das Klassische CMS System Vielleicht verbessern kann. Innovative Content Erstellung und Verwaltung. Einfach mal was neues ausprobieren.

Vielleicht habt ihr ja Gedanken oder Ideen. Vielleicht eine Mischform aus Wiki und CMS mit blog Funktionen wie pingback etc.