WeizenSpr.eu

« | »

Content Management System Brooke.cc

Ich habe diese Woche damit verbracht, mir einen Überblick darüber zu verschaffen, was das zukünftige Content Management System später leisten soll und worauf besonders Wert gelegt werden soll. Kurz um: Ich habe eine Feature-Liste erarbeitet. Auf Basis dieser Feature-Liste sollen das technische Feinkonzept und das Sicherheitskonzept entstehen. Beides werde ich in einem großen, umfassenden Dokument beschreiben. (Ja, normalerweise kommt erst ein Lastenheft, dann ein Pflichtenheft, dann ein technisches Grobkonzept, dann ein technisches Feinkonzept und abschließend ein Sicherheitskonzept. Da ich jedoch mein eigener Kunde bin, komme ich gleich zum Knackpunkt.)

Einen Namen für das CMS habe ich nun übrigens auch gefunden. Eigentlich hatte ich ja "SecWCMS" im Kopf, aber ehrlich gesagt fand ich den Namen schlussendlich doch doof. Ich habe mich deshalb für den Namen Brooke.cc entschieden. Brooke ist ein meist weiblicher Vorname, heißt so viel wie Fluss oder Bach und soll den Informationsfluss, der durch ein CMS entsteht, symbolisieren. Außerdem erinnert mich das Wort sehr an "book" (dt. "Buch"), zudem beginnt es mit "br", dem HTML-Tag für Zeilenumbrüche. Das ".cc" der Domain habe ich übrigens mit in den Namen aufgenommen. "CC" steht bei E-Mails ja angeblich für "Carbon Copy". Meiner Meinung nach irgendwie passend für ein OpenSource-Projekt. :-)

Hier also die von mir zusammengestellten Anforderungen:

So, das ist doch mal eine ganz annehmbare Liste für ein kleines CMS. Sollten euch noch weitere Funktionen einfallen, die ein CMS unbedingt benötigt, dann hinterlasst diese doch bitte in den Kommentaren. :-)

Managende Grüße, Brooke Kenny

Posted by on 13. Januar 2012.

Categories: Brooke.cc

16 Responses

  1. Hm, klingt eher nach Pornoseite, aber ok. Das mit dem Fluß wird trotzdem keiner schnallen. Das cc auch nicht. :-)

    die Rollen Administrator, Moderator, Autor und Besucher sollen strikt getrennt werden

    Als Richtlinie ok, aber das muss besser definierbar sein. (sowas wie der Capability Manager) Das nervt mich ungemein in WordPress, dass es zwar ein Rechtesystem gibt, aber dass man das nur durch Plugins feinjustieren kann.

    in Kommentaren soll BB-Code verwendbar sein

    Warum nicht html? BB Code ist Mist. Mich nervt es hier schon, dass ich nicht richtig zitieren kann.

    die Anwendung soll keine E-Mails versenden

    Wie meinen? Generell oder sollen nur keine Passwörter verschickt werden?

    es soll dynamisch zwischen verschiedenen Designs umschaltbar sein (z.B. ein Desktop- und Mobil-Design)

    Themes meinst Du? Desktop und Mobil ist keine gute Idee wegen Barrierefreiheit.

    für Besucher soll eine Statistik erzeugt werden, die ohne Speicherung der IP des Besuchers auskommt (abschaltbare)

    Wie willst Du die denn auseinander halten ohne IP (und ohne Sessions)?

    Bei PHP/MySQL solltest Du Mindestversionen angeben, wenn Du auf Sicherheit wert legst. Vor allem bei PHP mindestens 5.3 (auch wegen z. B. crypt/bcrypt).

    by Oliver on Jan 13, 2012 at 23:27

  2. Als Richtlinie ok, aber das muss besser definierbar sein. (sowas wie der Capability Manager) Das nervt mich ungemein in WordPress, dass es zwar ein Rechtesystem gibt, aber dass man das nur durch Plugins feinjustieren kann.

    Die Rollen sollen fest vorgegeben sein. Bei den Autoren soll ein bisschen Spielraum bestehen, was die Sichtbarkeit fremder Artikel angeht, aber eine Feinjustierung wie sie der von dir angesprochene Capability Manager bietet, ist IMHO absoluter Overkill.
    Das ist sicherlich auch ein bisschen die Erfahrung. Kaum jemand macht sich die Mühe, haarklein sämtliche Berechtigungen von Rollen auszudefinieren. Da im Falle von Brooke.cc auch entsprechende DB-Nutzer an jeder Rolle hängen, wäre es obendrein schwierig, dies überhaupt technisch sauber umzusetzen.

    Warum nicht html? BB Code ist Mist. Mich nervt es hier schon, dass ich nicht richtig zitieren kann.

    Das hat einen ganz einfachen Grund: BB-Code verringert die Möglichkeiten, die jemand nutzen kann, um User-Generated Content in eine Seite zu bringen, ohne, dass der Nutzer dies großartig merkt. Wenn man anfängt zu sagen "Du darfst aber nur die Tags benutzen und obendrein nur diese Attribute.", dann versuchen die Leute aus diesem Schema auszubrechen. Bei einer anderen Metasprache ist dies nicht der Fall. Dass man aber auch dort Probleme haben kann, habe ich heute gemerkt. Einfaches Beispiel: Klick mich!

    Wie meinen? Generell oder sollen nur keine Passwörter verschickt werden?

    Die Anwendung selbst soll generell keine E-Mails verschicken. Sie soll nicht einmal den Code dafür enthalten. Wenn E-Mails wegen irgendwas verschickt werden sollen (z.B. wegen neuen Kommentaren in der Moderationsqueue), dann soll das extern über Cronjobs erledigt werden. Die Gefahr bei Mailfunktionen in Software ist immer, dass der dort eingetragene Empfänger überschüttet wird (z.B., wenn der Spamfilter ausgehebelt wird). Das soll verhindert werden.

    Themes meinst Du? Desktop und Mobil ist keine gute Idee wegen Barrierefreiheit.

    Ja, man könnte es als Theme bezeichnen. Desktop und Mobil war lediglich ein Beispiel, da ich diese Trennung derzeit selbst nutze (siehe desktop.weizenspr.eu und mobile.weizenspr.eu). Warum dies aufgrund der Barrierefreiheit keine gute Idee sein soll, kann ich persönlich nicht nachvollziehen.

    Wie willst Du die denn auseinander halten ohne IP (und ohne Sessions)?

    Die Idee war Hash(IP + User-Agent + Datum + Salt) abzuspeichern. So kann ich ein und denselben User-Agenten von einer IP tagesweise auseinander halten, ohne die IP selbst speichern zu müssen. Finde die Idee schon ein bissel clever.

    Bei PHP/MySQL solltest Du Mindestversionen angeben, wenn Du auf Sicherheit wert legst. Vor allem bei PHP mindestens 5.3 (auch wegen z. B. crypt/bcrypt).

    Das macht meines Erachtens nach nicht wirklich Sinn. Natürlich kann man eine Mindestversion empfehlen - erzwingen sollte man sie allerdings nicht. Und da die Versionsempfehlung sowieso "die neuste" ist, ist auch solch ein Vorgehen nicht wirklich sinnvoll.

    by Kenny on Jan 14, 2012 at 02:13

  3. aber eine Feinjustierung wie sie der von dir angesprochene Capability Manager bietet, ist IMHO absoluter Overkill.

    Ja, man kann ja die Rollen nutzen und darüber Standardeinstellungen definieren. Aber wäre schon cool, wenn einzelne Aktionen auch von anderen Usern gemacht werden dürfen oder halt auch nicht. Das muss ja nicht Overkill sein, wenn man z. B. sagen kann, User XY ist grundsätzlich Autor, kann aber auch die Kommentare in seinen Artikeln bearbeiten oder seine eigenen Artikel nicht bearbeiten. WordPress kann das ja, aber man kann es halt nur über Tricks einstellen.

    BB-Code verringert die Möglichkeiten, die jemand nutzen kann, um User-Generated Content in eine Seite zu bringen. Wenn man anfängt zu sagen “Du darfst aber nur die Tags benutzen und obendrein nur diese Attribute.”, dann versuchen die Leute aus diesem Schema auszubrechen.

    Ja und nein, hast Du ja auch schon gemerkt. Für Tags/Attribute gibt es sehr gute Klassen, die man nutzen kann. Die sind halt durch Erfahrung schon sehr sicher. Ich seh das immer wieder, das manche Probleme haben [ und ] zu schreiben. geht meistens noch besser.

    Da im Falle von Brooke.cc auch entsprechende DB-Nutzer an jeder Rolle hängen, wäre es obendrein schwierig, dies überhaupt technisch sauber umzusetzen.

    Ich würde das wirklich noch mal überdenken. Du bekommst erstens Probleme mit Hostingpaketen mit einem DB User und ich seh auch nicht den Vorteil. Die meisten SQL Attacken versuchen ja nicht zu schreiben, sondern zu lesen. Aber jeder Besucher muss auch schreiben können.

    Dann bleibt noch das Anlegen von prepared statements, aber das willst Du ja eh auf php seite machen. Also was bleibt dann noch? Im laufenden Betrieb legt für gewöhnlich auch keine Tabellen an, die Rechte benötigt ein User also nicht. Du kannst auch keine Rechte auf Tabellen legen, also wie unterscheidet sich dann der Adminuser noch vom normalen Besucher? Die Zugangsdaten für alle Benutzer müssen auch im Quelltext stehen.

    Die Gefahr bei Mailfunktionen in Software ist immer, dass der dort eingetragene Empfänger überschüttet wird (z.B., wenn der Spamfilter ausgehebelt wird). Das soll verhindert werden.

    Welches aktuelle Blog/Forum/CMS hat denn das Problem? Cronjobs haben einen großen Nachteil, sie arbeiten nicht in Echtzeit und wenn irgendein Problem auftritt, blockiert Dir die komplette Mailqueue und vermutlich merkst Du es noch nicht mal und der User auch nicht. Und Cronjobs ohne eigenen (V)Server gibt es fast nicht.

    Warum dies aufgrund der Barrierefreiheit keine gute Idee sein soll, kann ich persönlich nicht nachvollziehen.

    Das ergibt sich aus der BITV: Soweit auch nach bestem Bemühen die Erstellung eines barrierefreien Internetangebots nicht möglich ist, ist ein alternatives, barrierefreies Angebot zur Verfügung zu stellen, dass äquivalente Funktionalitäten und Informationen gleicher Aktualität enthält, soweit es die technischen Möglichkeiten zulassen. Bei Verwendung nicht barrierefreier Technologien sind diese zu ersetzen, sobald aufgrund der technologischen Entwicklung äquivalente, zugängliche Lösungen verfügbar und einsetzbar sind.

    Trifft aber hier nicht zu. Themes ja, alternative Versionen nicht.

    Die Idee war Hash(IP + User-Agent + Datum + Salt) abzuspeichern.

    Also Sessions?! :-)

    Natürlich kann man eine Mindestversion empfehlen – erzwingen sollte man sie allerdings nicht.

    Willst Du das ganze noch auf PHP 5.2 runter schrauben und testen? PHP 5.3.0 kam im Juni 2009, also vor 2 1/2 Jahren. Der Support für 5.2 ist ausgelaufen. Das sollte eigentlich keine Einschränkung mehr sein (ich weiß, 1und1 hat es noch), z. B. bei den crypt Funktionen zum hashen bist Du auf das Betriebssystem angewiesen. Wenn das einer auf Windows installiert bye bye bcrypt. Namespaces sind auch ne schöne Sache und natürlich immer wieder der Sicherheitsaspekt.

    BTW: Ich nörgel nicht, ich will nur helfen. :-)

    by Oliver on Jan 14, 2012 at 03:09

  4. Ja und nein, hast Du ja auch schon gemerkt. Für Tags/Attribute gibt es sehr gute Klassen, die man nutzen kann. Die sind halt durch Erfahrung schon sehr sicher. Ich seh das immer wieder, das manche Probleme haben [ und ] zu schreiben. geht meistens noch besser.

    Das ist der Knackpunkt. Die Software soll nicht "durch Erfahrung sehr sicher sein", sondern weil ein stringentes Sicherheitskonzept verfolgt worden ist. Durch Erfahrung ist auch WordPress sicher, aber das reicht mir persönlich eben nicht aus.

    Ich würde das wirklich noch mal überdenken. Du bekommst erstens Probleme mit Hostingpaketen mit einem DB User und ich seh auch nicht den Vorteil. Die meisten SQL Attacken versuchen ja nicht zu schreiben, sondern zu lesen. Aber jeder Besucher muss auch schreiben können.

    Sollte wirklich jemand ein Hostingpaket benutzen und dementsprechend nicht die Möglichkeit haben, sämtliche Sicherheitsfeatures zu nutzen, dann muss er die entsprechenden zusätzlichen Sicherungen abschalten - dann aber auf die Gefahr hin, dass die Software nicht mehr den vollen Schutz entfalten kann. Das ist so wie beim Häuserbauen - man kann das ganze schon sehr stabil machen, aber wenn man hier eine Mauer und dort eine Mauer entfernt, wird es irgendwann instabil.

    Die Aussage ist zudem so nicht ganz korrekt. Viele Angriffe auf WordPress versuchen z.B., einen (möglichst versteckten) Admin-Zugang anzulegen oder aber das Passwort des bestehenden Admins zu überschreiben. Das ist auch sinnvoll, weil wozu soll man sich abmühen, von außen X spezielle Angriffsschritte auszuführen, wenn man sich auch einfach irgendwann den Admin-Zugang besorgen kann (was bei gehashten Passwörtern ohne Schreiben recht schwierig ist)?
    Auch danach ist, vor allem bei einem CMS, das Hauptaugenmerk das Schreiben. Genauer gesagt, das Verbreiten von Schadcode und/oder Spam. Das ist meist relativ einfach, weil der Admin automatisch Artikel verfassen darf und selbst ein Besucher von außen schreibenden Zugriff auf die Artikeldatenbank erlangen kann.
    Deswegen auch hier die strikte Trennung, Administratoren sollen nur administrieren, Besucher dürfen eh kaum was und selbst Autoren dürfen keine Inhalte veröffentlichen - das unterliegt ausschließlich dem Moderatoren. Die Autoren dürfen nur Artikelvorschläge einreichen, die anschließend geprüft, potentiell überarbeitet und erst anschließend von einer anderen Instanz veröffentlicht werden.

    Vor allem in diesem Bereich habe ich mir schon einige Gedanken gemacht. Genauer gesagt, habe ich für eine Studienarbeit ein Framework erdacht und geschrieben, das genau diese datenbank-basierte Sicherung verwaltet. Ich werde dieses Framework zwar nicht direkt verwenden (dafür habe ich in den letzten Jahren zu viel neues gelernt), aber die Absicherung des CMS wird auf den früheren Arbeiten aufbauen. Es wird wahrscheinlich verständlicher, wenn die Sicherheitsanteile des Konzeptes fertig sind.

    Dann bleibt noch das Anlegen von prepared statements, aber das willst Du ja eh auf php seite machen. Also was bleibt dann noch? Im laufenden Betrieb legt für gewöhnlich auch keine Tabellen an, die Rechte benötigt ein User also nicht. Du kannst auch keine Rechte auf Tabellen legen, also wie unterscheidet sich dann der Adminuser noch vom normalen Besucher? Die Zugangsdaten für alle Benutzer müssen auch im Quelltext stehen.

    Richtig, Prepared Statements sind ein Standardweg. Es ist auch richtig, dass im laufenden Betrieb nur sehr selten neue Tabellen angelegt werden - meistens dann, wenn eine aktualisierte Software neue Daten ablegen muss, oder wenn komplett neue Software zum Einsatz kommt. Die Rechte benötigt ein Nutzer (genauer gesagt der Admin) also schon.
    Die Aussage, dass man keine Rechte auf Tabellen legen kann, ist mir persönlich nicht verständlich - natürlich geht das! Genau das ist eins DER Sicherheitsfeatures im DB-Umfeld. MySQL MyISAM kennt leider keine Rollen, dadurch fällt RBAC (= Role Based Access Control) aus, IBAC (= Identity Based Access Control) ist jedoch möglich. Es ist prinzipiell sogar möglich, den lesenden Zugriff auf Daten auf eine View zu beschränken und nur das Einfügen (aber nicht das Updaten) von Daten zu ermöglichen. So kann man Admins von Besuchern unterscheiden. Die Idee ist, dass die verschiedenen Rollen nur die Daten sehen können, die sie benötigen und auch nur die Daten schreiben können, die sie auch dürfen. Oder anders ausgedrückt: Selbst, wenn jemand die vollständige Anwendung hackt, soll er nicht mehr mit den Daten machen können, als er auch über die Oberfläche hätte machen können.
    Es ist schon richtig, dass sich die Zugangsdaten der verschiedenen DB-Nutzer im Quelltext befinden müssen. Aber wer sagt denn, dass es sich um einen einzelnen Quelltextbaustein handeln muss? Das ist mit strikter Trennung der Rollen gemeint. Jede der Rollen soll ihren eigenen Zugang zum System erhalten. Es soll z.B. möglich sein, den Quelltext, der den Zugang für den Admin ermöglicht, einfach zu löschen (oder aber z.B. über eine andere Domain zugänglich zu machen). So, dass sollte der Quelltext kompromitiert werden, immernoch nicht die Admin-, Autoren- oder Moderatoren-Zugänge freigelegt werden, da diese entweder gelöscht wurden oder sich auf einem anderen (z.B. virtuellen) Host befinden.

    Welches aktuelle Blog/Forum/CMS hat denn das Problem? Cronjobs haben einen großen Nachteil, sie arbeiten nicht in Echtzeit und wenn irgendein Problem auftritt, blockiert Dir die komplette Mailqueue und vermutlich merkst Du es noch nicht mal und der User auch nicht. Und Cronjobs ohne eigenen (V)Server gibt es fast nicht.

    Nehmen wir mal meinen Blog als Beispiel. Ich habe Glück, dass ich einen Spamfilter einsetze, ansonsten würde ich jeden Tag zwischen 600 und 900 entsprechende Mails bekommen. Warum ich sie nicht bekomme? Weil es bisher nur wenige Bots gibt, die den Spamfilter umgehen können - aber wer sagt, dass das so bleibt?
    Um Leuten ohne V-Server das Leben zu erleichtern, könnte man (wie in WordPress) eine Art Cron in der Software implementieren. Diese könnte dann das entsprechende Script aufrufen.
    Das Script wiederum könnte dann eine Sammlung von unveröffentlichten Kommentaren rausschicken (z.B. 1x die Stunde oder 1x am Tag). Man könnte das Versenden des Reports (auch, wenn keine neuen Kommentare da sind) erzwingen, sodass man erkennt, sobald der Cronjob nicht mehr korrekt läuft. Man merkt übrigens auch nicht, wenn beim derzeitigen Vorgehen, etwas schief geht - weil auch dort dann keine Mails mehr ankommen.

    Das ergibt sich aus der BITV [...]

    Nun das große aber: In der Vorschrift geht es um nicht-barrierefreie Auftritte. Eine normale Website wird allgemein als barrierefrei angesehen. Dass diese ihr Aussehen je nach Client anpasst, ändert daran IMHO nichts. Denn auch dieses zweite Aussehen ist wieder barrierefrei. Hier geht es AFAIK um die Dinge wie notwendiges JavaScript (wird es nicht geben) oder sogar Auswüchse wie Flash-Webseiten.

    Also Sessions?! :-)

    Sessions im allgemeinen Sinne (Session-ID wird im Cookie gespeichert und auf dem Server mit weiteren Laufzeit-Informationen verknüpft) nicht, nein. Dass hier (ohne Zutun des Clients) eine Art Session entsteht, ja.

    Willst Du das ganze noch auf PHP 5.2 runter schrauben und testen?

    Erst einmal muss ich sehen, was ich alles benötige und anhand dessen sehe ich ja dann, ob die Software noch mit PHP 5.2 kompatibel sein wird. Als Plattform angestrebt ist es jedenfalls nicht.

    by Kenny on Jan 14, 2012 at 13:32

  5. Die Idee ist, dass die verschiedenen Rollen nur die Daten sehen können, die sie benötigen und auch nur die Daten schreiben können, die sie auch dürfen.

    Jetzt weiß ich, was Du meinst, aber dann musst Du einfachen Usern z. B. verbieten ihr Passwort zu ändern!? Oder soll man sich gar nicht anmelden können? So lange es optional ist, ist es aber auch egal.

    Ich habe Glück, dass ich einen Spamfilter einsetze, ansonsten würde ich jeden Tag zwischen 600 und 900 entsprechende Mails bekommen.

    Bitte? Wieso? Von WordPress?

    Hier geht es AFAIK um die Dinge wie notwendiges JavaScript (wird es nicht geben) oder sogar Auswüchse wie Flash-Webseiten.

    Nee, aber Ziel der BITV ist es EINE Internetseite für alle zugänglich zu machen und da sind alternative Auftritte auf Basis der Clients möglich, aber nicht erwünscht. Eine Seite muss schon wesentlich mehr leisten als nur ohne JS auszukommen. :-)

    Ach und kannst Du mal ein blockquote einbauen? und größer/kleiner Zeichen nicht einfach raus filtern. :-)
    Und was ist eigentlich mit dem Artikel. *Schlechtes-Gewissen-anmelden*

    by Oliver on Jan 14, 2012 at 14:27

  6. Jetzt weiß ich, was Du meinst, aber dann musst Du einfachen Usern z. B. verbieten ihr Passwort zu ändern!? Oder soll man sich gar nicht anmelden können? So lange es optional ist, ist es aber auch egal.

    Wozu sollte sich ein normaler CMS-Besucher anmelden können? Diese Not sehe ich persönlich nicht. Wer sich anmelden (und sein Passwort ändern) können muss, sind Autoren, Moderatoren und Administratoren. Das Ändern ist in der Tat spannend, denn dazu bräuchte man, theoretisch, Update-Rechte auf der User-DB. Theoretisch, denn praktisch kann man Änderungen auch per Insert lösen. Der aktuellste Datensatz entspräche dann dem neusten Passwort. Ein Risiko bleibt dabei bestehen, nämlich, dass jemand das Passwort eines anderen Nutzers überschreibt, der die gleichen Rechte wie man selbst besitzt. Ja, dieses datenbankseitige Risiko besteht und wird lediglich durch Software-side Security verhindert. Die Frage, die sich allerdings stellt, ist, in wieweit es sinnvoll ist, sich bei einem Einbruch Zugriff auf einen Account zu verschaffen, der die gleichen Rechte besitzt, wie man selbst.

    Bitte? Wieso? Von WordPress?

    Ja klar! Für jeden Kommentar erhalte ich von WordPress eine E-Mail - mit Ausnahme von Kommentaren, die als Spam markiert worden sind.

    by Kenny on Jan 14, 2012 at 17:12

  7. Dein Blog hat 600 bis 900 Kommentare am Tag?

    by Oliver on Jan 14, 2012 at 22:22

  8. Mein Blog hat täglich 600-900 Spamkommentare. Würden sie nicht als Spam erkannt werden, dann würde jeder einzelne davon das Versenden einer Info-Mail verursachen.

    by Kenny on Jan 15, 2012 at 23:07

  9. Ich mag diese kleinen alternativen Syteme. Die haben oft nur wenige Funktionen, sind dafür allerdings nicht so überladen wie ein Joommla mit 15 Komponenten, Modulen und Plugins. Das ist gerade für Endkunden, die auch keine große Funktionsvielfalt benötigen, optimal.

    by Tim on Jan 19, 2012 at 15:04

  10. ich würde dir empfehlen dich nochmal komplett neu umzusehen, deine ideen sind nicht stand der dinge, das sind fast alles punkte die seit ~5 jahren out-of-date sind. du sagtest du legst wert auf sicherheit, kannst du nochmal ganz kurz und knapp zusammenfassen was deine software sicher machen soll?

    by jens on Jan 21, 2012 at 22:41

  11. Verzeihe mir bitte, wenn ich ungläubig gluckse, aber welche der Punkte sind denn bitte seit ~5 Jahren "out-of-date"? Strikte Rollentrennung? Sichere Passwortablage? Datenschutzkonformes Logging? Spamfilter? Die Verwendung einer Template-Engine? Die Kategorisierung von Inhalten? Die Kommentierbarkeit von Inhalten? Oder etwa das erstellen von Konzepten? Falls du mir die ("fast alle") Punkte, die "out-of-date" sind, nicht nennen willst, sage mir doch bitte wenigstens, was heutzutage so "state-of-the-art" ist. Like-Buttons? Cloud-Computing?

    Das Konzept ist ziemlich simpel. Der Code für die einzelnen Rollen (Admin, Moderator, Autor, Besucher) soll vollständig getrennt sein. Jede Rolle bekommt einen eigenen DB-Nutzer mit den zur Aufgabe passenden Rechten. Das Ziel: Selbst, wenn du mit dem zur Rolle gehörigen DB-Nutzer direkt auf der DB arbeitest, sollst du nicht mehr können, als dir die GUI ermöglicht. As simple as that.

    by Kenny on Jan 22, 2012 at 02:22

  12. domain driven design?

    by bum on Jan 24, 2012 at 05:44

  13. "Domain-Driven Design" was? Was soll mir dieses hingeworfene Buzzword sagen? Mit der Anforderungsanalyse (nichts weiter ist das Auflisten der gewünschten Features) hat das dahinterstehende Thema jedenfalls nichts zu tun. Zumindest habe ich nicht erkennen können, dass bei DDD plötzlich keine Anforderungsanalyse mehr notwendig wäre.

    Und noch kurz zu DDD: Klingt für mich persönlich danach, als ob jemand versucht hat, Softwareentwicklungsprozess (V-Modell, Wasserfallmodell, etc.) und stark vereinfachtes UML in einen Topf zu schmeißen.

    by Kenny on Jan 25, 2012 at 23:02

  14. Das wäre hart :D

    by Micha on Jan 31, 2012 at 11:55

  15. Ohne mich nun durch 52,456KG Text zu wühlen: Warum ein neues CMS? Schonmal MODX angesehen? Vielleicht auch die advanced-Version davon?

    Schöne Grüße,
    @Cheatha

    by Cheatha on Feb 7, 2012 at 02:07

  16. Kleiner Vergleich.

    Brooke.cc: Prio 1 = "Umfassende Konzeption inkl. Sicherheitsbetrachtung" (Quelle)
    MODX: "Der Fokus liegt auf Usability, Design und Inhalt." (Quelle)

    by Kenny on Feb 7, 2012 at 08:28

Leave a Reply

« | »

Letzte Artikel

Seiten