Django CMS

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

Hallo,

ich muss gerade eine Seite basteln, bei der ich auf ein CMS setzen muss. Am besten wäre es wohl, das alles selbst zu machen, dann hat man, was man wirklich braucht. Dazu habe ich aber keine Lust und finde, dass man durchaus auf existierende Lösungen setzen sollte.

Wie siehts mit http://django-cms.org/ aus? Jemand Erfahrung damit? Vllt. andere Vorschläge (pylucid habe ich angesehen, ist mir aber definitiv noch zu unausgereift und gefällt mir so auch nicht wirklich)?

Danke!
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

Ich sag es einmal so, es ist leichter ein eigenes zu schreiben, als ein vorhandenes so anzupassen, dass es tut was du willst. Von daher hast du nicht viele Optionen. Wie du schon richtig erkannt hast ist keines der von dir genannten CMS verwendbar. Auch wenn django-cms.org nice aussieht und sicherlich nicht schlecht ist, wird es etwas unlustig, wenn du was willst, was es nicht will ;)
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

danke für dein Feedback und du hast wahrscheinlich recht, dass es (vor allem) mit Django einfacher ist, ein eigenes, angepasstes CMS zu bauen (die Admin-Oberfläche muss man ja glücklickerweise nicht mehr selbst machen).
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Was suchst du genau und was gefällt dir an PyLucid nicht?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Ich hatte mal selbst begonnen, ein einfaches CMS zu bauen. Ich gab's wieder auf, weil ich mit dem Ergebnis nicht so richtig zufrieden war. Ich hatte eine klassische statische Site vor Augen, die einmal konzipiert und dann von Redakteuren mit Inhalten gefüllt wird - zum Beispiel eine Online-Zeitung.

Es gab Seiten (`Page`), Artikel (`Story`) und Layouts (`Layout`). Seiten bilden eine Hierarchie. Die Kindseiten sind geordnet. Jede Seite kennt mehrere Artikel als geordnete Listen. Ein Artikel hat einen Titel, einen Text und das selbe noch mal, wenn er als Aufmacher dargestellt werden soll. Er kennt die Seite, die seine URL definiert. Vorlagen definieren mittels Django-Template, wie ein Artikel oder eine Seite als HTML dargestellt werden soll. Diese wollte ich aber ebenfalls bearbeitbar machen und daher nicht im Dateisystem speichern. Um beliebige andere Attribute zu einer Seite oder einem Artikel hinzuzufügen, gibt es das Konzept von Meta-Daten. Im Prinzip ist dies ein Textfeld, wo ich Zeilen wie `keywords: a, b, c` eintragen kann und dann mit `page.meta.keywords` in einem Layout ansprechen kann.

In dem folgenden Datenmodell sieht man noch die Klasse `PageStory`, welche die N:M-Beziehung zwischen Seiten und Artikeln definiert. Da ich pro Seite mehrere Listen (`aspect`) habe und die Listen geordnet sind (`position`), kann ich nicht einfach ein `ManyToManyField` benutzen.

Code: Alles auswählen

    class Layout(models.Model):
        name = models.CharField(max_length=100)
        text = models.TextField()

    class Page(models.Model):
        parent = models.ForeignKey("self", related_name="child_set")
        position = models.IntegerField(default=0)
        url = models.CharField(max_length=100)
        title = models.CharField(max_length=200)
        layout = models.ForeignKey(Layout)
        meta = models.MetaField()

    class Story(models.Model):
        master = models.ForeignKey(Page, null=True)
        title = models.CharField(max_length=200)
        text = models.TextField()
        teaser_title = models.CharField(max_length=200)
        teaser_text = models.TextField()
        meta = models.MetaField()

    class PageStory(models.Model):
        page = models.ForeignKey(Page)
        story = models.ForeignKey(Story)
        aspect = models.CharField()
        position = models.IntegerField(default=0)
        layout = models.ForeignKey(Layout, null=True)
Auf Effizienz hatte ich nicht ernsthaft geachtet. Um zu einer URL die passende Seite zu finden, bin ich für `/foo/bar/` bei der Wurzel losgelaufen und habe für jedes URL-Segment das passende Kind gesucht. Gibt es keine solche Seite, ist es ein 404. Andernfalls lade ich das Layout und übergebe die Seite zur Anzeige. Das stößt das Laden der Artikel und weiterer Layouts an.

Code: Alles auswählen

    class Page...
        @classmethod
        def root(cls):
            return Page.objects.get(url="")
        
        @classmethod
        def from_url(cls, url):
            page = cls.root()
            if url:
                for segment in url.split("/"):
                    try:
                        page = page.child_set.get(url=segment)
                    except Page.NotFound:
                        return None
            return page

    def show(request, url):
        page = Page.from_url(url)
        if not page:
            raise Http404
        t = Template(page.layout.text)
        return HttpResponse(t.render(Context({'page': page})))
Damit ein Template weitere Templates laden kann, muss man noch ein bisschen mehr machen, aber das Prinzip sollte klar sein. Eine Reihe von passenden Funktionen in `Page` hat geholfen, die Seiten wie geschwünscht zusammenzustellen.

Ein entscheidener Punkt war, Artikel mit einem bestimmten Layout in eine Seite einzubetten. So könnte man z.B. alle unter dem Aspekt `related` assoziierten Artikel einer Seite mit dem Layout `related_article` unter dem als `main` assoziierten Artikel anzeigen. Dazu hatte ich ein spezielles Template-Tag gebaut.

Das funktionierte alles auch so weit, doch ein paar Dinge waren blöd: Das Admin-UI war nicht gerade ideal (Baum und geordnete Listen werden nicht unterstützt), die Datenstruktur zu bearbeiten, gerade weil mal Artikel und Seiten zueinander konsistent halten musste. Zudem empfand ich als Entwickler es als eine Qual, Templates in einem "textarea" zu bearbeiten - selbst wenn ich das nicht länger als vielleicht 30min für den Prototyp gemacht hatte.

schließlich war ich mir nicht sicher, was ich durch mein generisches Modell wirklich gewinnen und was stattdessen verlieren würde. Was, wenn man etwa "Standorte" listen wollte? Oder Partner? Sind das auch Artikel? Schließlich war die Verwaltung von Bildern ein ungelöstes Problem. Dazu fehlte mir eine Verwaltung und eine Möglichkeit, Bilder pro Artikel oder global (für Layouts) hochzuladen, ohne dass sich die Namen in die Quere kommen. Doch einen gewissen Einfluss würde ich auch die Namen schon nehmen wollen, denn was z.B., wenn ich zu jedem Autor ein Bild anzeigen will. Habe ich `meta.author=sma`, könnte ich einfach ein Bild `sma.jpg` ablegen und die URL für das "img"-Element ist trivial zu bauen.

Ich war mir auch nicht sicher, ob man nicht besser Seiten und Navigation statt Artikel und Seiten hat. Oder gar alles drei. Irgendwie fühlte sich mein Ansatz sowohl zu kompliziert als auch nicht flexibel genug an.

Und Versionierung und die Möglichkeit, eine Seite freizugeben und schon mal weiter zu bearbeiten, hatte ich natürlich auch nicht. Das wird schnell beliebig kompliziert, müsste ich z.B. überall einen "dies ist die offizielle Version"-Marker berücksichtigen.

Schließlich war ich nicht darauf vorbereitet, interaktive Seiten zu haben - wohin posten, wenn man mehr als einen interaktiven Teil auf der Seite hat? Man bräuchte eine Art Portlet-Konzept, wenn man Seiten flexibel aus interaktiven Bausteinen zusammensetzen will.

Stefan
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Interessant.

Ich sehe da viele Parallelen zu PyLucid. Allerdings haben wir keine mehrere Artikel pro Seite. Jeder Seite hat einen Inhalt. Wobei man halt lucidTags einfach einfügen kann, damit dort der Inhalt eines Plugins einfließt.
Möchte man was spezielles haben (z.B. Blog, Lexicon, Sitemap) erstellt man eine Plugin-Seite und diese hängt dann im Menü-Baum, genauso wie normale Text-Inhalts-Seiten.

Damit Templates und auch CSS/JS Dateien bearbeitbar sind, speichern wir diese in der DB und nutzten dazu u.a. django-dbtemplates.

Templates in Templates haben wir im Prinzip auch. Es gibt das globale Template, was die Seite vom Layout festlegt. Dort gibt es einen "content" Bereich. In diesem kommt der Inhalt.
Der Inhalt ist entweder ein normaler Text (PageContent Typ) der aber auch lucidTags beinhalten kann, was Ausgaben vom Plugins sind (z.B. Liste der letzten Änderungen).
Eine Seite kann auch vom Typ Plugin sein, dann wird die "Ausgabe" des Plugins als Seiteninhalt eingefügt (z.B. Blog Plugin).
Jedes Plugin kann ebenfalls django template nutzten.
btw. Plugins nicht eigentlich nichts anderes als kleine django-apps.

Für Versionsverwaltung der Inhalte nutzten wir django-reversion.

Wir gehen auch die URL Teile durch und suchen den passenden PageTree Eintrag.

PyLucid ist nicht wirklich auf ein Redaktions-Workflow ausgerichtet. Dennoch kann man Seiten nicht öffentlich machen, in dem man sagt das nur eine bestimmte User-Gruppe Zugriff hat. Wobei man Ansicht und Editieren eine separate User-Gruppe zuteilen kann.

Zum Thema Bilder: Dort haben wir leider noch nicht viel gemacht. Im Grunde wird es aber wohl darauf hinauslaufen, das man einen http-Upload realisiert und die Dateien in ein bestimmtes Verzeichnis im Static-Ordner speichert. Beim editieren einer Seite sollte man dann eine Liste aller vorhandenen Bilder bekommen, um einen Link einfach einfügen zu können.

Das Django Admin Panel ist für das arbeiten nicht ganz so gut erweiterbar. Zumal man mehrere Model-Klassen hat, die Logisch verknüpft sind und später eine Seite ergeben.
Ich sehe es ehr als Low-Level-Editor für den superuser an. PyLucid Plugins können aber auf einfacher weise "Admin views" im Menü unterbringen und damit kann man dann einfache Editiermöglichkeiten erstellen.

Was PyLucid noch hat:
* Wir nutzten das django Site Framework: d.h. man kann mehrere Domains (die alle ganz unterschiedlich aussehen können) parallel mit einer instanz verwalten.
* Alles hat i18n Unterstützung.

Deswegen, wenn man ein nettes System haben will, ist das eine Menge Arbeit und nicht ganz so trivial. Mal eben so ein CMS bauen ist es nicht...
Ich würde mir wünschen es würden sich mehr Leute an PyLucid beteiligen, damit man Design-Entscheidungen gemeinsam treffen kann, um eine möglichst gute Lösung zu finden.

(Das gesagte, gilt nur für die v0.9 Entwicklerversion)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

Ich weiß nicht, ob ich ein CMS brauche, das so verschachtelt und kompliziert aufgebaut ist.
Gerade hier ist ja auch der Vorteil, wenn man sich selbst das zusammenbaut, was man braucht - es muss eben nicht alles unterstützt werden, was irgendwie irgendwer mal brauchen könnte.

Das Problem des Filebrowsers, Bildern etc. habe ich innerhalb von kürzester Zeit gelöst, das Ergebnis ist hier zu sehen: http://www.icoost.com/programmiersprach ... lebrowser/ und ich bin eigentlich ziemlich zufrieden damit. Im Endeffekt muss ich auf dieser Basis nur noch ein paar Models basteln, je nach Einsatzgebiet...

Zu PyLucid: hauptsächlich geht es mir darum, dass es noch zu unbeständig ist und der Code anscheinend zu oft von Grund auf neu gemacht wird. Ich habe mir den Code nicht konkret angesehen, aber das spricht eigentlich dafür, dass der/die Entwickler noch kein wirklich passendes Konzept gefunden haben. Und wenn ich ein CMS verwende, will ich eigentlich schon ein ausgereiftes, beständiges Produkt und kein System mit Kinderkrankheiten.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ja, bis v0.9 einsatzbereit ist, dauert es noch eine weile, das Stimmt.

Ich weiß allerdings nicht, was so schlimm daran ist, das wir mehrmals von fast 0 Angefangen haben? Meinst du es ist besser immer weiter mit seinem Kram zu machen, auch wenn man weiß das die Basis besser geändert werden sollte?
Warum wir neu angefangen habe, kann man hier nachlesen: http://www.pylucid.org/_goto/70/genesis/

Btw. es gab immer die Möglichkeit seine Seite auf die Nächste Version zu Updaten. Das wird es auch weiterhin geben. Schließlich benutzte ich PyLucid selber und will meine Seite auch Updaten ;)

Ich wollte eigentlich am Anfang auch nur was kleines haben. Viel braucht man ja nicht usw.... Mit der Zeit möchte man aber doch das ein oder andere Feature haben. Somit ist PyLucid mittlerweile schon etwas dicker geworden.
Aber ich denke dir könnte es ebenfalls so gehen, wenn du mit was kleines Anfängst...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Die Möglichkeit, eine Site einerseits in einer Form anzuzeigen, währenddessen aber an der nächsten Form zu arbeiten, um diese dann zu einem bestimmten Zeitpunkt umzustellen ist IMHO der Kernvorteil eines CMS. Leider reicht es dazu nicht aus, einfach nur Seiten und Artikel zu versionieren, sondern man muss das auch für die Assoziationen machen. Schließlich kann Seite und Artikel gleich bleiben, doch morgen möchte ich eine andere Liste von verwandten Artikeln anzeigen.

Da mir das zu kompliziert wurde, habe ich es gelassen.

Jens, wie würdest du denn so einen typischen Zeitungsartikel darstellen, wie du ihn vielleicht bei Zeit-Online findest? Dort sehe ich zu einem Artikel (den sie idiotischerweise in einzelne Seiten aufteilen - wahrscheinlich um mehr IPs zu generieren) eine Liste Artikel "mehr zum Thema". Alle Artikel sind auch kategorisiert und verschlagwortet. Letzteres wäre wohl eine spezielle Funktion (ebenso wie das "Neu im Resort" und "Beliebteste Artikel in Rubrik") doch die Rubriken selbst könnte mit meinem Datenmodell abbilden.

CSS-Dateien und JS müssten, da hast du Recht, auch im CMS stecken. Hatte ich nicht bedacht. Ich würde es dann aber eigentlich anders herum sehen. Warum nicht alles in eine Versionsverwaltung stecken? Das ist eine andere Idee von mir, für die ich schon immer mal einen Prototyp bauen wollte. Wenigstens Templates und andere Dateien kann ich gefahrlos und effizient im Dateisystem speichern, wenn ich denn dem Gelegenheitsnutzer ein Web-UI biete und allen anderen direkten Zugriffs per Subversion oder Git oder so biete.

Stefan
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Die Screenshots von django-filebrowser (was ich gar nicht kannte und glaube ich auch neuer ist, als mein CMS-Prototyp) zeigen einen schicken frischen Look für das Admin UI. Löst das Ding allerdings das Problem, dass ich einen eigenen Namensraum pro Artikel haben können möchte?

Stefan
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

Klar ist es besser alten Mist zu löschen und auf solider Basis neu anzufangen. Vllt. greife ich irgendwann auch auf PyLucid zurück - wer weiß - nur momentan ist es mir einfach noch zu unausgereift.

@sma: ich brauche solche Funktionen nicht und wenn das mal so sein sollte, dann bau ich es mir angepasst ein...
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Zum Thema Kategorie und Verschlagwortung: In PyLucid kann man Seiten mit Tags versehen.

Naja, ich selbst möchte keine Zeitungsseite machen ;) Ich denke das Sinnvollste wäre es, ein PyLucid Plugin zu machen, damit man auch einen Teaser Text unterbringen kann. Dort kann man dann natürlich auch einen Redaktions-Workflow realisieren.

Ich hatte mir von einiger Zeit mal den django-filebrowser angesehen, war aber noch unbrauchbar. Vielleicht hat sich das zwischenzeitlich geändert.
Es gab nämlich in v0.8 von PyLucid auch einen FileManager Plugin, der noch nicht portiert ist auf v0.9. Hier ein screenshot: http://pylucid.org/_goto/136/filemanager/#screenshot
Aber wenn django-filebrowser was taugt, werde ich den verwenden.
Mit dem Namensraum: Einfach ein Unterverzeichnis erstellen?

HTML, CSS und JS in ein SVN stecken wäre nett. Allerdings würde man dann auf jeden Fall PyLucid nicht mehr auf "normalen" Webhostern nutzten können. Mit django-reversion hat man ja schon eine versionsverwaltung. Wobei es da leider keine Diff Ansichten gibt. Das möchte ich irgendwann mal einbauen.
btw. CSS/JS Dateien werden auch im Media-Pfad als "Cache" hinterlegt, wenn Schreibzugriff erlaubt ist, wenn nicht, liefert ein view die Daten aus, was natürlich langsamer ist...

edit: Ach Zum Thema admin extras, dazu hab ich ein extra Menü eingebaut:
Bild
Dort können sich Plugins einfach verankern. Ein ähnliches Menü sieht man dann auch immer auf der Seite, wenn man eingeloggt ist.
Mehr Bilder: http://www.flickr.com/photos/jensdiemer/tags/pylucid/

Noch was zum Zeitplan: Ich denke in ein/zwei Wochen wird es eine Beta Version geben, die man dann auch einsetzten kann, da ich die selber auf meinen Homepages nutzten möchte. Aber noch schrauben wir an den Models: http://pylucid.org/phpBB2/viewtopic.php?t=295 Erst wenn die Stehen kann man es auch produktiv einsetzen...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

jens hat geschrieben:Aber noch schrauben wir an den Models: http://pylucid.org/phpBB2/viewtopic.php?t=295 Erst wenn die Stehen kann man es auch produktiv einsetzen...
Führst du öfters selbstgespräche? *duck und weg*
lunar

Irgendwann hat sicher auch der letzte bemerkt, dass Du mit Jens' Art zu Entwicklen nicht einverstanden bist … es reicht also langsam, Du musst solche Diskussionen nicht jedes Mal anfangen, wenn Jens was sagt.
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

@apollo13: ich muss ganz ehrlich auch sagen, dass dieser Kommentar mehr als sinnlos ist und absolut nichts zur Sache beiträgt. Auch aus dem Grund, dass jens Ausführung sehr wohl informativ war.
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

Nun mir geht es auch schon langsam auf den Nerv, dass er überall mit pylucid kommen muss… Jetzt wird schon im Eingangspost gesagt, dass pylucid keine option ist und dann macht er wieder nen pylucid thread draus.
lunar

@apollo13: Diese Diskussion dreht sich um CMS. Zwar hat der OP PyLucid eingangs ausgeschlossen, aber wenn sma sich dazu äußern darf, wie man ein CMS implementieren könnte, dann darf Jens das auch, mit samt seinen persönlichen Erfahrungen mit PyLucid. Das muss Dir nicht gefallen, ist aber um Meilen näher am Thema als Dein Kommentar. Wenn das ein persönliches Problem für Dich ist, kannst Du das im Interesse aller anderen bitte privat mit Jens klären.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

lunar hat geschrieben:aber wenn sma sich dazu äußern darf, wie man ein CMS implementieren könnte
Es ging doch um die Überlegung, ob selbst ein CMS bauen oder was fertiges nehmen... und somit finde ich sind auch Jens Beiträge bezüglich seiner Erfahrungen total on topic.

Stefan
Antworten