Gesammelte Werke

[stefan25376]

Liebe Contenido-Entwickler und -Benutzer,

Wie in einigen vorherigen Posts angedeutet nutze ich Contenido
sehr intensiv für Kunden. Ich arbeite dabei in größeren Netz-
werken, bestehend aus Designern, HTML-Layoutern und Programmierern.

Ich persönlich finde die Struktur und das Prinzip von Contenido
gut. Es erfüllt für mich die Dinge, die ich primär erwarte. Das
sind: Struktur, Benutzerverwaltung, Internationalisierung und
die Bereitstellung von Schnittstellen. Fertige Lösungen sind für
mich eher sekundär. Daher nutze ich Contenido auch für sehr
komplexe Anwendungen. Ich habe in den letzten Monaten Glossare,
Gästebücher, Foren und sogar komplexe Shops damit realisiert.

Ich habe mal einige Dinge, die mir aufgefallen sind gesammelt und
möchte diese nun schreiben. Für alle Lesefaulen wird das jetzt
hart werden.

----------------------------------------------------------------

1. Plugins.

Kürzlich habe ich mir das Blog-System bblog installiert. Das
System stellt an verschiedenen Stellen im Skript sogenannte
"Hooks" (deutsch: Haken) zur Verfügung, wo Plugins ansetzen
können.

Toll wäre es, wenn es im Contenido an allen relevanten Stellen,
d.h. Navigationen, Sub-Navigationen und Innereien "Hooks" gebe,
wo Plugins ansetzen könnten. Dann könnte man in der Kopf-
Navigation beispielsweise das "Newsletter-Plugin" einbetten.
Der Benutzer hätte aber auch die Möglichkeit, ein anderes
"Newsletter-Plugin" zu nutzen.

Ich persönlich finde, das das Newsletter-Modul im
krassen Gegensatz zur sonstigen Struktur von Contenido steht,
da es entgegen der sonst eher abstrakten Struktur von Contenido
doch sehr "konkret" wird.

Darüberhinaus finde ich den FCKeditor ungeschlagen. Unsere Kunden
sind ganz begeistert. Wäre toll, wenn der WYSIWYG über Plugins
gelöst wäre.

Bei bblog ist das so gelöst, das es einen zentralen /plugins-
Ordner gibt, in dem alle Plugins als .php enthalten sind. Jeder
Hook bekommt einen Namen, beispielsweise "main_navigation".
Jedes Plugin nimmt dann über den Dateinamen direkt Bezug auf
diesen "Hook"-Namen. Ein möglicher Dateiname wäre:

main_navigation.newsletter.php

Das würde den Vorteil bringen, daß man das System nicht dauernd
kompliziert patchen müßte. Diese Patches sind schwierig zu
veröffentlichen. Hinzu kommen dann noch Versionsunterschiede
etc.....

Man könnte die Plugins dann Gruppen-Nutzer-abhängig schalten.
Dann könnte der eine Kunden den tinyMCE und ein anderer den
FCKeditor nutzen. Je nach Geschmack!

Ein bißchen Träumerei: Meine Kunden haben oft Upload-Probleme
mit sehr großen Dateien. Ich hatte überlegt einen VPN-Server
zu installieren. Toll wäre es natürlich, wenn ich diesen
direkt in Contenido über ein von mir entwickeltes Plugin
konfigurieren könnte. Dann könnten alle Kunden auch bequem
und sicher VPN verwenden zum Datei-Upload. *schwärm*

----------------------------------------------------------------

2. smarty template engine.

Ich würde mich offiziell anbieten, Contenido auf die
"smarty template engine" zu portieren. Das bringt Vorteile:

2.1 Weniger und einfachere Templates
2.2 Eine ausgereiftere, perfomantere Engine, die ständig
weiterentwickelt wird
2.3 Eine einfachere Einbindung von Plugins (bblog basiert
auf smarty)
2.4 bessere Verknüpfung mit ebenfalls smarty basierten Systemen,
wie Newslettern, Shops etc.
2.5 Gründe, die ich in Punkt 3 nenne

Ich würde die Umstellung komplett nach Feierabend machen.

----------------------------------------------------------------

3. Templates & I18n

In letzter Zeit schreibe ich immer komplexere Module. Diese
erfordern teilweise die Nutzung von "Templates". Das HTML in die
Module zu schreiben bringt Nachteile:

3.1 Unübersichtlicher, unsauberer Module-Code
3.2 Keine oder erschwerte Internationalisierung
3.3 Probleme mit den Designern, die in meinem Code "wurschteln"

Darüberhinaus finde ich den Contenido-internen Namen
"Styles/Templates" nicht logisch. Templates sind im Normalfall
Inhalte mit Platzhaltern. Ich würde diesen Bereich eher
"Configurations" taufen, da dort ja Layouts mit Modulen
verknüpft und konfiguriert werden.

Man könnte dann einen Bereich "Styles/Templates" ins Leben rufen.
Dort könnten sprachabhängig Templates hinterlegt werden. Diese
könnte man dann später in die Module integrieren:

$template = "CMS_TEMPLATE[1]";

Nun könnte ich mit diesem Template arbeiten. Der Platzhalter
CMS_TEMPLATE[x] würde mit einem sprachabhängigen Template
gefüllt. Die Templates würden unter "Styles/Templates" vom
System automatisch durchnummeriert. Man kann dann einen
lesbaren Namen vergeben, mit Kommentar und Inhalt.

Ähnlich wie bei den Artikeln und Kategorien würde bei der
Erzeugung einer neuen Sprache einfach der "Ur-Inhalt"
einkopiert. Dann könnte man das Template übersetzen.

Ich hätte die Designer vom Hals. Die können sich mit dem Bereich
"Styles/Templates" und "Styles/Styleeditor" beschäftigen. Mein
PHP-Code bliebe unberührt.

Wenn man nun die smarty-template-engine schon integriert hätte,
könnte man in diesen Templates direkt diese Engine nutzen.

Die "Normal-Benutzer" bräuchten diesen Bereich ja nicht nutzen.
Das System würde nicht komplizierter, sondern im Gegenteil eher
mächtiger!

----------------------------------------------------------------

So! Das war es erstmal. Ich hoffe das Ganze ist einigermaßen
verständlich und nachvollziehbar.

Macht weiter so,

Stefan Jelner

[HerrB]

Ähm...

Toll wäre es, wenn es im Contenido an allen relevanten Stellen,
d.h. Navigationen, Sub-Navigationen und Innereien "Hooks" gebe,
wo Plugins ansetzen könnten.

Es gibt sowohl Plugins (die sich in die Menüs einklinken können, Beispiel: Hello World-Plugin von emergence), als auch Chains, mit den Funktionen in einen Ablauf integriert werden können (Beispiel: Upload-Chain, findet sich unter V4.4 im Forum).

Teilweise fehlt natürlich in den einzelnen Bereichen dafür notwendiger Code - der Wunsch besteht aber, nur die Kapazität zur Umsetzung fehlt.

Dann könnte man in der Kopf-Navigation beispielsweise das "Newsletter-Plugin" einbetten. Der Benutzer hätte aber auch die Möglichkeit, ein anderes "Newsletter-Plugin" zu nutzen. Ich persönlich finde, das das Newsletter-Modul im krassen Gegensatz zur sonstigen Struktur von Contenido steht, da es entgegen der sonst eher abstrakten Struktur von Contenido doch sehr "konkret" wird.

Die Möglichkeit, das flexibel zu gestalten, finde ich gut. Das mit dem "konkret im Vergleich zum Rest" verstehe ich nicht so; tatsächlich entspricht schematisch der Code für den Newsletter-Bereich den Code für die Frontend User. Es gibt mittlerweile die Möglichkeit, Plugins, die weitere Felder einbinden, zu verwenden.

Das das kein Plugin ist, hat zum einen historische Gründe (übrigens würde 4fb das aus Contenido rausnehmen, wenn ich es nicht pflegen würde). Anderseits wird es regelmäßig gewünscht (so dass noch nicht wirklich der Wunsch bestand, es herausnehmen zu können) und auch die nahtlose Einbindung in Contenido hat sich bisher als Vorteil erwiesen (Zugriff auf Objekte, Eigenschaften, Performance).

Es ist aber sicherlich eine gute Idee, die Möglichkeit der Einbindung alternativer Tools vorzusehen.

Darüberhinaus finde ich den FCKeditor ungeschlagen. Unsere Kunden sind ganz begeistert. Wäre toll, wenn der WYSIWYG über Plugins
gelöst wäre.

Gibt es m.W. auch schon für V4.6 hier im Forum - als Plugin nicht möglich, da einiges dranhängt, aber ein einmaliger Upload und Umstellung in der config.php genügt.

Bei bblog ist das so gelöst, das es einen zentralen /plugins-
Ordner gibt, in dem alle Plugins als .php enthalten sind. Jeder
Hook bekommt einen Namen, beispielsweise "main_navigation".
Jedes Plugin nimmt dann über den Dateinamen direkt Bezug auf
diesen "Hook"-Namen.

contenido/plugins - Beispiele, kann man dem Hello World-Plugin, dem
FrontendLogic-Plugin, dem FrontendUser-Plugins und den Empfänger-Plugins entnehmen.

2. smarty template engine. Ich würde mich offiziell anbieten, Contenido auf die "smarty template engine" zu portieren.

Reine Neugier: Meinst Du nur für die Module, für Layouts/Templates oder ganz Contenido?

Ansonsten: Wunderbar. Gern. Machen. Ich kann Dir nicht versprechen, dass es auch im offiziellen Core eingebaut wird, aber wenn sowas mal da ist, lässt sich da leichter überzeugen.

3. Templates & I18n

Kannst Du das nochmal anders erläutern?

Templates (Style -> Templates) sind die Kombination aus Layout und Modulen. Layouts sollten/können sprachunabhängig definiert sein. Module sollten sprachunabhängig gestaltet sein - dafür gibt es im Bereich Modul-Code die Funktion mi18n("Hello"), mit der jedes entsprechend programmierte Modul über die eingebaute Übersetzungsfunktion übersetzt werden kann.

Sprachabhängige Komponenenten in Layouts würde ich immer durch Container ersetzen, für die feste Module gesetzt werden, die wiederum die Mehrsprachigkeit berücksichtigen.

Die Templates, die bei Modulen Verwendung finden (Style -> HTML Editor <- und diese Bezeichnung wird sich auch noch ändern, denn die ist wirklich Murx) sollten ebenfalls sprachunabhängig gestaltet sein.

Gruß
HerrB

[stefan25376]

Hallo,

1. Ich bin wohl etwas falsch verstanden worden. Was ich meine, ist, daß ich Contenido eher abstrakt sehe. Es ist ein Werkzeug zur Erzeugung von Inhalten, Benutzerverwaltung, Internationalisierung etc. Die Struktur Layouts->Module->Templates ist simpel und bietet bestechende Möglichkeiten. Das heißt diese grundlegende Bereitstellung einer "Idee" oder Struktur ist das, was ich von einem CMS erwarte.

Einzelne Features, wie z.B. ein "Newsletter" sind rein strukturell eher Plugins. Darüber kann man natürlich streiten. Ich meine, das die Kern-Inhalte, das nackte Skelett von den Plugins deutlicher getrennt werden sollte. Das bringt mehr Klarheit, kleineren Code und Flexibilität. Es müßte auch machbar sein, den WYSIWYG per Plugin einbetten zu können. Statt oben in der Unter-Navigation des Artikels nur "Editor" stehen zu haben, könnte da ja auch "Editor (FCKeditor)" stehen. Eine Chain oder ein Hook an allen möglichen Stellen würde die Weiterentwicklung ohne Patches gehörig vorantreiben.

2. Da die Integration der smarty template engine einigen Aufwand bedeuten würde, muss ich das leider vorher wissen. Vielleicht sehen sich die Verantwortlichen das einmal an und geben mir dann Bescheid.

3. Auch bei der Internationalisierung bin ich falsch verstanden worden. Ich habe meine Module bereits internationalisiert. Aber über PHP-arrays!
Ob nun über eine i18n-Funktion oder so ist egal. Ich muss in jedem Fall weiter den Code zerhacken und überall in meinem HTML

<p><?php echo mi18n("Hello"); ?></p>

hinschreiben. Nicht gerade sehr sauber getrennt. In großen Projekten trennt man heutzutage Code von Markup von Formatierung. D.h. ich würde gern mit echten Templates arbeiten. Beispiel:

<p>Dein Name: {{{vorname}}}</p>

Wenn der User nun Englisch wählt, wird das sprachabhängige Template benutzt. Beispiel:

<p>your name: {{{vorname}}}</p>

Mein Code würde so aussehen:

$template = "CMS_TEMPLATE[1]";
$template = preg_replace('/\\{\\{\\{vorname\\}\\}\\}/','Stefan Jelner',$template);

Fertig!

Die Möglichkeit Templates in irgendeinem Ordner auf dem Server abzulegen finde ich nicht gut gelöst. Darüberhinaus ist die Frage der Internationalisierung dadurch nicht hinreichend gelöst.

Man bräuchte eine Datenbank-Tabelle, wo Templates abhängig von der "idlang" abgelegt würden. Das heißt dasselbe Template kann mehrfach existieren, ist nur in einer anderen Sprache. Wenn Contenido in einer Pflege-Schnittstelle eine automatische Nummerierung vornehmen würde, könnte man wie in obigem Beispiel verfahren.

d.h. Contenido vergibt meinem Template die Nummer 235:

$template = "CMS_TEMPLATE[235]";

so wäre das Template dann eingebunden. Je nach Sprache würde Contenido den obengenannten Platzhalter dann mit Template 235 in der aktuellen Sprache (idlang) füllen.

Zu i18n-Funktionen: Ich möchte ja das ganze Template bereits übersetzen und nicht einzelne Wörter per PHP-Funktion austauschen. Bei riesigen Projekten ersetz ich ja übermorgen noch........

Außerdem können die Templates ohne weiteres von einem Designer auch im WYSIWYG bearbeitet und übersetzt werden.

Bis dann,

Stefan Jelner

[HerrB]

2. Da die Integration der smarty template engine einigen Aufwand bedeuten würde, muss ich das leider vorher wissen. Vielleicht sehen sich die Verantwortlichen das einmal an und geben mir dann Bescheid.

Ich werde versuchen, diese Frage innerhalb der nächsten 2 Wochen zu klären.

3. Auch bei der Internationalisierung bin ich falsch verstanden worden. Ich habe meine Module bereits internationalisiert. Aber über PHP-arrays! Ob nun über eine i18n-Funktion oder so ist egal. Ich muss in jedem Fall weiter den Code zerhacken und überall in meinem HTML

<p><?php echo mi18n("Hello"); ?></p>

Bitte ganz sauber formulieren, welchen Bereich Du meinst!

Nehmen wir mal an, Du meinst die Modul-Templates (Style -> HTML Editor). Diese bindest Du z.B. als Objekt $tpl ein. Nun kannst Du im Template {PALIMPALIM} schreiben und im Modul-Code $tpl->('s', 'PALIMPALIM', mi18n("Funky Feature"));. Beispiel findet sich im Modul Hauptnavigation.

Ist das Modul-Template geeignet definiert, kannst Du mit sowas wie $tpl->('d', 'PALIMPALIM', mi18n("Your Name:")."nbsp;".$firstname); und $tpl->next(); auch mehrere Zeilen befüllen. Aus zwei Modul-Templates zaubere ich Dir eine komplette Tabelle mit beliebigen Spalten und Zeilen und individuellen Style-Angaben.

Das ist sogar weitaus abstrakter, als die sprachabhängigen Templates, denn es genügt für alle Sprachen ein Modul-Template, ein Modul-Code und nur bei Style -> Module -> Modul anklicken -> Übersetzung ist für die jeweilige Sprache eine Übersetzung einzutragen.

Wenn Du Templates (aus Style -> Templates) meinst, dann reden wir über sprachabhängige Layouts (Style -> Layouts). Hier gilt das oben Gesagte.

Die Möglichkeit Templates in irgendeinem Ordner auf dem Server abzulegen finde ich nicht gut gelöst. Darüberhinaus ist die Frage der Internationalisierung dadurch nicht hinreichend gelöst.

Überall ist (für Modul-Templates) Mandant/templates. Über das Template-Objekt kann aber auch ein beliebiges anderes Verzeichnis verwendet werden (evtl. Einschränkung: beliebig, aber innerhalb Mandantenverzeichnis).

Zu i18n-Funktionen: Ich möchte ja das ganze Template bereits übersetzen und nicht einzelne Wörter per PHP-Funktion austauschen. Bei riesigen Projekten ersetz ich ja übermorgen noch........

Ist mir in unerträglichem Umfang bisher nicht begegnet, aber das will nichts heißen. Wenn Du das Template-Objekt verwendest, geht das auch heute schon: $tpl->generate("templates/funkyfeature_".$lang."html");

Außerdem können die Templates ohne weiteres von einem Designer auch im WYSIWYG bearbeitet und übersetzt werden.

Das ist noch eine schöne Idee - hier dürfte der Online-Editor Steuerzeichen (z.B. {}) kodieren, dass müsste man dann noch berücksichtigen.

Gruß
HerrB

[stefan25376]

Hallo HerrB,

Danke erstmal für die anregende Diskussion. Was man dabei so alles über die Arbeitsweise anderer Leute lernen kann.

Ich muss feststellen, daß wir völlig andere Ansätze haben. Ich werde versuchen meinen etwas deutlicher zu machen.

Ein einfaches Beispiel: Ich habe eine Übersicht über Kunden in 3 Sprachen und hätte im Contenido ein Template
Nummer 235 erzeugt, das ich nun in drei Sprachen übersetzt hätte. (rein hypothetisch existiert ein Menüpunkt
"Styles/foo" über den man Templates mehrsprachig in der Datenbank ablegen kann)

Deutsch:

Code: Alles auswählen

<table>
 <thead>
  <tr>
   <th>Name</th>
   <th>Telefon</th>
   <th>E-Mail</th>
  </tr>
 </thead>
 <tbody>
{{{repeat}}}
  <tr>
   <td>{{{name}}}</td>
   <td>{{{phone}}}</td>
   <td>{{{email}}}</td>
  </tr>
{{{/repeat}}}
 </tbody>
</table>

Englisch:

Code: Alles auswählen

<table>
 <thead>
  <tr>
   <th>Name</th>
   <th>Phone</th>
   <th>Email</th>
  </tr>
 </thead>
 <tbody>
{{{repeat}}}
  <tr>
   <td>{{{name}}}</td>
   <td>{{{phone}}}</td>
   <td>{{{email}}}</td>
  </tr>
{{{/repeat}}}
 </tbody>
</table>

Französisch:

Code: Alles auswählen

<table>
 <thead>
  <tr>
   <th>Nom</th>
   <th>Téléphone</th>
   <th>Adresse e-mail</th>
  </tr>
 </thead>
 <tbody>
{{{repeat}}}
  <tr>
   <td>{{{name}}}</td>
   <td>{{{phone}}}</td>
   <td>{{{email}}}</td>
  </tr>
{{{/repeat}}}
 </tbody>
</table>

Nun mein Modul:

Code: Alles auswählen

<?php

$template = 'CMS_TEMPLATE[235]';
$search = preg_replace('/^.*(\\{\\{\\{repeat\\}\\}\\}.*?\\{\\{\\{\\/repeat\\}\\}\\}).*$/si',"$1",$template);
$replace = '';
$tr = preg_replace('/\\{\\{\\{\\/?repeat\\}\\}\\}/i','',$search);

//Hier wird irgendeine SQL-Tabelle ausgelesen
//.....

while($db->next_record()) {
	$temp = $tr;
	$temp = preg_replace('/\\{\\{\\{name\\}\\}\\}/i',$htmlentities($db->f('name')),$temp);
	$temp = preg_replace('/\\{\\{\\{phone\\}\\}\\}/i',$htmlentities($db->f('phone')),$temp);
	$temp = preg_replace('/\\{\\{\\{email\\}\\}\\}/i',$htmlentities($db->f('email')),$temp);
	$replace .= $temp;
}
unset($temp);
unset($tr);

$template = preg_replace('/'.preg_quote($search,'/').'/s',$replace,$template);
unset($search);
unset($replace);

echo $template;
unset($template);

?>

(Entschuldigt diesen schnellen und schmutzigen Code)

Was augenscheinlich ist:

1. Die Templates sind simpel und enthalten keinerlei Code
2. Das Modul ist simpel und enthält keinerlei HTML
3. Das Ganze ist internationalisiert.
4. Die Templates können auch in WYSIWYGs übersetzt werden
5. Die Templates liegen in der Datenbank

Man könnte das Ganze jetzt natürlich noch feiner gestalten durch eine Engine, die die
obigen regulären Ausdrücke schon übernimmt. Das würde den Code noch übersichtlicher
machen. (Obwohl: Ich oute mich hier als Perl-Liebhaber!)

Mit der smarty template engine kann man wesentlich komplexere Strukturen auf
Templates abbilden. Ich habe diese Engine bereits mehrfach verwendet und war
jedesmal begeistert. Ist aber Geschmackssache......

Mein Ansatz ist sicherlich anders. Ich lege sehr viel Wert auf getrennte Strukturen.
Wie gesagt, in Teams treten die wildesten Sachen auf. Einmal hatte ich deutsche
Umlaute in regulären Ausdrücken. Nachdem der Designer die Datei unter OS X im
Dreamweaver bearbeitet hat, waren das Encoding und die Umlaute total Schrott. Es
half auch kein iconv mehr! Daher habe ich meinen Code immer gern getrennt.
Außerdem mache ich keine Übersetzungen für meine Kunden. Das sollen schön die selbst
oder der Designer machen.

Bis dann,

Stefan Jelner

[stese]

Hi,

ja interessante Punkte, aber gerade im Bereich Templates ist es
momentan recht schön, so getrennt zu arbeiten, eben weil man die
Übersetzungen etc. alles dem Anwender überlassen kann und diese
nicht hardcoded im HTML stehen.

zu sehen bspw. hier bei meinem Download Modul

Ich persönlich vertrete die Ansicht, dass z.B. in Templates so gut wie
keine Kontrollstrukturen zu finden sind, nur Platzhalter - die ganzen
Kontrollmechanismen, soll das PHP Script erzeugen. Das hält den Code
clean und jeder weiß, wo er zu suchen hat. Dem widerspricht Smarty,
mit den Möglichkeiten, die es bietet. So kann man theoretisch echt
komplexe Sachen direkt in dem Template deklarieren. Das hat zur Folge,
dass ich an zwei Stellen suchen muss, wenn irgendwo ein Logikfehler
auftritt. Gerade wenn man mit meheren Leuten an Projekten arbeitet, ist
die wahrscheinlichkeit groß, dass Code nicht sehr sauber und strukturiert
ist und mitunter in Dateien abgelegt wurde wo er unlogisch ist (selbst
Contenido ist da nicht ganz frei von).

Das mit dem Newsletter ansich ist eine gute Idee, den als eigenständiges
Plugin zu schreiben. Ich verwende Grundsätzlich keine PHP Newsletter,
weil die ab einer bestimmten Größenordnung einfach jeden Server in die
Knie zwingen werden. Daher könnte man diesen einfach sauber entfernen,
falls er Ballast ist, bzw. man könnte verschiedene Newsletter-Plugins
einbinden, die unterschiedliche Aufgaben zu bewältigen haben.

Die Hooks oder Chains gibt es ja, wie HerrB schon geschrieben hat,
allerdings würde ich mir wünschen, wenn diese auch schon an diversen
Stellen in der front_content.php im Frontend greifen würden, oder habe
ich da was übersehen?

Genrell würde ich dir, Stefan, raten, dir mal die Plugins genauer
anzuschauen. Module werden einfach mit der Zeit zu unübersichtlich,
um komplexe sachen damit zu machen. Der Vorteil am Plugin ist
ja, dass man bestimmten Personen die Rechte dafür geben kann oder
auch nicht und man einen wirklich sauberen und abgeschlossenen
Coding-Bereich hat, in dem wirklich alles relevante von Contenido,
allerdings auch nur deine eigenen Änderungen zur Verfügung stehen.
(sprich i18n, templates, grafiken, klassen etc - alles fein getrennt)

[stefan25376]

Hallo,

War von meiner Seite etwas unglücklich gewählt mit den Templates. Diese enthalten natürlich eine sich wiederholende Struktur. Man könnte die Templates natürlich auf pure Platzhalter reduzieren. Mir ging es auch eher um die Themen:

1. Templates in der Datenbank
2. Templates ähnlich wie Kategorien oder Artikel sprachabhängig pflegen
3. Einbindung durch Platzhalter (ähnlich den Containern oder CMS_*-Platzhaltern)

Ich habe bereits bemerkt das viele Leute gemischte Gefühle zur smarty template engine haben. Ich persönlich finde auch, daß man es übertreiben kann mit den Kontrollstrukturen. Meine smarty templates sehen eigentlich immer recht simpel aus.

Plugins werden für mich immer dann notwendig, wenn strukturell das CMS eine Lösung nicht mehr abbilden kann. Wie bei einem Newsletter-System, bei einer VPN-Administration, LDAP, RSS etc. Ein Shop, ein Forum oder ein Gästebuch bestehen grob gesehen auch aus Artikeln. Die Inhalte können also mit den CMS_*-Möglichkeiten abgedeckt werden. Habe ich so auch bereits realisiert. Läuft prima und performant.

Bis dann,

Stefan Jelner

[HerrB]

Das mit dem Newsletter ansich ist eine gute Idee, den als eigenständiges Plugin zu schreiben. Ich verwende Grundsätzlich keine PHP Newsletter, weil die ab einer bestimmten Größenordnung einfach jeden Server in die Knie zwingen werden. Daher könnte man diesen einfach sauber entfernen, falls er Ballast ist, bzw. man könnte verschiedene Newsletter-Plugins einbinden, die unterschiedliche Aufgaben zu bewältigen haben.

Naturgemäß breche ich eine Lanze für "mein" Baby und nix gegen weitere Lösungen/Plugins/Alternativen, aber...

... lassen wir die Kirche im Dorf.

Die Newsletter-Funktion ist nicht für tausende Newsletter mit zehntausenden von Empfängern mit einem täglichen Senderaster konzipiert. Es ist sicherlich kein High-End-Newsletter-System.

Wird der aktuelle Code verwendet, sind aber 5000 und mehr Empfänger kein Problem - auch nicht für den Server (die Gruppen-Administration ist anstrengend). Es hängt nur von der Leistungsfähigkeit des Servers ab, wie lange man beim Senden zugucken muss.

Mit der nächsten Überarbeitung wird der HTML-Newsletter, eine Newsletter-abhängige Versandoptionsspeicherung (da weiss jetzt keiner, was damit gemeint ist ... , ein Database-Log und eine Resume-Funktion kommen.

Es wäre damit IMHO auch möglich, den Versand via echtem cronjob im Hintergrund zu erledigen.

Die Funktion ist kein Ballast, da die Funktionen, Klassen und Tabellen unabhängig vom Rest sind.

@stefan25376:
funkytemplate.html:

Code: Alles auswählen

<table> 
 <thead> 
  <tr> 
   <th>{HEADER_NAME}</th> 
   <th>{HEADER_PHONE}</th> 
   <th>{HEADER_MAIL}</th> 
  </tr> 
 </thead> 
 <tbody>
<!-- BEGIN:BLOCK -->
  <tr> 
   <td>{NAME}</td> 
   <td>{PHONE}</td> 
   <td>{MAIL}</td> 
  </tr> 
<!-- END:BLOCK -->
 </tbody> 
</table>

Code: Alles auswählen

<?php 
cInclude("classes", "class.template.php");

$sTemplate = 'funkytemplate.html'; 
$oTpl          = new Template;

// Headline
$oTpl->set('s', 'HEADER_NAME', mi18n("Name:"));
$oTpl->set('s', 'HEADER_PHONE', mi18n("Phone:"));
$oTpl->set('s', 'HEADER_MAIL', mi18n("E-Mail:"));

//Hier wird irgendeine SQL-Tabelle ausgelesen 
//..... 

while($db->next_record()) {
   $oTpl->set('d', 'NAME', $htmlentities($db->f('name')));
   $oTpl->set('d', 'PHONE', $htmlentities($db->f('phone')));
   $oTpl->set('d', 'MAIL', $htmlentities($db->f('email')));
   $oTpl->next();
} 

echo $oTpl->generate("templates/".$sTemplate); 
unset($oTpl);
unset($sTemplate);
?>

Sowohl das eine Template, als auch der Modul-Code ist ausreichend für alle Sprachen ... funky, isn't it?

Gruß
HerrB

[stese]

@HerrB
Das sollte nix gegen deinen Newsletter sein ;) er ist auch recht mächtig. Und es gibt genügend Leute die das über nen Webserver machen und dafür ist das doch super. Ich halt nicht. Ich bin halt der Meinung, dass man non Core Funktionalitäten nicht fest implementieren sollte - aber da bin ich wohl Typo3 geschädigt. Als Entwickler arbeite ich halt lieber in nem reinen Framework.

aber zu sehr OT.

[stefan25376]

Hallo,

@HerrB: Wo kommt denn die endgültige Information für

mi18n("Name:")

her? Aus einer Datei, die assoziative Arrays mit den endgültigen Sprachdaten enthält? Solche Dateien kann aber nur jemand mit Erfahrung bearbeiten.

Darüberhinaus muss ich diese Dateien doch auf dem Server ablegen?
Ich arbeite im Moment auch mit auf dem Server liegenden Templates und Zusatzfunktionen. Finde ich nicht wirklich sauber und flexibel gelöst.

Der Vorteil meines Verfahrens ist, das neben dem puren Ersetzen von Textinhalten sogar länderspezifische HTML-Anpassungen eingebaut werden könnten, die über CSS hinausgehen. Außerdem würden nur echte "Modul-Erzeugnisse" ersetzt. (wie sie in der while-Schleife stehen)

Ich persönlich argumentiere für die Designer und HTML-Layouter. Ich weiß, daß viele Programmierer gern für sich selbst argumentieren. Aber in meinen Netzwerken hat sich meine Vorgehensweise bewährt. Mein HTML-Layouter kommt mit den Templates super zurecht und macht im WYSIWYG die Übersetzungen. Ich bin nur für die Technik zuständig.

Für mich ist es natürlich kein Problem, das bisher schon brutal für meine Anforderungen gepatchte Contenido weiter zu patchen. Aber bevor ich sowas mache, frage ich lieber nach, ob das für Alle nützlich ist oder ob es einen besseren Weg gibt. Denn auch ich kenne nicht alle Möglichkeiten, da meine Zeit begrenzt ist.

@stese: Kann ich Dir nur beipflichten. Jeder der den Newsletter nicht braucht, lädt ihn nicht mit herunter und hat ihn auch nicht im System. Wenn Drittanbieter dann eigene Plugins für Newsletter herausgeben, kann man sich später immer noch entscheiden. Aber vielleicht bin ich auch nur ein Prinzipienreiter.

Bis dann,

Stefan Jelner

[stese]

@stefan
die mi18n() gescichten findest du im menüpunkt "Übersetzungen" im Modul Untermenü (gleich neben Historie)

Das ist aber m.E. erst seit Version 4.5.x der fall - also wenn du nur mit älteren Versionen arbeitest, dann schau dir unbedingt die aktuelle an - das is schon nen mächtiger schritt gegenüber der 4.4.x.

die normalen templates kannst du über style/HTML Editor auch online ändern, werden aber physikalisch im mandanten/templates verzeichnis als .html gelagert.

[stefan25376]

Hallo,

@stese: Danke für die Erläuterung. Muss mir das mal genauer zu Gemüte führen. Werde das in einem meiner neuen Projekte mal einsetzen. Vielleicht löst das meine Probleme hinreichend.

Ich denke ich muss meine bisherigen Erfahrungen mit Templates mal über Bord werfen und einen neuen Weg probieren. Dieser Ansatz ist ja gänzlich anders als der anderer Engines, wie beispielsweise der smarty template engine.

Danke bis hierher an alle für diese fruchtbare Diskussion. Werde demnächst sicher wieder nerven.

Bis dann,

Stefan Jelner

[HerrB]

Na, sage ich doch.

Übrigens ist das der Bereich Misc V4.6, ich bin daher davon ausgegangen, dass eine solche auch eingesetzt wird. Angaben wie "Style -> HTML Editor" waren auch nicht als Art Deco gemeint, sondern entsprechen den aufzurufenden Menüpunkten. Wie man an die Übersetzung kommt, habe ich oben detailliert geschrieben ... :

Style -> Module -> Modul anklicken -> Übersetzung ist für die jeweilige Sprache eine Übersetzung einzutragen

Es sei eine Einschränkung des Contenido-Template-Systems genannt: Es kann pro Template nur einen Block-Bereich geben.

Gruß
HerrB