Und warum überhaupt eine neue Template Engine, warum wurde kein Smarty verwendet?
Ansonsten sind die Infos zur Technik (DB-Layer, Structur, Besonderheiten) des Systems sowohl in der News wie auch auf der HP mehr als dürftig. Ja die News bietet fast sogar noch mehr als die HP
>Und warum überhaupt eine neue Template Engine, warum wurde kein Smarty verwendet?
Wir haben uns gegen die Verwendung von Smarty entschieden um flexibler auf ggf. auftretende Probleme im Zusammenhang mit dem CMS reagieren zu können und um gewisse Besonderheiten, wie zum Beispiel den standardmäßigen ThickBox Support, den eingebauten Sprachen-Umschalter oder die Kommentarfunktion (noch nicht im aktuellen Release enthalten), besser implementieren zu können. Des Weiteren unterstützt Smarty meines Wissens nach kein zwischenspeichern von generierten Seiten. Das war aber ein Ziel unserer Engine um auf großen Seiten mit hohen Besucherzahlen die Serverlast zu reduzieren.
Dem Kritikpunkt der mangelnden Informationen zur Technik muss ich mir auf jedenfall gefallen lassen. Das wissen wir im Team auch selber und arbeiten auch momentan daran, die Dokumentationen zu erweitern und unsere Entwicklung transparenter zu gestalten. Bei der Neuentwicklung (0.5.0) soll jedoch dies deutlich besser gemacht werden und sowohl der Code soll besser kommentiert, als auch die externen Dokumentationen sollen ausführlicher werden.
Smarty unterstützt das sogar sehr gut, mit ein grund warum es viele nutzen aber das nur so am rande, steht auch in den meisten allgemeinen Smarty beschreibungen. Es sollte auf jedenfall noch ein wenig an der Demo Seite geschraubt werden sieht zwar schon besser aus als die alte Startseite aber die DivŽs sind nicht wirklich alle so perfekt braucht ja nicht alles per div zu beschreiben.
ich glaube ihr solltet auf jedenfall noch mind. eine Seite auf eurer HP den Thema "Was machen wir", "Was machen wir anders" und "Technik" widmen. Das vermisse ich bei euch wirklich. Auch eure Demoseite ist noch etwas leer.
Die Punkte die du angesprochen hast wegen der Template Engine sollten mit Smarty aber kein Problem sein. Man kann bei Smarty vieles, auch absolute Grundfunktionen, mittels Funktionserweiterungen und co. ergänzen, ganz ohne den Smartycode zu verändern. Ich halte Smarty für eine wirklich gute Wahl.
Ich muss aber auch sagen das mir euer System vom Admin her sehr nach Mambo/Joomla aussieht. Ich erkenne nicht direkt die deutliche Vereinfachung im Vergleich dazu Außer vielleicht durch Funktionsverzeicht. Das ist zwar sicher ein Weg, aber da wäre vielleicht ein spezieller Joomla Release einfacher als ein ganzes CMS. Gibt halt schon sooo viele.
Ich denke von Smarty werden wir trotz allem die Finger lassen. Unsere Engine kann Smarty vielleicht nicht das Wasser reichen, aber wir wollen ungerne Fremdcode in das System aufnehmen. Allerdings wird sich einer unserer Entwickler mal genauer mit Smarty beschäftigen. Wer weiß, vielleicht bieten wir Smarty als Alternative an.
Zugegeben, das aktuelle Control Panel sieht Joomla! ziemlich ähnlich, ist allerdings eher unbeabsichtigt. Das wird sich aber auch mit der 0.5.0 ändern. Das Control Panel wird gaaaaanz anders aussehen als das jetzige. Mit der Einfachheit hast du momentan leider noch Recht. Punkte die uns wichtig sind wären zum Beispiel die Installation von Erweiterungen und Einbindung bestimmter Drittsystem (vBulletin zB) Weiterhin arbeiten wir derzeit an einem Artikelsystem für Newsseiten und weiteren Erweiterungen die TGS etwas vom Rest abheben sollen. Aber dazu kommt später auf unserer Seite noch eine ausführliche Nachricht.
Die Seite, die wie schon von mir erwähnt momentan mit einer uralten TGS Version läuft, wird in der nächsten Woche auf die 0.2.5r3 umgestellt und wird dann auch mehrsprachig. Weiterhin werden wir die Tabellen aus dem Design entfernen und allgemein einige Änderungen vornehmen. Unter anderem werden dann auch solche Informationsseiten, wie "Was machen wir", "Was ist TGS Content Management" usw. erstellt. Die Seite wird dann in Englisch, Japanisch, Holländisch und Deutsch verfügbar sein. Aber das ist momentan noch in der Mache!
Auf jedenfall danke für Eure Tipps und Eure Meinung zu unserem System. Vielen Dank und gruß Christoph
Der eine ruft nach Smarty der andere fragt sich warum nicht gleich richtiges XSL ... ich halte es durchaus für legitim an solchen Stellen eigene Mechanismen zu bauen, die dann für den Anwendungsfall optimiert sind.
Ich frage mich auch eher, was das Merkmal dieses CMS ist, daß es Sinn gemacht hat, ein neues System zu schreiben. Konzeptionslose CMS, die nicht mehr können als unflexible Dokumentenstrukturen irgendwie darzustellen, gibt es ja mehr als genug.
Auch würde ich mir wünschen, daß man bei Pro-Linux eine etwas schärfere Grenze zwischen Berichterstattung über und Eigenwerbung von Projekten erkennen könnte.
Es tut mir Leid, wenn Ihr das hier als Eigenwerbung versteht, darum ging es uns nun wirklich nicht! Ziel unserer Aktion war eher, dass wir uns etwas mehr Feedback für das Projekt wünschen und gehofft haben WIEDER welches von Euch zu bekommen. Nach der News zur Veröffentlichung der 0.2.5r2 gab es einige gute und berechtigte Kritikpunkte, die alle in die Entwicklung eingeflossen sind. Auch waren Eure Kommentare in der letzten News ein ausschlaggebender Grund die Template Engine schon jetzt in TGS zu integrieren und nicht, wie geplant, zur Version 0.3.0.
Als ein Konzeptloses CMS würde ich TGS, nicht nur weil ich Entwickler bin, nicht bezeichnen. Wir als das Team legen unseren Fokus auf jedenfall auf der Vereinfachung von Content Management Systemen allgemein. Die alltägliche Bedienung soll WIRKLICH für jeden verständlich sein und die Installation und Konfiguration sollte ebenfalls möglichst einfach gehalten werden. Ziel ist es ein System zu erschaffen, was von jedem bedienbar ist, alle nötigen Funktionen zum betreiben einer Seite bietet und eine möglichst große Flexibilität für den Benutzer/Anwender bietet. Ein reines darstellen der Datenbank ist nun wirklich nicht unser Ziel.
Sicher muss ich zugeben, dass wir noch weit von unserem eigenen Ziel entfernt, aber das alleine sagt denke ich auch schon die Versionsnummer aus. Interessante Änderungen wird es in der Neuentwicklung in Form von TGS Content Management 0.5.0 geben. Der dort eingesetze CMS-Kern wird dann auch die Basis für alle uns vorschwebenden Erweiterungen sein.
> Auch würde ich mir wünschen, daß man bei Pro-Linux eine etwas schärfere Grenze zwischen Berichterstattung über und Eigenwerbung von Projekten erkennen könnte.
Jep, und ein "Bericht" bei jeder Revisionsänderung ist nun wirklich etwas zuviel, zumal ja nichtmal direkt mit Linux zu tun hat..
>zumal ja nichtmal direkt mit Linux zu tun hat.. Es wurde schon oft genug von demon und Co. erklärt, dass es sich bei PL nicht _nur_ um Linux dreht, sondern auch um Open Source an sich.
Also wenn das Template System immer solch zerfranzten Layouts auswirft wie auf der Seite von dennen werd mir das bestimmt nicht näher anschauen. Oder hat dort nur wer zu viel Text in Felder geschrieben die für weniger vorgesehen waren?
Auf der Homepage (die wirklich schlecht ist) läuft noch eine uralte Frontend Version (keine Template Engine). Im Einsatz sieht man die Engine auf usnerer Demo Seite => http://demo.tgs-cms.de/
Dass keine Tabellen für Layout verwendet und auf Standardkompatibilität geachtet wurde, ist sehr positiv. Es gibt genug CMS, die immer noch in altem Tabellenchaos steckengeblieben sind. Aber geht doch noch einen Schritt weiter. Im Moment leidet das TGS-CMS an "Divitis". Das mag zwar syntaktisch korrekt sein, ist aber semantisch eher ungünstig.
Bei HTML gibt es Auszeichnungsmöglichkeiten für viele Textbausteine, die auch verwendet werden sollten. Man zeichnet den Text aus nach seiner Bedeutung. Zum Beispiel sollte man für eine Seitenüberschrift statt: div class="sitetitle" besser h1 verwenden, für weitere Überschriften h2, h3 usw, für Absätze im Fließtext p, für Linklisten ul. Für große Layoutabschnitte auf einer Seite, die nur einmal vorkommen, ist div id="" besser als div class="". Veraltete Tags wie center sollten gar nicht mehr verwendet werden.
Als Doctype finde ich strict besser, weil der Validator dann mehr Fehler und Ungereimtheiten findet. Zumindest zum Entwickeln ist das zu empfehlen.
Einen guten Einstieg in all das bieten z.B. diese beiden Websites: http://www.htmldog.com/ http://css.maxdesign.com.au/
Es gibt ja im Grunde schon quasi eine Rubrik "LUS's stellen sich vor". Vielleicht ist in Anlehnung daran eine "Projekte stellen sich vor" sinnvoll. Ist doch verständlich. Die Entwickler basteln Monate lang vor sich hin und wenn es beginnt einiger maßen rund zu laufen, wollen sie ihr Baby auch mal vorstellen. Wenn es eine Extra Rubrik oder dafür gibt, weiß jeder wo ran er ist - und Gut.
Da ist was dran, weshalb ich diesen Vorschlag unterstützen würde. Es stellt sich nur die Frage, ob dann solche Beiträge nicht die Überhand nehmen würden. Auf der anderen Seite gibt es auch sonst sehr wenig Möglichkeit, seine Projekte vorzustellen.
Und noch ein CMS, bei dem wieder an zentralen Punkten das Rad neu erfunden wird.
Warum setzt nicht endlich mal einer wirklich auf Standards auf? Laßt doch mal diese zwangsläufig immer irgendwie halbgaren Template-Engines weg und baut dafür endlich ein CMS mit Datenbank-Backend, das eine komplette XML-Publishing-Chain über XSL und WYSIWYG-Editoren sowohl für die Templates als auch für den Content umsetzt. Ok, wird nicht ganz so trivial, weil man im Grunde einen Echtzeit-XSLT-Prozessor mit nachgeschaltetem Gecko bräuchte, aber im Zeitalter von 3GHz-Rechnern kann das doch nicht wirklich der begrenzende Faktor sein, oder?
Weitere Wunsch-Features meinerseits: - PostgreSQL als Backend mit konsequent eingesetzten Transaktionen - "Poor Man's" Load-Balancing durch Replikation des Backends und DNS-Round-Robin - XSLT-Importfilter und -Exportfilter für dynamischen Content aller Art - Importfilter für OpenDocument-Dateien - Direkte Anbindung von OpenOffice als alternatives Front-End für Autoren - Integration von CMS- und DMS-Funktionalitäten in ein System (Zugriffskontrolle, Versionierung, Archivierung, GBDBU-Konformität, Referenzenverwaltung und so weiter), so daß man intern erstellte Dokumente quasi per Rechtefreigabe und Referenzierung direkt ins CMS publishen kann.
Danke für deine Meinung! Ich werde das mal auf die Liste für den neuen Core setzen. Alles wird sich nicht realisieren lassen, aber ein paar Dinge werden wir mit Sicherheit einbauen, so oder so ähnlich!
"Skriptsprache HTML" *hüst*
http://de.wikipedia.org/wiki/Hypertext_Markup_Language
Und warum überhaupt eine neue Template Engine, warum wurde kein Smarty verwendet?
Ansonsten sind die Infos zur Technik (DB-Layer, Structur, Besonderheiten) des Systems sowohl in der News wie auch auf der HP mehr als dürftig. Ja die News bietet fast sogar noch mehr als die HP
Wir haben uns gegen die Verwendung von Smarty entschieden um flexibler auf ggf. auftretende Probleme im Zusammenhang mit dem CMS reagieren zu können und um gewisse Besonderheiten, wie zum Beispiel den standardmäßigen ThickBox Support, den eingebauten Sprachen-Umschalter oder die Kommentarfunktion (noch nicht im aktuellen Release enthalten), besser implementieren zu können. Des Weiteren unterstützt Smarty meines Wissens nach kein zwischenspeichern von generierten Seiten. Das war aber ein Ziel unserer Engine um auf großen Seiten mit hohen Besucherzahlen die Serverlast zu reduzieren.
Dem Kritikpunkt der mangelnden Informationen zur Technik muss ich mir auf jedenfall gefallen lassen. Das wissen wir im Team auch selber und arbeiten auch momentan daran, die Dokumentationen zu erweitern und unsere Entwicklung transparenter zu gestalten. Bei der Neuentwicklung (0.5.0) soll jedoch dies deutlich besser gemacht werden und sowohl der Code soll besser kommentiert, als auch die externen Dokumentationen sollen ausführlicher werden.
Danke aber erstmal für deine Meinung
Es sollte auf jedenfall noch ein wenig an der Demo Seite geschraubt werden sieht zwar schon besser aus als die alte Startseite aber die DivŽs sind nicht wirklich alle so perfekt braucht ja nicht alles per div zu beschreiben.
ich glaube ihr solltet auf jedenfall noch mind. eine Seite auf eurer HP den Thema "Was machen wir", "Was machen wir anders" und "Technik" widmen. Das vermisse ich bei euch wirklich. Auch eure Demoseite ist noch etwas leer.
Die Punkte die du angesprochen hast wegen der Template Engine sollten mit Smarty aber kein Problem sein. Man kann bei Smarty vieles, auch absolute Grundfunktionen, mittels Funktionserweiterungen und co. ergänzen, ganz ohne den Smartycode zu verändern. Ich halte Smarty für eine wirklich gute Wahl.
Ich muss aber auch sagen das mir euer System vom Admin her sehr nach Mambo/Joomla aussieht. Ich erkenne nicht direkt die deutliche Vereinfachung im Vergleich dazu
Außer vielleicht durch Funktionsverzeicht. Das ist zwar sicher ein Weg, aber da wäre vielleicht ein spezieller Joomla Release einfacher als ein ganzes CMS. Gibt halt schon sooo viele.
Zugegeben, das aktuelle Control Panel sieht Joomla! ziemlich ähnlich, ist allerdings eher unbeabsichtigt. Das wird sich aber auch mit der 0.5.0 ändern. Das Control Panel wird gaaaaanz anders aussehen als das jetzige. Mit der Einfachheit hast du momentan leider noch Recht. Punkte die uns wichtig sind wären zum Beispiel die Installation von Erweiterungen und Einbindung bestimmter Drittsystem (vBulletin zB) Weiterhin arbeiten wir derzeit an einem Artikelsystem für Newsseiten und weiteren Erweiterungen die TGS etwas vom Rest abheben sollen. Aber dazu kommt später auf unserer Seite noch eine ausführliche Nachricht.
Die Seite, die wie schon von mir erwähnt momentan mit einer uralten TGS Version läuft, wird in der nächsten Woche auf die 0.2.5r3 umgestellt und wird dann auch mehrsprachig. Weiterhin werden wir die Tabellen aus dem Design entfernen und allgemein einige Änderungen vornehmen. Unter anderem werden dann auch solche Informationsseiten, wie "Was machen wir", "Was ist TGS Content Management" usw. erstellt. Die Seite wird dann in Englisch, Japanisch, Holländisch und Deutsch verfügbar sein. Aber das ist momentan noch in der Mache!
Auf jedenfall danke für Eure Tipps und Eure Meinung zu unserem System.
Vielen Dank und gruß
Christoph
Ich frage mich auch eher, was das Merkmal dieses CMS ist, daß es Sinn gemacht hat, ein neues System zu schreiben. Konzeptionslose CMS, die nicht mehr können als unflexible Dokumentenstrukturen irgendwie darzustellen, gibt es ja mehr als genug.
Auch würde ich mir wünschen, daß man bei Pro-Linux eine etwas schärfere Grenze zwischen Berichterstattung über und Eigenwerbung von Projekten erkennen könnte.
Auch waren Eure Kommentare in der letzten News ein ausschlaggebender Grund die Template Engine schon jetzt in TGS zu integrieren und nicht, wie geplant, zur Version 0.3.0.
Als ein Konzeptloses CMS würde ich TGS, nicht nur weil ich Entwickler bin, nicht bezeichnen. Wir als das Team legen unseren Fokus auf jedenfall auf der Vereinfachung von Content Management Systemen allgemein. Die alltägliche Bedienung soll WIRKLICH für jeden verständlich sein und die Installation und Konfiguration sollte ebenfalls möglichst einfach gehalten werden. Ziel ist es ein System zu erschaffen, was von jedem bedienbar ist, alle nötigen Funktionen zum betreiben einer Seite bietet und eine möglichst große Flexibilität für den Benutzer/Anwender bietet. Ein reines darstellen der Datenbank ist nun wirklich nicht unser Ziel.
Sicher muss ich zugeben, dass wir noch weit von unserem eigenen Ziel entfernt, aber das alleine sagt denke ich auch schon die Versionsnummer aus. Interessante Änderungen wird es in der Neuentwicklung in Form von TGS Content Management 0.5.0 geben. Der dort eingesetze CMS-Kern wird dann auch die Basis für alle uns vorschwebenden Erweiterungen sein.
Jep, und ein "Bericht" bei jeder Revisionsänderung ist nun wirklich etwas zuviel, zumal ja nichtmal direkt mit Linux zu tun hat..
Es wurde schon oft genug von demon und Co. erklärt, dass es sich bei PL nicht _nur_ um Linux dreht, sondern auch um Open Source an sich.
Wem die News egal ist -> einfach mal nicht lesen.
Im Einsatz sieht man die Engine auf usnerer Demo Seite => http://demo.tgs-cms.de/
Bei HTML gibt es Auszeichnungsmöglichkeiten für viele Textbausteine, die auch verwendet werden sollten. Man zeichnet den Text aus nach seiner Bedeutung. Zum Beispiel sollte man für eine Seitenüberschrift statt: div class="sitetitle" besser h1 verwenden, für weitere Überschriften h2, h3 usw, für Absätze im Fließtext p, für Linklisten ul. Für große Layoutabschnitte auf einer Seite, die nur einmal vorkommen, ist div id="" besser als div class="". Veraltete Tags wie center sollten gar nicht mehr verwendet werden.
Als Doctype finde ich strict besser, weil der Validator dann mehr Fehler und Ungereimtheiten findet. Zumindest zum Entwickeln ist das zu empfehlen.
Einen guten Einstieg in all das bieten z.B. diese beiden Websites:
http://www.htmldog.com/
http://css.maxdesign.com.au/
Viel Erfolg weiterhin!
Hey, nicht böse gemeint, ich setz auch nur noch xhtml 1 strict bzw xhtml 1.1 als doctype ein
Haha, ja, das war mir schon klar. Klang ein bischen tumpig von mir, geb ich zu.
Warum setzt nicht endlich mal einer wirklich auf Standards auf? Laßt doch mal diese zwangsläufig immer irgendwie halbgaren Template-Engines weg und baut dafür endlich ein CMS mit Datenbank-Backend, das eine komplette XML-Publishing-Chain über XSL und WYSIWYG-Editoren sowohl für die Templates als auch für den Content umsetzt. Ok, wird nicht ganz so trivial, weil man im Grunde einen Echtzeit-XSLT-Prozessor mit nachgeschaltetem Gecko bräuchte, aber im Zeitalter von 3GHz-Rechnern kann das doch nicht wirklich der begrenzende Faktor sein, oder?
Weitere Wunsch-Features meinerseits:
- PostgreSQL als Backend mit konsequent eingesetzten Transaktionen
- "Poor Man's" Load-Balancing durch Replikation des Backends und DNS-Round-Robin
- XSLT-Importfilter und -Exportfilter für dynamischen Content aller Art
- Importfilter für OpenDocument-Dateien
- Direkte Anbindung von OpenOffice als alternatives Front-End für Autoren
- Integration von CMS- und DMS-Funktionalitäten in ein System (Zugriffskontrolle, Versionierung, Archivierung, GBDBU-Konformität, Referenzenverwaltung und so weiter), so daß man intern erstellte Dokumente quasi per Rechtefreigabe und Referenzierung direkt ins CMS publishen kann.
- Importfilter für OpenDocument-Dateien
- Direkte Anbindung von OpenOffice als alternatives Front-End für Autoren
Zusätzlich
- Export als OpenDocument
Es gibt zwar solche Lösungen unter typo3 aber diese (als ich das getestet hatte) waren noch nicht so ganz das, was ich benutzerfreundlich bezeichne