nicmare wrote:
das content_module ist ja noch ziemlich neu ne? aber wie soll das dann in zukunft ablaufen? weil du schreibst dass es advancedcontent ablösen könnte! wie würde man es dann verwenden?
An der Funktionalität würde sich nicht viel ändern.
Nur die Anwendung wäre dann etwas anders. (um nicht zu sagen besser, weil bessere Kompatibilität zum Core etc.)
Also ich stelle es mir so vor wie mit dem GBFilePicker:
{content_module module="AdvancedContent" block_type="checkbox" block_tab= ...}
D.h. der Standardinhaltstyp macht dann nichts weiter als die Ausgabe des Blocks im Backend dem Modul zu übergeben. Dann braucht man also nicht mehr den Inhaltstypen zu wechseln. Wodurch dann auch wieder weniger Probleme mit anderen Modulen entstehen, die nur nach dem normalen Inhalstypen suchen.
Allerdings müsste man im Frontend den Tag dann so aufrufen:
{content_module ... assign="output"}
{eval var=$output}
weil sonst keine Smartytags im Inhalt verarbeitet werden.
{content_module} gibt den Inhalt momentan einfach nur so aus, wie er in der Datenbank gespeichert wurde.
Das hat allerdings den Vorteil, dass man noch dies oder jenes prüfen kann bevor man den Inhalt wirklich verarbeitet.
Mal sehen, ob das so bleibt.
Der normale Inhaltstyp bietet eine Funktion, mit der man sich die Inhaltsblöcke als Array geben lassen kann. D.h. AdvancedContent würde sich einfach bereits beim ersten Aufruf alle Inhaltsblöcke geben lassen, prüfen, welcher davon mit {content_module module="AdvancedContent"} aufgerufen wurde, und dann die Ausgabe entsprechend vornehmen wie es jetzt der Fall ist (also Blöcke in Tabs gruppieren - zumindest erstmal in Blocktabs, bei den Pagetabs weiß ich noch nicht, ob und wie ich das lösen kann. Es gibt auch noch eine Funktion mit der die Pagetabs gesetzt werden, ich weiß allerdings nicht, ob ich da vom Modul aus drauf zugreifen darf bzw. ob das an dieser Stelle überhaupt noch einen Sinn hat - eher nicht, weil der Inhaltstyp dann bereits beim auslesen der Tabs ist.)
D.h. anstelle einfach nur eines Inhaltsblocks pro Block-Tag auszugeben, würde AdvancedContent gleich beim ersten Aufruf alle AdvancedContent Inhaltsblöcke ausgeben (und sich dabei merken, dass es bereits ausgeführt wurde, damit nicht beim nächsten Aufruf alles nochmal ausgegeben wird).
Problem wäre allerdings, dass dann die Reihenfolge im Backend nicht mehr ganz so stimmt wie im Template vorgegeben. D.h.
{content}
{content_module block="Block 1"}
{content block="Block 2"}
{content_module block="Block 3"}
würde im Backend dann so aussehen
Content
Block 1
Block 3
Block 2
Da muss mann dann halt beim Planen des Templates drauf achten bzw. sich vom Backend nicht verwirren lassen.
Aber wie gesagt, das sind nur Ideen, die ich erst noch ausprobieren muss. Vor allem im Zusammenhang mit CMSms 1.9, weil Calguy angekündigt hat, dass einige Variablen und Funktionen, auf die bislang noch von Modulen aus zugegriffen bzw. die einfach neu gesetzt werden konnten, demnächst (wie schon lange vorgesehen, aber von PHP4 nicht unterstützt) als "private" deklariert werden, wodurch man bestimmte "Hacks" einfach nicht mehr ausführen kann. (Daher weiß ich eben nicht, ob das mit den Pagetabs funktionieren wird.)
D.h. wenn die Devs für bestimmte Sachen keine Alternativen einbauen (weil ihrer Meinung nach nicht nötig), dann komme ich mit meiner Idee vermutlich nicht weiter. Aber sie nehmen derzeit Ideen und Vorschläge auf. Ist also noch nicht alles verloren.
Aber keine Sorge, das sind eh erstmal nur Zukunftsvisionen.
So schnell wird sich an AdvancedContent erstmal nichts ändern bzw. würde man es bis auf den Wechsel des Tags im Template (und evtl. den Verlust der Pagstabs) kaum merken. Aber das würde dann eh erstmal eine Weile alles Parallel laufen. olange bis ich weiß, ob und wie man dabei auf einen zusätzlichen Inhaltstypen verzichnetn kann.
