vor einem reichlichen Monat (27.11.2006) hatte sich Ted (der Projektleiter von CMS made simple) zu der Zukunft von CMS made simple geäußert. Da sich relativ drastische Änderungen für CMSms abzeichnen, hab ich mich an eine Übersetzung gemacht (die aus Zeitmangel erst jetzt fertig geworden ist). Eventuell technisch ungenaue Übersetzungen seien mir im Sinne des besseren Allgemeinverständnisses verziehen
.Das Original kann hier
http://forum.cmsmadesimple.org/index.ph ... 387.0.html
nachgelesen werden.
Wie ihr sicherlich bereits wisst, läuft die Entwicklung der Version 1.1 bereits auf vollen Touren. In den letzten Wochen habe ich damit begonnen, den Grundstein für die künftige Entwicklung zu legen. Da gibt es eine Menge zu tun.
Ich möchte euch hier nach Abstimmung mit allen CMSms-Entwicklern informieren, welchen Weg CMSms nehmen wird. Einige der Änderungen sind drastisch, aber notwendig, um dieses Projekt in das Reich der "big boys" zu führen.
Ok, #1 und die drastischste ... CMSms 1.1 wird eine Technologie namens ORM verwenden. Für die Nichtprogrammierer: ORM meint Object-Relational-Mapping (O/R-Mapping) und bezeichnet die Abbildung von objektorientierten Daten auf relationale Daten. Damit wird es möglich, eine Datenbanktabelle als ein Objekt anzusprechen. Dies hat zur Folge, dass einige Sachen wie zum Beispiel die Speicherung in der Datenbank automatisch erledigt werden, ohne dass der Code mit hunderten SQL-Anweisungen “verunreinigt” wird.
Als ich ORM unter php4 und php5 lauffähig machen wollte, fand ich einige Fehler in php4. Diese Fehler sind jedoch im PHP-Bug-Tracker als “werden nicht behoben” gekennzeichnet. Mit anderen Worten ... entweder, der Code, den ich bislang programmiert habe, war umsonst, oder es muss eine harte Entscheidung getroffen werden.
Ich habe mich für die zweite Variante entschieden. Ab Version 1.1 wird CMSms nur noch unter php5 lauffähig sein. Ich weiß, das ist eine sehr harte Entscheidung, da php4 bei den meisten Providern noch der Normalfall ist. Ich gehe damit zwar ein Risiko ein, aber ich bin davon überzeugt, dass das die richtige Entscheidung war. Es ist relativ wahrscheinlich, dass die Provider nach und nach auf php5 aktualisieren. Und es wäre falsch, fehlerhaften Code in ein fehlerhaftes System einzufügen, nur weil entschieden wurde, diese Fehler nicht zu beheben. CMSms soll ein modernes, stabiles System sein. Je weiter sich CMSms entwickelt, desto schwieriger wird es, es unter älteren Versionen lauffähig zu bekommen.
Nebenbei bemerkt, andere Systeme haben diesen Sprung bereits gewagt. Zum Beispiel ist Mediawiki (die von Wikipedia eingesetzte Software) bereits seit Version 1.8 nur unter php5 lauffähig.
1.0.x bleibt solange in der "Wartung" (und damit in der Unterstützung), bis php5 seinen Weg zu den meisten der großen Provider gefunden hat. Ich hoffe, dass das nicht länger als 1 Jahr dauern wird.
Einige der 1.1er Änderungen werden auch für die Versionen 1.0.x verfügbar sein. Es ist jedoch ziemlich wahrscheinlich, dass sich dies auf Fehlerkorrekturen beschränkt (keine Weiterentwicklung).
Das wird unser Weg sein. Der Rest der Neuigkeiten ist gut, ich schwöre. Weiter im Text ...
#2. Seit der Version 0.9 ist es geplant, das Content-System neu zu schreiben. Dies ist zum Großteil erledigt. Die neue Version des Content-Systems funktioniert genau so wie in der aktuellen Version, aber die Verwendung von ORM ermöglicht wesentlich schlankeren und weniger komplizierten Code. Die Programmierung neuer Inhaltstypen ist jetzt aufgrund der Verwendung von Smarty-Templates wesentlich einfacher.
Im neuen Contentsystem wurde auch die Behandlung mehrerer Inhaltsblöcke überarbeitet. Derzeit sind die Inhaltsblöcke lediglich für HTML-Text ausreichend. Diese Beschränkung wurde meiner Erinnerung nach mit der Version 0.7 oder 0.8 eingeführt.
Künftig sind für jeden Content-Block verschiedene Inhaltstypen möglich, welche bei Bearbeitung der Seite separat ausgewählt werden können.
In der Version 1.1 werden verschiedene Blocktypen mitgeliefert. Der Standard wird HTML sein und funktioniert wie der bereits bekannte Inhaltstyp “content”. Für jeden Block kann ein WYSIWYG-Editor (oder keiner, falls es deaktiviert wurde) festgelegt werden. Aber es werden noch einige neue Typen hinzukommen ... Markdown-Text und Images, um nur zwei davon zu nennen. Es wird möglich sein, für jeden content-Block einen Standard-Typ festzulegen ({content type='image' name='ein_bild'}) und dies auch so zu fixieren, dass diese Zuweisung von den Editoren nicht mehr geändert werden kann. Damit obliegt die Festlegung der Blocktypen einzig und allein dem Template-Designer.
Das Hinzufügen eines neuen Inhaltstypen wird sich vereinfachen, wovon auch Module profitieren. So wird auch der Inhaltstyp “News” in einen Blocktyp umgewandelt, so dass nicht die ganze Seite für die Auflistung von News benötigt wird.
#3. TinyMCE wird der neue Standard-WYSIWYG-Editor. Da der FCKEditor unnötig aufgeblasen ist und mehr enthält, als für die Arbeit mit CMSms notwendig ist, wird TinyMCE der neue Standard-WYSIWYG-Editor. Der FCK-Editor bleibt jedoch über den Modul-Manager verfügbar.
#4. Versionierung wird in der Version 1.1 enthalten sein und kann als Option aktiviert werden. Das heisst, alle früheren Versionen der verschiedenen Inhalte, Templates und Stylesheets werden gespeichert, wodurch es möglich wird, diese bei Bedarf auf ältere Versionen zurückzusetzen. Die programmtechnische Umsetzung ist bereits klar, nur für das Interface habe ich noch keinen Anhaltspunkt. Über Anregungen würde ich mich freuen.
#5. Versionierung bedeutet auch, dass sich Arbeitsabläufe einfach steuern lassen. Es ist noch nicht entschieden, ob diese Funktionen im Core oder als Modul realisiert werden. Aber grundsätzlich bedeutet das, dass Bearbeiter Änderungen an einer Seite vornehmen können, die jedoch von einem Administrator freigegeben werden müssen. Dies ist ein bisschen knifflig und bedarf einiger „Datenbank-Gymnastik“, um es in einer annehmbaren Geschwindigkeit zu realisieren. Auch hier sind eure Ideen willkommen.
#6. Mehrsprachigkeit. Dies wird voraussichtlich in der Version 1.1 verwirklicht werden. Katon und ich haben einen Weg gefunden, das Multilanguage-System als ein separates Subsystem auszuführen, was von anderen CMSms-Teilen einfach genutzt werden kann, ohne deren Strukturen großartig zu verändern. Katon sprach davon, dies noch vor Veröffentlichung der Version 1.1 als Erweiterung für die Versionen 1.0.x zu programmieren. Ich bin mir nicht ganz sicher, ob der zeitliche Rahmen dafür ausreicht, aber er hat definitiv seine Hilfe für die Implementierung zugesagt.
Das sind nur die Änderungen, über die ich am besten Bescheid weiß. Der Rest des Entwicklerteams arbeitet an anderen Funktionen wie etwa die Überarbeitung des Berechtigungssystems (calguy1000) oder der Ersatz der Datei- und Bildverwaltung durch neu geschriebene Module (silmarillion).
Vielen Dank für eure Geduld. Die Veröffentlichung der Version 1.1 ist für Ende des ersten Quartals 2007 geplant, die Betas natürlich etwas eher ...
. Ich hab mir den aktuellen SVN-Stand mal installiert und kann nichts erkennen, was dem entgegen steht. Smarty bleibt Smarty. Am Templatesystem wird es keine Änderung geben. Also sollten im Normalfall die Templates wie gehabt funktionieren. Im Gegenteil - auch in der Administration wird immer mehr Smarty eingesetzt, so dass auch die optisch angepasst werden kann.
.
- Tiny war bereits bis zur 0.10 der mitgelieferte Standard-Editor.