Das deutsche Python-Forum

10 Jahre Diskussionen rund um die Programmiersprache Python
Aktuelle Zeit: Sonntag 26. Oktober 2014, 05:38

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: Django CMS
BeitragVerfasst: Sonntag 6. September 2009, 16:12 
User

Registriert: Dienstag 6. November 2007, 22:49
Beiträge: 862
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!


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Sonntag 6. September 2009, 16:26 
User

Registriert: Samstag 5. Februar 2005, 18:53
Beiträge: 774
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 ;)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Montag 7. September 2009, 08:08 
User

Registriert: Dienstag 6. November 2007, 22:49
Beiträge: 862
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).


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Montag 7. September 2009, 08:38 
Moderator
Benutzeravatar

Registriert: Dienstag 10. August 2004, 10:40
Beiträge: 7544
Wohnort: duisburg
Was suchst du genau und was gefällt dir an PyLucid nicht?

_________________

CMS in Python: http://www.pylucid.org
GitHub | ohloh Profil
1JEgSQepxGjdprNedC9tXQWLpS424AL8cd


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 10:00 
User

Registriert: Montag 19. November 2007, 20:57
Beiträge: 3018
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.

  1.     class Layout(models.Model):
  2.         name = models.CharField(max_length=100)
  3.         text = models.TextField()
  4.  
  5.     class Page(models.Model):
  6.         parent = models.ForeignKey("self", related_name="child_set")
  7.         position = models.IntegerField(default=0)
  8.         url = models.CharField(max_length=100)
  9.         title = models.CharField(max_length=200)
  10.         layout = models.ForeignKey(Layout)
  11.         meta = models.MetaField()
  12.  
  13.     class Story(models.Model):
  14.         master = models.ForeignKey(Page, null=True)
  15.         title = models.CharField(max_length=200)
  16.         text = models.TextField()
  17.         teaser_title = models.CharField(max_length=200)
  18.         teaser_text = models.TextField()
  19.         meta = models.MetaField()
  20.  
  21.     class PageStory(models.Model):
  22.         page = models.ForeignKey(Page)
  23.         story = models.ForeignKey(Story)
  24.         aspect = models.CharField()
  25.         position = models.IntegerField(default=0)
  26.         layout = models.ForeignKey(Layout, null=True)
Highlighting by GeSHi


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.

  1.     class Page...
  2.         @classmethod
  3.         def root(cls):
  4.             return Page.objects.get(url="")
  5.        
  6.         @classmethod
  7.         def from_url(cls, url):
  8.             page = cls.root()
  9.             if url:
  10.                 for segment in url.split("/"):
  11.                     try:
  12.                         page = page.child_set.get(url=segment)
  13.                     except Page.NotFound:
  14.                         return None
  15.             return page
  16.  
  17.     def show(request, url):
  18.         page = Page.from_url(url)
  19.         if not page:
  20.             raise Http404
  21.         t = Template(page.layout.text)
  22.         return HttpResponse(t.render(Context({'page': page})))
Highlighting by GeSHi


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


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 10:16 
Moderator
Benutzeravatar

Registriert: Dienstag 10. August 2004, 10:40
Beiträge: 7544
Wohnort: duisburg
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)

_________________

CMS in Python: http://www.pylucid.org
GitHub | ohloh Profil
1JEgSQepxGjdprNedC9tXQWLpS424AL8cd


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 10:33 
User

Registriert: Dienstag 6. November 2007, 22:49
Beiträge: 862
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.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 10:41 
Moderator
Benutzeravatar

Registriert: Dienstag 10. August 2004, 10:40
Beiträge: 7544
Wohnort: duisburg
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...

_________________

CMS in Python: http://www.pylucid.org
GitHub | ohloh Profil
1JEgSQepxGjdprNedC9tXQWLpS424AL8cd


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 10:46 
User

Registriert: Montag 19. November 2007, 20:57
Beiträge: 3018
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


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 10:54 
User

Registriert: Montag 19. November 2007, 20:57
Beiträge: 3018
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


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 11:00 
User

Registriert: Dienstag 6. November 2007, 22:49
Beiträge: 862
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...


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Mittwoch 9. September 2009, 11:00 
Moderator
Benutzeravatar

Registriert: Dienstag 10. August 2004, 10:40
Beiträge: 7544
Wohnort: duisburg
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...

_________________

CMS in Python: http://www.pylucid.org
GitHub | ohloh Profil
1JEgSQepxGjdprNedC9tXQWLpS424AL8cd


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 10. September 2009, 18:04 
User

Registriert: Samstag 5. Februar 2005, 18:53
Beiträge: 774
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*


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 10. September 2009, 18:33 
Python-Forum Veteran

Registriert: Freitag 4. August 2006, 12:29
Beiträge: 5746
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.

_________________
Freiheit ist immer die Freiheit der Andersdenkenden. (Rosa Luxemburg) — Blog, Twitter, GitHub


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 10. September 2009, 21:00 
User

Registriert: Dienstag 6. November 2007, 22:49
Beiträge: 862
@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.


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.

Suche nach:
Gehe zu:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Deutsche Übersetzung durch phpBB.de