Typo3 oder selber machen?

[Encoder]

Hallo

Ich habe hier eine angefangene Webseite mit Typo3 vor mir. Da soll ich ein bisschen was ändern und z.B. tote Links entfernen, hinter denen keine weitere Info steht. Es geht hier um eine vorgefertigte Informationsseite, die nicht alle der bereits vorbelegten Kategorien braucht.
Das Layout gefällt mir schon irgendwie, wär aber nichts was man selber nicht schaffen würde.
Allerdings gibts auch recht seltsame Dinge drin, man klickt beispielsweise auf ein Bildchen (Icongröße und -charakter) und es öffnet sich eine Art Lytebox mit dem Bild drin, genauso groß und daher ziemlich unsinnig. Die Navigation allgemein ist für den A... und kein bisschen durchsichtig. Eigentlich verlinkt so ziemlich alles irgendwohin und keiner weiß warum.

Ich hab jetzt schon mehr Zeit mit Typo3 verbracht (und finde immer noch nichts) als ich gebraucht hätte um den Text in einer selber gebastelten Seite zu ändern.

Momentan bin ich der Meinung, die wirklich benötigte Information der Seite selber schneller hinzukriegen, als ein so wahnsinnig mächtiges und dafür unverständliches und verschachteltes CMS zu benutzen.
Wie seht ihr diesen Gedanken?
Bin ich da zu selbstherrlich, zu wenig innovativ, zu ignorant... Sollte ich mich hier weiter einarbeiten, um vielleicht auch jemand anderem mal die Möglichkeit zu geben, hier was zu ändern? (Ich hab mich übrigens dafür gemeldet weil sonst keiner das machen wollte :-)

Oder hab ich vielleicht recht, wenn ich sage ich mach mir was wo ich Inhalt selber ändern kann wie ich will, einfach mit einem Texteditor anstatt mich bäumeweise durch Strukturen zu klicken und dann weitere Klick zu machen bis ich irgendwo mal zufällig meinen zu ändernden Text finde?

Was habt ihr für Erfahrungen?
Nochmal zur Klärung, es geht hier bei weitem um nichts das täglich aktualisiert werden muss. Seht es als Vereisseite, wo immer wieder mal auf einer Seite von aktuellen Dingen berichtet werden soll.

[fastix®]

Moin!

Was habt ihr für Erfahrungen?
Nochmal zur Klärung, es geht hier bei weitem um nichts das täglich aktualisiert werden muss. Seht es als Vereisseite, wo immer wieder mal auf einer Seite von aktuellen Dingen berichtet werden soll.

Dann ist Typo3 einfach zu groß. Ein kleineres CMS tut es dann auch.

Lernaufwand und mangelhafte Performance sind die Kritikpunkte an Typo 3, aber das ist eben aos, wenn jeder Wunsch nach Eiern, Milch, Wolle und Fleisch erfüllt wird. Dann kommt eine eierlegende Wollmilchsau heraus, die Spezialfutter braucht und ganztags von einem Psychologen betreut werden möchte - und weder besonders tolle Milch gibt legt, noch jeden Tag Eier legt, deren Fell nur zu Filz und nicht für Wolle taugt und deren Fleisch nur in die Wurstsuppe kann.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Encoder]

Ok das sagt mir eigentlich dass ich richtig liege :-)
Ich weiß nicht mal obs überhaupt ein CMS sein muss. Dafür dass die Seite einmalig eingerichtet wird und vielleicht eine Unterseite alle paar Wochen/Monate mal geändert wird, find ich die Einarbeitung in jedes CMS zu krass.
Ich werde rausfinden ob jemand anderes ohne HTML-Kenntnisse daran auch mal was machen will. Falls nicht, mach ich die Seite selber.

[fastix®]

Moin!

Ich würde mich ja freuen, wenn sich mal einer mit "Des fastix kleines CMS" an ein dafür geeignetes Projekt macht.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Steel]

Moinsen!

Ich würde mich ja freuen, wenn sich mal einer mit "Des fastix kleines CMS" an ein dafür geeignetes Projekt macht.

Klingt ja nett.

Hier: Korrigier doch mal:

"Auch da kann Ihnen helfen:" (unter Anpassungen, unten)

[fastix®]

Moin!

Hier: Korrigier doch mal:

"Auch da kann Ihnen helfen:" (unter Anpassungen, unten)

THX!

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Steel]

Nabend,

Hier: Korrigier doch mal:

"Auch da kann Ihnen helfen:" (unter Anpassungen, unten)

THX!

Keine Ursache.

Soll ich mal weitermachen? Neben Schriften, sammel ich irgendwie wohl auch CMS. Also hab ich mir fastix (so nenn ich das mal) runtergeladen und 'installiert'.

Setup aufgerufen. Angemeldet. Jetzt sollte laut Anleitung eine Aufforderung kommen, das Passwort zu ändern. Kam nix. Also flott zur Benutzerverwaltung und dort 'root' ein neues Passwort verpasst. Damits beim Testen schön einfach ist auch erstmal 'root' eingegeben. Fehlermeldung: Name (3 Zeichen) oder Passwort (4 Zeichen) zu kurz. Komisch. Passt doch? Hm. Vielleicht einer dieser Fehler, die ganz wo anders liegen als angezeigt? Vielleicht darf das Passwort nicht gleich dem Namen sein? Also als neues Passwort 'admin' eingegeben. Gleiche Fehlermeldung. Vielleicht brauchts auch zahlen drin? 'admin5' hat funktioniert. Erst jetzt sehe ich den Text über dem Formular, daß das Passwort mindestens 6 Zeichen haben muß. Is schon spät.

Magst Du weitere Erlebnisberichte?

[fastix®]

Moin!

Magst Du weitere Erlebnisberichte?

Ja. Vor allem Bugreports. Das nicht zum Ändern des Passworts aufgerufen wurde war z.B. ein Fehler beim Packen des Tarballs.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Steel]

Mahlzeit,

bisher ist mir nichts weiter aufgefallen. Der erste Eindruck war, dass es ein kleines sehr aufgeraeumtes und uebersichliches System handelt. Die Skingenerierung (Template Erstellung) finde ich vorbildlich. Alles ist sofort erkennbar und aenderbar. Beim Erstellen von Content hatte ich ein paar Anlaufschwierigkeiten. Sobald ich geschnallt hatte, dass man zuerstmal ne Kategorie erstellen muss und nicht einfach Seiten generieren kann, hat alles gut geklappt.

Vom Handling ein nettes kleines System. Durchaus empfehlenswert. Mit nem Forum waere es sicher schon jetzt unter meinen Favourites ganz vorn. So muss ich mal sehen, ob ich es noch weiter teste. Bin leider ab morgen unterwegs und gehoere zu den armen Menschen ohne Notebook. Sonst wuerd ich das System in meinen freien Tagen sicher etwas strapazieren.

[suit]

Dann ist Typo3 einfach zu groß. Ein kleineres CMS tut es dann auch.

Lernaufwand und mangelhafte Performance sind die Kritikpunkte an Typo 3

Der Lernaufwand kann aber auch ein positiver Kritikpunkt sein, wenn man sowieso vor hat sich in TYPO3 einzuarbeiten. Eine kleine Seite als "Übungsobjekt" ist da nicht verkehrt.

suit.rebell.at ist z.B. auch mit TYPO3 gemacht obwohl das bei den ~5 bis 10 Seiten der absolute overkill ist ;)

[Sven Rautenberg]

Moin!

Ich hab jetzt schon mehr Zeit mit Typo3 verbracht (und finde immer noch nichts) als ich gebraucht hätte um den Text in einer selber gebastelten Seite zu ändern.

Dann ist Typo3 die falsche Software.

Momentan bin ich der Meinung, die wirklich benötigte Information der Seite selber schneller hinzukriegen, als ein so wahnsinnig mächtiges und dafür unverständliches und verschachteltes CMS zu benutzen.

Tja, Typo3 ist groß und mächtig, aber nach Meinung vieler auch unverständlich und kompliziert.

Bin ich da zu selbstherrlich, zu wenig innovativ, zu ignorant... Sollte ich mich hier weiter einarbeiten, um vielleicht auch jemand anderem mal die Möglichkeit zu geben, hier was zu ändern? (Ich hab mich übrigens dafür gemeldet weil sonst keiner das machen wollte :-)

Denk mal einen Augenblick drüber nach, warum das außer dir keiner machen wollte. Könnte es daran liegen, dass niemand mit dem CMS klarkommt, und der klassische Vorteil "Man braucht keinen HTML-Experten mehr, um die Seite zu bearbeiten" ersetzt wurde durch den Nachteil "Man braucht jetzt einen Typo3-Experten, um die Seite zu bearbeiten".

Ich bin von Halb-Experten schon extrem schräg angeguckt und angefeindet worden, weil ich als Softwarevorschlag für die Seitenverwaltung eine Blogsoftware genommen habe, anstelle zur Pflege was selbstgeschriebenes oder ein klassisches CMS zu verwenden.

Resultat: Die Leute können mit dem Blog bestens umgehen, weil sich alle relevanten Seiten automatisch aktualisieren, und die eigentliche Arbeit eben im Schreiben des jeweiligen Textes besteht - und damit kommt jeder klar. Ich will nicht spekulieren, was die selbstgeschriebene Software so gekonnt hätte, oder ein klassisches CMS an Overhead mitbringen würde.

Der zentrale Punkt ist: Nur weil das eine Blogsoftware ist, muss man noch lange nicht ein Webtagebuch damit schreiben. Webseiten bestehen im Prinzip ja aus zwei Typen von Seiten: Erstens den Inhaltsseiten (und die herzustellen erfordert einen Textschreiber), und zweitens den Übersichtsseiten mit den (variablen) Listen von Inhaltsseiten. Und genau dabei hilft das Blog: Die Inhaltsseiten zu schreiben ist die Kernkompetenz der Admin-Oberfläche des Blogs, und die Übersichtsseiten herzustellen ist die Aufgabe der entsprechenden Templates und Automatiken. Und damit hat man meist 99% aller Anforderungen erschlagen.

Oder hab ich vielleicht recht, wenn ich sage ich mach mir was wo ich Inhalt selber ändern kann wie ich will, einfach mit einem Texteditor anstatt mich bäumeweise durch Strukturen zu klicken und dann weitere Klick zu machen bis ich irgendwo mal zufällig meinen zu ändernden Text finde?

Du kannst es dir kompliziert oder einfach machen. Kompliziert wird es, wenn du die Aufgabe zu ernst nimmst, dass du alles perfekt verbessern willst, dabei aber Typo3 nicht loswirst.

Einfach wäre es, wenn du ganz banal mit Scheuklappen nur die relevanten Text- und Linkänderungen vornimmst, und dich über den mangelhaften Gesamtzustand nicht weiter aufregst. Die Frage ist halt: Willst du es "richtig richtig" machen und dafür alles auf den Kopf stellen, oder reicht es aus, innerhalb des mangelhaften Gesamtzustandes mit den Möglichkeiten desselben die Welt nur ein ganz klein wenig zu verbessern.

Was habt ihr für Erfahrungen?
Nochmal zur Klärung, es geht hier bei weitem um nichts das täglich aktualisiert werden muss. Seht es als Vereisseite, wo immer wieder mal auf einer Seite von aktuellen Dingen berichtet werden soll.

Das ist eben der Klassiker für ein Blog.

- Sven Rautenberg

[Encoder]

Einfach wäre es, wenn du ganz banal mit Scheuklappen nur die relevanten Text- und Linkänderungen vornimmst, und dich über den mangelhaften Gesamtzustand nicht weiter aufregst. Die Frage ist halt: Willst du es "richtig richtig" machen ...

Eigentlich will ich es grad nur überhaupt irgendwie machen. Ich hab eine Seite in der Baumansicht ausgewählt, wo ich Text ändern will. Leider sehe ich diesen Text nirgends. Ich hab schon auf ziemlich alle dieser vielen Icons geklickt. Es scheint als wäre hier ein Plugin eingebunden, denn wenn ich das lösche ist der ganze Text weg. Wo ich jetzt diesen Text finde, ist mir allerdings immer noch ein Rätsel.

Wenn ich nicht diesen Irrsinn selber kennen würde, was man alles für Goodies und Krempel in irgendwelche Software einbauen kann - ist ja egal obs noch jemand blickt oder nicht - würd ich mich jetzt direkt drüber aufregen :-)

[suit]

Tja, Typo3 ist groß und mächtig, aber nach Meinung vieler auch unverständlich und kompliziert.

Ja, komplexe Systeme sind nach Meinung vieler immer unverständlich und kompliziert - für Insider aber nicht.

Für mich sind Videorekorder oder Waschmaschinen groß, mächtig und kompliziert - TypoScript oder die Extension-Schnittstelle von TYPO3 hingegen finde ich nahezu "trivial".

Denk mal einen Augenblick drüber nach, warum das außer dir keiner machen wollte. Könnte es daran liegen, dass niemand mit dem CMS klarkommt, und der klassische Vorteil "Man braucht keinen HTML-Experten mehr, um die Seite zu bearbeiten" ersetzt wurde durch den Nachteil "Man braucht jetzt einen Typo3-Experten, um die Seite zu bearbeiten".

Das ist meistens ein fehler beim Einsatz eines CMS, denn man muss denoch in der Lage sein HTML und CSS zu erstellen/bearbeiten. Hinzu komt aber das Wissen um das CMS.

Ebenso entsteht im Vergleich zu einer statischen Seite ein Angriffspunkt mehr: das CMS selbst hat eine Administrationsoberfläche die es zu schützen gilt.

Ich bin von Halb-Experten schon extrem schräg angeguckt und angefeindet worden, weil ich als Softwarevorschlag für die Seitenverwaltung eine Blogsoftware genommen habe, anstelle zur Pflege was selbstgeschriebenes oder ein klassisches CMS zu verwenden.

Wordpress ist z.B. für einfache Seiten auch völlig geeignet - da spricht auch nichts dagegen, sofern ein "normaler Mensch" die Inhalte zu warten hat und keine extremen Sonderwünsche notwendig sind. Aber das ist eben vor der Wahl des CMS abzuwägen.

Du kannst es dir kompliziert oder einfach machen. Kompliziert wird es, wenn du die Aufgabe zu ernst nimmst, dass du alles perfekt verbessern willst, dabei aber Typo3 nicht loswirst.

[Steel]

Hi!

Ich persoenlich wuerde auch dazu tendieren ein Leichtgewicht von CMS zu installieren. Das kann eine Blogsoftware sein oder ein kuschliges kleines CMS. (wobei ich da nicht unbedingt einen Unterschied sehe)

Klar kannst Du auch alles Manuell machen und selbst immer Aenderungen im HTML vornehmen. Wuerde ich aber, soweit es absehbar ist, dass das regelmaessig geschieht (1x die woche, 1x im monat, ...), nicht tun.

Ich nehm mal an, von Typo3 haste dich geistig schon verabschiedet?

[Encoder]

Ich nehm mal an, von Typo3 haste dich geistig schon verabschiedet?

Nach einer Stunde hab ich rausgefunden, dass ein sogenanntes news-Plugin den zu ändernden Inhalt einer Seite enthält. Dieses kann ich zwar entfernen, aber ich finde nirgends wie ich an die Quelle des Inhalts komme, um den Inhalt zu ändern.
Insofern kann ich deine Frage mit einem sehr wahrscheinlichen Ja beantworten.

[suit]

Ich nehm mal an, von Typo3 haste dich geistig schon verabschiedet?
Nach einer Stunde hab ich rausgefunden, dass ein sogenanntes news-Plugin den zu ändernden Inhalt einer Seite enthält. Dieses kann ich zwar entfernen, aber ich finde nirgends wie ich an die Quelle des Inhalts komme, um den Inhalt zu ändern.

Vermutlich tt_news - eines der meistgenutzten und imho am dämlichtsen programmierten Plugins ;)

Der Inhalt ist vermutlich unter "List" auf derselben Seite zu finden (oder hat einen anderen "Startingpoint" (in den Plugin-Einstellungen oder im TypoScript zu finden).

[Encoder]

Der Inhalt ist vermutlich unter "List" auf derselben Seite zu finden

Sowas hab ich auch schon gegoogelt. Aber ich finde in der List Ansicht nichts passendes. Ees gibt ein paar "SysOrdner", die da anscheinend zuständig sind. Aber in denen ist nichts drin. Und die Ansicht sieht auch nicht ganz so aus wie in einem Beispielbild im Internet.

(oder hat einen anderen "Startingpoint" (in den Plugin-Einstellungen oder im TypoScript zu finden).

Tja... ich schau nochmal da rein. Sonst wird halt der Editor geöffnet und die insgesamt 4 oder 5 Seiten des Projekts halt doch manuell umgesetzt.

[suit]

Die Hölle ist der Code der anderen, wie Beat immer so schön sagt ;)

Das trifft besonders auf TYPO3 zu.

[hotti]

h1,

Was habt ihr für Erfahrungen?

Mit dem genannten CMS keine, aber mit einem anderen CMS, was einen ähnlich gepimpften Maschinisten braucht um es bedienen zu können. Nach einem Anraunzer in der Newsgroup (es war wohl nicht ganz die Richtige, sondern die, wo nur die Loblieder gesungen werden durften) hab ichs dann aufgegeben und ein eigenes CMS geschrieben.

Nochmal zur Klärung, es geht hier bei weitem um nichts das täglich aktualisiert werden muss. Seht es als Vereisseite, wo immer wieder mal auf einer Seite von aktuellen Dingen berichtet werden soll.

HTML schreibt sich nicht von selbst. Zumindest sollte der Autor den <h> und den <p>-Tag kennen.

Hotti

[suit]

HTML schreibt sich nicht von selbst. Zumindest sollte der Autor den <h> und den <p>-Tag kennen.

Was tut der "<h>-Tag" in good HTML?

[hotti]

h1,

Was habt ihr für Erfahrungen?

Für mein CMS, was selbstverständlich auch multiuserfahig ist, nutze ich konsequent OOP. Wie ich das mit Perl mache, habe ich auch veröffentlicht:

Teil 1
http://rolfrost.de/objcont.html

Teil 2
http://rolfrost.de/urlobj.html

Den zweiten Teil habe ich noch am Wickel, wird evntl. heute abend erst fertig.

Hottü

[Nerdi]

Hallo,

Tpyo3 kann nur der jenige verstehen der von anfang an dabei ist! Das System hat sich mittlerweile zu einem extrem Klicki-Bunti entwickelt. Es ist total undurchsichtig. Nichts funktioniert intiutiv. Will man an einer stelle was ändern muss man an tausend anderen stellen noch mehr klicken und anpassen. Deswegen sagt man auch, die Konfigurationsprache. Es ist nicht mächtig sondern zu kompliziert. Typo3 ist der Neanderthaler unter den CMS-Systemen, meine Meinung. Kein Homosapziens! Aus diesem Grund ist Typo3 in einem wandel, laut Blog-Nachrichten, sonst adieu!  Mir hat es nicht gefallen. Bin garnicht damit  zurecht gekommen und entwickel momentan ein eigenes CMS-System.

Gruß

Nerdi

[suit]

Tpyo3 kann nur der jenige verstehen der von anfang an dabei ist!

Unsinn - es ist ein Einstieg auch problemlos in der aktuellen Version möglich. Historisches Wissen ist nicht erforderlich und oft auch nutzlos, da sich das System in seiner Geschichte tiefgreifend geändert hat.

Das System hat sich mittlerweile zu einem extrem Klicki-Bunti entwickelt.

Frontend-Bearbeitung kam dazu, ansonsten ist nichts "Klicki-Bunti" - eine Eigenschaft die ich eher Mac OS X oder Joomla! zuschreiben würde.

Es ist total undurchsichtig.

Seit etwa 2 Jahren gibt es eine extrem gut Dokumentierte API - vorher war es undurchsichtig.

Nichts funktioniert intiutiv.

Das trifft auf viele CMS zu - ich hab' bisher noch jeder "08/15-Bürotante" die noch nie zuvor ein CMS gesehen hat TYPO3 binnen kürzester Zeit ordentlich erklären können.

Will man an einer stelle was ändern muss man an tausend anderen stellen noch mehr klicken und anpassen.

Wenn das System ursprünglich ein Vollidiot konfiguriert hat - ja. Man _kann_ bei TYPO3 dasselbe an vielen verschiedenen Stellen machen - wenn jemand "herumprobiert" hat an verschiedenen Baustellen und dann durch zufall das richtige gefunden hat und dann seine Versuche nicht mehr bereinigt, ist das PITA - das hat aber nichts mit TYPO3 zu tun sondern mit dem Deppen der es so bedient.

Deswegen sagt man auch, die Konfigurationsprache.

Sagt man was?

Es ist nicht mächtig sondern zu kompliziert.

Das Framework für die Extensions ist nicht komplizierter als das Zend-Framework oder andere vergleichbare PHP-Frameworks.

Der TypoScript-Teil ist im grunde nur ein riesiges PHP-Array.

Somit jeder der Ahnung von PHP, mehrdimensionalen Arrays und ein bisschen OOP hat kommt mit TYPO3 idR. gut zurecht.

Typo3 ist der Neanderthaler unter den CMS-Systemen, meine Meinung.

Klingt danach, als hättest du noch nicht viele verschiedene CMS von "innen" gesehen. Schon mal Imperia gesehen?

Mir hat es nicht gefallen. Bin garnicht damit  zurecht gekommen und entwickel momentan ein eigenes CMS-System.

Das kann etwas werden.

Entwickelst du auch deine eigene Template-Engine weil du mit Smarty nicht zurecht kommst? ;)

Aber was red' ich: don't feed :)

[Struppi]

Entwickelst du auch deine eigene Template-Engine weil du mit Smarty nicht zurecht kommst? ;)

In PHP eine Template Engine zu entwickeln, ist relativ sinnlos. PHP ist eine Template Sprache, sie hat alles was eine Template Engine braucht.

Das war ja überhaupt damals der Erfolg von PHP gegenüber Perl, weil die Sprache eingebettet in HTML ist. Ansonsten hat sie wenig Vorteile.

Struppi.

[suit]

In PHP eine Template Engine zu entwickeln, ist relativ sinnlos. PHP ist eine Template Sprache, sie hat alles was eine Template Engine braucht.

Du sagst also, Smarty wäre sinnlos :) halte ich jetzt für ein Gerücht, aber ich respektiere deine Meinung.

Das war ja überhaupt damals der Erfolg von PHP gegenüber Perl, weil die Sprache eingebettet in HTML ist. Ansonsten hat sie wenig Vorteile.

Das ist mittlerweile nicht mehr so - PHP ist mitterlweile weit von einem einfachen Template-Baukasten entfernt.

[Struppi]

In PHP eine Template Engine zu entwickeln, ist relativ sinnlos. PHP ist eine Template Sprache, sie hat alles was eine Template Engine braucht.

Du sagst also, Smarty wäre sinnlos :)

Fast immer, ja.
Was für einen Vorteil sollte es haben, eine zusätzlich Programmiersprache in einer Programmierprache zu erlernen?
Zumal Smarty sicher nicht mehr kann als PHP, d.h. also hat man eine Programmiersprache, die weniger kann. Und das (einzige) Argument was für eine zusätzliche Templatesprache in PHP spricht, dass der Templateentwickler weniger Freiheit hat, geht davon aus, das die die Templates anfassen, ein interesse daran hätten Templates zu zerstören.

Das war ja überhaupt damals der Erfolg von PHP gegenüber Perl, weil die Sprache eingebettet in HTML ist. Ansonsten hat sie wenig Vorteile.

Das ist mittlerweile nicht mehr so - PHP ist mitterlweile weit von einem einfachen Template-Baukasten entfernt.

Von Baukasten habe ich nicht gesprochen, sondern davon, dass es eingbettet in HTML ist, ich gehe mal davon aus, dass sich das nicht ändern wird. Dann könnte man auch wieder Perl nehmen.

Struppi.

[suit]

Was für einen Vorteil sollte es haben, eine zusätzlich Programmiersprache in einer Programmierprache zu erlernen?

Dann ist PHP also auch sinnlos - man könnte genauso in C++ schreiben, das ist ohnehin doppelt so schnell :)

Der Argumentation will ich nich ganz folgen, wenn du erlaubst.

Von Baukasten habe ich nicht gesprochen, sondern davon, dass es eingbettet in HTML ist, ich gehe mal davon aus, dass sich das nicht ändern wird. Dann könnte man auch wieder Perl nehmen.

PHP in HTML einzubetten ist bei komplexen Systemen aber nicht mehr in Mode - wenn man Programmierung, Auszeichnung, Inhalt und Design voneinander isoliert, nutzt man diesen "Vorteil" von PHP eben nicht mehr aus.

Der Sinn davon ist, dass man prinzipiell die Programmiersprache durch eine andere Ersetzen kann - oder die Datenbank oder das Ausgabemedium.

Smarty-Templates lassen sich z.B. auch (bedingt) mit ASP Template parsen.

Wenn man hingegen ein Wordpress-Template von PHP auf eine andere Sprache migrieren möchte, ist man aufgeschmissen, da dort eben PHP wirklich eingebettet ist.

[Struppi]

Was für einen Vorteil sollte es haben, eine zusätzlich Programmiersprache in einer Programmierprache zu erlernen?

Dann ist PHP also auch sinnlos - man könnte genauso in C++ schreiben, das ist ohnehin doppelt so schnell :)

Du verdrehst meine Aussagen. PHP ist ein Template Sprache, die eine Programmiersprache in HTML einbettet. Und hat genau aus diesem Grund seine Verbreitung gefunden. Wo schrieb ich das das sinnlos ist?
Dieser Weg ist bequem und einfach, darüber hinaus aber noch eine zusätzliche Sprache zu lernen und einzubinden, die eigentlich keinen grossen Nutzen hat, halte ich für sinnlos.

Von Baukasten habe ich nicht gesprochen, sondern davon, dass es eingbettet in HTML ist, ich gehe mal davon aus, dass sich das nicht ändern wird. Dann könnte man auch wieder Perl nehmen.

PHP in HTML einzubetten ist bei komplexen Systemen aber nicht mehr in Mode - wenn man Programmierung, Auszeichnung, Inhalt und Design voneinander isoliert, nutzt man diesen "Vorteil" von PHP eben nicht mehr aus.

Das ist doch Unsinn, Smarty ist keine Programmiersprache? Es gibt Variabeln, Schleifen, Funktionen, usw... man trennt nichts voneinander, man baut nur eine Hürde auf, um sie dann Template nennen zu können.

Wenn man hingegen ein Wordpress-Template von PHP auf eine andere Sprache migrieren möchte, ist man aufgeschmissen, da dort eben PHP wirklich eingebettet ist.

Naja, du brauchst so oder so einen Parser unter Perl finde ich nur einen für PHP
http://search.cpan.org/~esummers/PHP-Include-0.2/lib/PHP/Include.pm einen Smarty Parser nicht.

Zumal es selbst in Smarty das gibt.

Aber du hast Recht, wenn es nicht auszuschliessen ist, dass die Templates protiert werden müssen, dann macht eine separate Templatesprache Sinn.

Wobei das (also die Portierfähigkeit) auf fast keine eingebettete Templatesprache zutreffen dürfte. Dann sollte man lieber direkt auf XSLT/XML umsteigen.

Struppi.

[suit]

Du verdrehst meine Aussagen.

Ich berichtigte sie nur.

PHP ist ein Template Sprache, die eine Programmiersprache in HTML einbettet.

php.net sagt: "PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML."

Ich bin geneigt, denen mehr zu glauben als dir :)

[Struppi]

Du verdrehst meine Aussagen.

Ich berichtigte sie nur.

In dem du behauptest ich könnte genauso gut C verwenden? Das habe ich nie gesagt und das ergibt sich auch nicht aus meinen Ausführungen.

PHP ist ein Template Sprache, die eine Programmiersprache in HTML einbettet.

php.net sagt: "PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML."

Ich bin geneigt, denen mehr zu glauben als dir :)

Was ist das jetzt für dich der gravierende Unterschied? Da steht das PHP in HTML eingebettet ist, genau das sagte ich auch.

Struppi.

[suit]

In dem du behauptest ich könnte genauso gut C verwenden? Das habe ich nie gesagt und das ergibt sich auch nicht aus meinen Ausführungen.

Ich hab das nur weitergeführt.

Du sagtest man könne auf eine in PHP geschriebene Template-Engine verzichten, weil man das mit PHP genauso machen kann. PHP ist in C, geschrieben - also warum nicht gleich auf PHP verzichten und in C arbeiten?

Was ist das jetzt für dich der gravierende Unterschied? Da steht das PHP in HTML eingebettet ist, genau das sagte ich auch.

Nein, da steht dass PHP in html eingebettet werden _kann_. Dass das zwangsläufig immer so ist, steht da nicht. Es steht explizit vorne dran, das PHP eine weit verbreitete, Scriptsprache für allgemeine Zwecke ist, die spezielle für die Web-Entwicklung geeignet ist.

[Struppi]

In dem du behauptest ich könnte genauso gut C verwenden? Das habe ich nie gesagt und das ergibt sich auch nicht aus meinen Ausführungen.

Ich hab das nur weitergeführt.

Du sagtest man könne auf eine in PHP geschriebene Template-Engine verzichten, weil man das mit PHP genauso machen kann. PHP ist in C, geschrieben - also warum nicht gleich auf PHP verzichten und in C arbeiten?

Nein, jetzt verdrehst du wieder alles. Ich sagte es ist sinnlos ein Spache _innerhalb_ einer anderen Sprache, nur um nicht diese Sprache zu verwenden, zu verwenden. Da PHP eine Template Sprache ist.

Was ist das jetzt für dich der gravierende Unterschied? Da steht das PHP in HTML eingebettet ist, genau das sagte ich auch.

Nein, da steht dass PHP in html eingebettet werden _kann_. Dass das zwangsläufig immer so ist, steht da nicht.

Da shabe ich auch nie behauptet. Ich sagte, dass der Erfolg von PHP darauf beruhte, dass sie sich einbetten läßt, das das mittlerweile anders ist spielt in dem Kontext nicht geringste Rolle.

Aber das ist natürlich auch eine super Diskussionsstil, einfach die Aussagen umdeuten und verdrehen, um dann das eigentliche Diskussionsthema völlig zu ignorieren.

Struppi.

[suit]

Da PHP eine Template Sprache ist.

PHP ist schon lange keine reine Template-Sprache mehr - PHP ist eine (teils) ojektorientierte, turingvollständige Programmiersprache.

das das mittlerweile anders ist spielt in dem Kontext nicht geringste Rolle.

Doch genau das spielt doch eine Rolle: man kann mit PHP eine Template-Engine programmieren und das wird in der Praxis auch gemacht ;)

Aber das ist natürlich auch eine super Diskussionsstil, einfach die Aussagen umdeuten und verdrehen, um dann das eigentliche Diskussionsthema völlig zu ignorieren.

Ich bin mir nicht sicher ob wir beide gerade dasselbe Diskussionsthema haben :)

[Struppi]

Da PHP eine Template Sprache ist.

PHP ist schon lange keine reine Template-Sprache mehr - PHP ist eine (teils) ojektorientierte, turingvollständige Programmiersprache.

Die als TemplateSprache konzipiert ist.

das das mittlerweile anders ist spielt in dem Kontext nicht geringste Rolle.

Doch genau das spielt doch eine Rolle: man kann mit PHP eine Template-Engine programmieren und das wird in der Praxis auch gemacht ;)

Was aber sinnlos ist, da PHP an sich schon eine Template Sprache ist.

Aber das ist natürlich auch eine super Diskussionsstil, einfach die Aussagen umdeuten und verdrehen, um dann das eigentliche Diskussionsthema völlig zu ignorieren.

Ich bin mir nicht sicher ob wir beide gerade dasselbe Diskussionsthema haben :)

Du diskutierst darüber ob PHP mehr ist als eine Templatesprache (was mir egal ist und was auch nicht bestreite). Mir geht es darum, dass es sinnlos ist eine Templatesprache zusätzlich mit einer Templatesprache zu überfrachten.

Das einzige Argument, was du bisher gebracht hast, die Sprachunabhängigkeit ist, wie du selber sagst nur beschränkt vorhanden und dafür gibt es auch bessere Möglichkeiten.

Struppi.

[Joachim]

Hi,

Zumal Smarty sicher nicht mehr kann als PHP, d.h. also hat man eine Programmiersprache, die weniger kann.

Das genau ist doch der Sinn von Smarty: reine Ausgabe, getrennt vom Applications-Layer. Es sind ja nicht immer PHPler, die am Template rumbauen. Wenn man natürlich anfängt, aufwändige Modifier etc. im Smarty zu verwenden, macht man imho was falsch.

Gruesse, Joachim

[Struppi]

Das genau ist doch der Sinn von Smarty: reine Ausgabe, getrennt vom Applications-Layer. Es sind ja nicht immer PHPler, die am Template rumbauen.

Aber Smarty  ist eben, wei die meisten Temple Sprachen, nicht die reine Ausgabe, sondern eine Programmiersprache. Da sind Schleifen, if Abfragen, include Befehle und was weiß ich. Der Vorteil erschließt sich mir unter PHP nicht. Natrülich, wer anfängt in sein Tamplate Logik seines Programms einzubauen macht etwas falsch, das kann er aber auch mit Smarty machen, nur eben langsamer und umständlicher.

Struppi.

[Joachim]

Hi,

Der Vorteil erschließt sich mir unter PHP nicht.

_Du_ sollst ja auch keine Templates machen ;-)
Der Vorteil von Smarty ist imho dass man nix kaputt machen kann. Jeder Webdesigner kann mit einem einfachen Loop eine Liste ausgeben, ohne wirklich tief in irgendwelche Syntax eindringen zu müssen. Sinn mach sowas aber nur bei eine entsprechenden Arbeitsteilung.

Allerdings sehe ich auch oft, das ganze Objekte einfach in Smarty assigned werden, diese Arbeitsweise führt imho das Templating as absurdum.

Ich gestehe aber, dass ich bei eigenen (Privat-)Projekten kein Smarty einsetze, da ich da eh alles in Personalunion mache.

Gruesse, Joachim

[Struppi]

Der Vorteil erschließt sich mir unter PHP nicht.
_Du_ sollst ja auch keine Templates machen ;-)
Der Vorteil von Smarty ist imho dass man nix kaputt machen kann.

Aber das ist ja explizit unter Smarty nicht so. Selbst da läßt sich PHP Code einfügen.

Ausserdem geht diese Begründung ja davon aus, dass es jemanden gibt, der ein Template kaputt machen wolte, was seltsam wäre, da die jenigen die am Template arbeiten, ja durchaus ein interesse daran haben das dies läuft.

Struppi.

[suit]

Aber das ist ja explizit unter Smarty nicht so. Selbst da läßt sich PHP Code einfügen.

Ja, aber machen soll man das nicht.

Man kann auch im Zend-Framework auch statt Zend_Db::factory mit mysql_connect arbeiten und um das Framework herumbauen - nur wozu sollte das gut sein?

Ausserdem geht diese Begründung ja davon aus, dass es jemanden gibt, der ein Template kaputt machen wolte, was seltsam wäre, da die jenigen die am Template arbeiten, ja durchaus ein interesse daran haben das dies läuft.

Natürlich aber es soll niemanden überfordern

<div id="inhalt">###inhalt###</div> schreckt einen unbedarften Benutzer/HTML-Autor weniger ab als <div id="inhalt"><?php the_content(); ?></div>

Im ersteren Fall ist ein Syntaxfehler unbedeuten, dann "geht's halt nicht" - im zweiten fall ist ein Syntaxfehler schlecht - da gibt Fehler oder es geht gar etwas (absichtlich) kaputt.

[Struppi]

Ausserdem geht diese Begründung ja davon aus, dass es jemanden gibt, der ein Template kaputt machen wolte, was seltsam wäre, da die jenigen die am Template arbeiten, ja durchaus ein interesse daran haben das dies läuft.

Natürlich aber es soll niemanden überfordern

<div id="inhalt">###inhalt###</div> schreckt einen unbedarften Benutzer/HTML-Autor weniger ab als <div id="inhalt"><?php the_content(); ?></div>

Ich glaube kaum, dass ein unbedarfter Benutzer die Smarty Sprache beherrscht.

Daneben gibt es dann so Dinge, wie Syntax Highlighting die den "unbedarftern Benutzer" helfen, um z.b. Schleifen Konstrukte zu erkennen und richtig zu bauen.

Im ersteren Fall ist ein Syntaxfehler unbedeuten, dann "geht's halt nicht" - im zweiten fall ist ein Syntaxfehler schlecht - da gibt Fehler oder es geht gar etwas (absichtlich) kaputt.

Ich bin mir sicher, dass es auch möglich ist einen Syntaxfehler in der zusätzlichen Skriptsprache "Smarty" einzubauen, nur dürfte dort die Meldungen nicht mehr so klar sein wie von PHP.

Struppi.

[fastix®]

Moin!

Ich glaube kaum, dass ein unbedarfter Benutzer die Smarty Sprache beherrscht.

Dem stimme ich zu. Allerdings gebe ich zu bedenken, dass Smarty keine alleinstehende Applikation ist, ja explizit nicht für unbedarfte Anwender geschrieben ist. Insofern gäbe es durchaus Probleme bei Webseiten, bei denen Inhalt (Texte), Layout (grafische Gestaltung) und Programmierung auch personell getrennt sind. Allerdings gibt es hier einen Programmierer, der eben kein unbedarfter Benutzer ist und dem grafisch orientierten "Templatefritze" Support leisten kann.

Was (das eigentlich tolle!) Smarty betrifft habe ich - wegen des Funktionsumfanges - hin und wieder meine Bauchschmerzen hinsichtlich der Effizienz. Ich weiß, dass Smarty - zum Ausgleich - auch Caching-Mechanismen zur Verfügung stellt. Nur ist das - in einfachen Fällen - alles wieder "overhead" und jeder "overhead" macht mir eben etwas Bauchschmerzen, da ich auf Grund des Umfanges der Software diese wieder nicht verstehe, deren Quelltext aus rein zeitlichen Gründen nicht prüfen kann.

Meine, in einfachen Fällen bevorzugte Methode ist auch ganz ähnlich der hier schon genannten, also etwa:

  
$strVor='$arTemplate[\'';  
$strNach='\']';  
foreach (array_keys($arTemplate) as $key) {  
    $arSearch[]=$strVor.$key.$strNach;  
    $arReplace[]=$arTemplate[$key];  
}  
print str_replace($arSearch, $arReplace, file_get_contents($arTemplate['TemplateFile']));  

Das geht schneller als man gucken kann. Die Prüfung ist auch ganz einfach: Man sehe sich den Output an :)
Natürlich geht es auch anders. Für jeden Aufruf im Template wird der Rückgabewert einer Funktion, eventuell unter Übergabe von Werten aufgerufen:

Im Template:
<myExec:myHallo>Welt</myExec>

Im PHP:

  
  
print execFunctionsInTpl(file_get_contents($strTemplateFileName));  
exit;  
  
function execFunctionsInTpl($str) {  
	$suchmuster = '/<myExec:(.*)>(.*)<\/myExec>/e';  
	return preg_replace($suchmuster, "execFunction('\\1','\\2')", $str);  
}  
  
function execFunction($fnName, $strValue) {  
     if ('my' != substr($fnName,0,2)) {  
          die ("Netter Versuch mit Funktion: $fnName.<br>\nExit!\n");  
     }  
  
     if (function_exists($fnName)) {  
          $str="return $fnName('$strValue');";  
          return eval($str);  
     } else {  
         die ("Fatal: Die Funktion $fnName ist nicht implementiert!\n");  
     }  
}  
  
function myHallo($str) {  
    return 'Hallo, '.$str."!\n";  
}  

Das geht, zur Vermeidung mehrere Durchläufe, natürlich auch mit bloßen Variablen, kann aber gefährlich sein:

<myExec:myGetOut>str</myExec>

dann muss natürlich die Funktion myGetOut() vorhanden sein:

function myGetOut($str) {  
    return $$str;  
}

Wenn man jetzt noch ein paar Funktionen in einem Include unterbringt, dann hat man fast zusammen, was Smarty kann... Ich wüsste jetzt auch nicht, welche der von Smarty gebotenen Funktion ich nicht ohne weiteres selbst in PHP coden könnte.

Nehmen wir z.B. mal aus dem Smarty-Crashkurs:

<table>  
{section name=mysec loop=$name}  
{strip}  
   <tr bgcolor="{cycle values="#eeeeee,#dddddd"}">  
      <td>{$name[mysec]}</td>  
   </tr>  
{/strip}  
{/section}  
</table>

das 'cycle values="#eeeeee,#dddddd"' sieht ja ganz nett aus...;

  
$intKlassen=2;  
$arTemplate['Tabelle']='<table><tbody>';  
$z=0;  
foreach ($arTabelle as $arZeile) {  
     $arTemplate['Tabelle']=.'<tr class="bgColor_'.($z % $intKlassen).'">';  
     foreach ($arZeile as $item) {  
         $arTemplate['Tabelle'].='<td>'.$arZeilen[$item].'</td>';  
     }  
     $z ++;  
     $arTemplate['Tabelle'].='</tr>';  
}  
$arTemplate['Tabelle'].='</tbody></table>';  

Im Template: steht dann nur: $arTemplate['Tabelle'], das versteht auch der Template-Designer. Die Farbe der Zeilen kommt eben in den Stylesheet als:

tr.bgColor_0 {background-color:#eee;}  
tr._bgColor1 {background-color:#ddd;}

(wo sie auch hin gehört) - und ich wüsste nicht, was Smarty hier besser kann als ich, denn ich kann auch:

tr.bgColor_0:hover, tr.bgColor_1:hover {background-color:#ffa;} - und da ist alles schön im CSS zusammen.  
  
  
Noch besser ist fast:  
  
[code lang=php]<div>{$smarty.now|date_format:"%Y-%m-%d"}</div>

vers.:
$arTemplate['heute']=date('Y-m-d');

Allerdings erspart mir da Smarty eine simple Zeile Code. Aber ob es sich wirklich lohnt, deshalb Smarty zu lernen? Immerhin könnte es auch bei Mehrsprachigkeit contraproduktiv sein:

$_SESSION['lang']='de'; # im Endeffekt aus Browsereinstellungen, Benutzereingaben, Domain, URL, ...  
  
$arDateFormat['de_de']='d.m.Y'; # aus Konfiguration  
$arDateFormat['fr_fr']='d/m/Y';  
$arDateFormat['en_us']='m.d.Y';  
...  
$arDateFormat['iso8601']='Y-m-d';  
  
if ( isset($arDateFormat[$_SESSION['lang']]) ) {  
    $arTemplate['heute']=date($arDateFormat[$_SESSION['lang']]);  
} else {  
    $arTemplate['heute']=date($arDateFormat['iso8601']);  
}

ist deutlich flexibler.

Eines will ich aber feststellen: Anders als mit Templates will ich gar nicht mehr arbeiten. In einem Spezialfall habe ich sogar sowas implementiert wie:

<uebersetze>Preis</uebersetze>: <currency>$arTemplate['Preis']</currency>

Dann muss natürlich nach dem Ersetzen der Inhalte nochmals das Template "geparst" werden und es müssen die entsprechenden Funktionen ausgeführt werden. Geht so ähnlich, wie oben beschrieben.

Klar. Das könnte Smarty bestimmt auch. Aber die Verwendung muss man eben von Fall zu Fall entscheiden. Es kann mit Smarty einfacher und schneller gehen - es muss aber nicht. Und in vielen Fällen glaube ich nicht daran.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Joachim]

Hi,

Ich glaube kaum, dass ein unbedarfter Benutzer die Smarty Sprache beherrscht.

ich glaube es nicht, ich weiss es - weil es bei uns so ist. An Smarty gibt es nix gross zu beherrschen, dazu ist es zu simpel. Ein einfaches foreach bekommt jeder Webdesigner hin, insbesondere wenn der Entwickler das schon im Groben angelegt hat. Ein debug zeigt ihm alles an, was zu Ausgabe zur Verfügung steht. Im Einzelfall muss er ggf Rücksprache halten. Vergleiche smarty mal mit template toolkit (perl)...

Die Tiefen, die Smarty ansonsten zu bieten hat sollten sowieso nur in Ausnahmefällen angewendet werden.

"unbedarftern Benutzer"

Naja, es sollen ja keine Redakteure Templates bauen, sondern Leute, die durchaus mit Strukturen umgehen können. Nur eben nicht unbedingt PHP-Entwickler.

Ich bin mir sicher, dass es auch möglich ist einen Syntaxfehler in der zusätzlichen Skriptsprache "Smarty" einzubauen, nur dürfte dort die Meldungen nicht mehr so klar sein wie von PHP.

Doch, bei Syntaxfehlern sogar mit Zeilennummer.

Gruesse, Joachim

[Struppi]

Vergleiche smarty mal mit template toolkit (perl)...

Wieso? Ich bestreite ja nicht die Notwendigkeit von Templatesprachen. Ich sehe nur nicht die Vorteile einer Templatesprache innerhalb einer anderen.

Naja, es sollen ja keine Redakteure Templates bauen, sondern Leute, die durchaus mit Strukturen umgehen können. Nur eben nicht unbedingt PHP-Entwickler.

Bin ich auch nicht, trotzdem konnte ich mich schnell in Wordpress Templates einarbeiten.

Struppi.

[Joachim]

Hi,

Ich sehe nur nicht die Vorteile einer Templatesprache innerhalb einer anderen.

ich glaube das die Einschätzung, dass es sich bei PHP um eine Templatesprache handelt, nicht wirklich verbreitet ist.

Bin ich auch nicht, trotzdem konnte ich mich schnell in Wordpress Templates einarbeiten.

Sach ich doch, dass Du eigentlich zu gut fürs Templating bist ;-) Ansonsten ist grade Wordpress kein gutes Beispiel für die Trennung von Programm und Output, da teilweise in den Funktionen viel HTML-Struktur generiert wird - zumindestens wars noch vor einem Jahr so, ich hab ne Weile nix mehr mit WP gemacht.

Gruesse, Joachim

[Nerdi]

Unsinn - es ist ein Einstieg auch problemlos in der aktuellen Version möglich. Historisches Wissen ist nicht erforderlich und oft auch nutzlos, da sich das System in seiner Geschichte tiefgreifend geändert hat.

Ne, es hat sich noch nichts großartiges geändert. Eine Historische Änderung wird wohl mit der Version 5 kommen. Bin mal gespannt.

Frontend-Bearbeitung kam dazu, ansonsten ist nichts "Klicki-Bunti" - eine Eigenschaft die ich eher Mac OS X oder Joomla! zuschreiben würde.

Die Frontend-Bearbeitung von der du redest ist ein New-Commer bei Typo. Also eine Art Befreiungsschlag.

Seit etwa 2 Jahren gibt es eine extrem gut Dokumentierte API - vorher war es undurchsichtig.

Da kann durchaus stimmen!

Nichts funktioniert intiutiv.

Das trifft auf viele CMS zu - ich hab' bisher noch jeder "08/15-Bürotante" die noch nie zuvor ein CMS gesehen hat TYPO3 binnen kürzester Zeit ordentlich erklären können.

Das erklären des Systems ist auch noch so ne Sache. Es hat sich zu einer Cafe-Fahrt System entwickelt. Wer das System nutzen möchten, muss erstmal eine Schulung buchen wo das Geld aus der Tasche gezogen wird. Es ist immer die gleiche ausrede die ich höre. Ja, super easy easy.

Wenn das System ursprünglich ein Vollidiot konfiguriert hat - ja. Man _kann_ bei TYPO3 dasselbe an vielen verschiedenen Stellen machen - wenn jemand "herumprobiert" hat an verschiedenen Baustellen und dann durch zufall das richtige gefunden hat und dann seine Versuche nicht mehr bereinigt, ist das PITA - das hat aber nichts mit TYPO3 zu tun sondern mit dem Deppen der es so bedient.

Aus entwickler sicht, klickt man hier, oh geht nicht, ups muss ja noch dort klicken, uiii geht ja immer noch nicht.. ah stimmt noch dort paar werte eintragen und das mit einem eingepflegten 4.3 System.

Deswegen sagt man auch, die Konfigurationsprache.

Sagt man was?

Das sagt man, das weist du selber!

Es ist nicht mächtig sondern zu kompliziert.

Das Framework für die Extensions ist nicht komplizierter als das Zend-Framework oder andere vergleichbare PHP-Frameworks.

Durchaus möglich.

Der TypoScript-Teil ist im grunde nur ein riesiges PHP-Array.

Das weis ich!

Somit jeder der Ahnung von PHP, mehrdimensionalen Arrays und ein bisschen OOP hat kommt mit TYPO3 idR. gut zurecht.

Ja mit den dingen komme ich sehr gut klar! Ja sogar mit MVC was mit Typo5 kommen soll.

Schon mal Imperia gesehen?

Nein, was hat das mit Typo zu tun?

Mir hat es nicht gefallen. Bin garnicht damit  zurecht gekommen und entwickel momentan ein eigenes CMS-System.

Entwickelst du auch deine eigene Template-Engine weil du mit Smarty nicht zurecht kommst? ;)

Ja tue ich, bevor Einstein kam hat man auch gesagt, feinste Sahne. Ich komme mit vielen dingen zurecht. Sehr gut sogar.

Nerdi

[suit]

Unsinn - es ist ein Einstieg auch problemlos in der aktuellen Version möglich. Historisches Wissen ist nicht erforderlich und oft auch nutzlos, da sich das System in seiner Geschichte tiefgreifend geändert hat.

Ne, es hat sich noch nichts großartiges geändert.

Wie lange arbeitest du schon mit TYPO3, wenn ich fragen darf?

Eine Historische Änderung wird wohl mit der Version 5 kommen. Bin mal gespannt.

TYPO3 5.x stellt quasi einen kompletten Codedrop dar und isoliert das CMS vom PHP-Framework (FLOW3). Zudem wird man verschen gängige Codeteile mit Drupal zu teilen - das ist eine Revolution.

Die Frontend-Bearbeitung von der du redest ist ein New-Commer bei Typo. Also eine Art Befreiungsschlag.

Ich brauch keine Frontend-Bearbeitung - auch nicht in einem anderen CMS ;)

Seit etwa 2 Jahren gibt es eine extrem gut Dokumentierte API - vorher war es undurchsichtig.

Da kann durchaus stimmen!

Nein, das stimmt sogar definitiv ;)

Das erklären des Systems ist auch noch so ne Sache. Es hat sich zu einer Cafe-Fahrt System entwickelt. Wer das System nutzen möchten, muss erstmal eine Schulung buchen wo das Geld aus der Tasche gezogen wird. Es ist immer die gleiche ausrede die ich höre. Ja, super easy easy.

Die Kunden mit denen ich zu tun habe brauchen sogar für Wordpress eine Schulung - da sind Leute die 0 Ahnung haben.

Und eine Schulung um 200 Euro spielt keine Rolle mehr, wenn man eine Website im oberen 5-stelligen Bereich gekauft hat.

Wenn das System ursprünglich ein Vollidiot konfiguriert hat - ja. Man _kann_ bei TYPO3 dasselbe an vielen verschiedenen Stellen machen - wenn jemand "herumprobiert" hat an verschiedenen Baustellen und dann durch zufall das richtige gefunden hat und dann seine Versuche nicht mehr bereinigt, ist das PITA - das hat aber nichts mit TYPO3 zu tun sondern mit dem Deppen der es so bedient.

Aus entwickler sicht, klickt man hier, oh geht nicht, ups muss ja noch dort klicken, uiii geht ja immer noch nicht.. ah stimmt noch dort paar werte eintragen und das mit einem eingepflegten 4.3 System.

Mal hier klicken und mal da und dann dort einen Wert eintragen ist kein entwickeln, das ist Trial&Error und hat mit ernsthaftem Arbeiten nichts zu tun.

Wenn man weiß, was man tut (und nicht in der Baustelle von jemandem herumgraben darf, der das nicht wusste) ist das überhaupt kein Problem. Und wenn es dennoch so ist: das ist kein Fehler von TYPO3. Ich kann auch CSS oder PHP so schreiben, dass es nur noch ich lesen kann.

Deswegen sagt man auch, die Konfigurationsprache.

Sagt man was?

Das sagt man, das weist du selber!

Nein, ich meinte ich kann dir nicht folgen. Irgendwie fehlt bei dem Satz etwas oder die Zeichensetzung ist falsch. Ich verstehe ich nicht.

Deswegen sagt man auch, die Konfigurationsprache [ist schlecht].
Deswegen sagt man auch "die Konfigurationsprache".

Was auch immer - bitte nochmal, in einer Sprache die ich auch verstehe :)

Schon mal Imperia gesehen?

Nein, was hat das mit Typo zu tun?

Du sagst, TYPO3 sei kompliziert - wenn du ein kompliziertes CMS sehen willst, schau dir Imperia an. Allerdings musst du da schon mal eine 5-stellieg Summe locker machen nur für die Lizenz ;)

Ich komme mit vielen dingen zurecht. Sehr gut sogar.

Wie schon irgendwo erwähnt: ich komm' mit Waschmaschinen nicht klar.

[suit]

Was habt ihr für Erfahrungen?

Ich mach' selbst kleine Seite mit nur wenigen Unterseiten mittlerweile ausschließlich mit TYPO3 - auch wenns der Overkill ist, aber ich bin so einfach schneller.

Der Unterschied ist: ich habe mit TYPO3 bereits ausreichend Erfahrung - für mich spielt es keine Rolle ob ich eine Seite mit 10 oder 10.000 Unterseiten mache. Eine TYPO3-Umgebung ist in etwa 30 Minuten eingerichtet, das Template in weiteren 30 Minuten eingebaut - der Rest ist HTML und CSS welches sowieso anfällt - bzw. PHP-Scripte die ich ohnehin programmieren müsste, wenn ich sie bräuchte. Ob ich die dann in eine TYPO3-Extension verpacke (mit ein paar Zeilen mehr Code) spielt keine Rolle mehr.

Wenn man aber nicht ernsthaft vor hat, TYPO3 auch zukunftig zu verwenden, ist der Aufwand sich für nur ein Projekt einzuarbeiten absolut unsinnig - sofern es sich nicht aus anderen Gründen lohnt (hoher Verdienst, Folgeaufträge ...).