Content2 / XContent / AdvancedContent ...

[nicmare]

ah ok! dann noch eine andere Frage bzw Anregung. Angenommen ich habe einen CMSms Bestand mit 20 Unterseiten. Wenn ich jetzt nen "unwichtigen" content_block hinzufüge (zB "Notizen") dann will ich eigentlich dass der standardmäßig ausgeblendet ist (also toggle +/-). Aktuell muss ich dann nämlich in jede Unterseite gehen und den block ausblenden (Minus-Button).

Außerdem fände ich es gut wenn man in den Einstellungen vom Modul ne Option hat, das Ablaufdatum auszublenden (inkl. dem AdvancedContent Tab). Weil ich dafür noch nie ne Verwendung hatte.

[NaN]

Der Blocktyp "note" fliegt in der nächsten version sowieso raus.
Sowas hat nichts im Seitentemplate zu suchen.
Ich werde eine Möglichkeit einbauen, Notizen etc. über die Moduladministration anzulegen und einzelnen Templates zuzuordnen. Da kann man dann auch angeben, ob ein oder ausgeblendet.

Außerdem habe ich vor, die Darstellung der Inhaltsblöcke über eigene Templates anpassen zu lassen. Dann sind dem Erscheinungsbild im Backend kaum noch Grenzen gesetzt.
(Evtl. lässt sich auch so zumindest die Sache mit den BlockTabs mit dem {content_module} Tag umsetzen)

Eine Option, um festzulegen, welche AdvancedContent Einstellungen im Backend angezeigt werden, ist keine schlechte Idee. Dabei würde der AdvancedContent Tab erst dann angezeigt werden, wenn mindestens eine Einstellung ausgewählt ist.

Wenn Du den Tab komplett ausblenden willst, gibt es momentan nur die Möglichkeit, Deinen Useraccount einer Gruppe zuzuordnen, die nicht die Berechtigung "Manage AdvancedContent Options" hat.

[nicmare]

ok! das mit den Notizen war ein blödes beispiel! ich wollte nur damit ausdrücken dass ich von hause aus viele content blöcke anlege aber nicht jede seite jeden block brauch. deswegen wäre es gut wenn es nen parameter gäbe der default mäßig den block ausblendet. nach dem motto status="collapse" oder einfach nur {content block="…" collapse}. ist mir klar dass der wert dann überflüssig ist sobald der block einmal aufgemacht wurde.

[NaN]

Achso, ok, das dürfte kein Problem werden.
Hab im SVN (tags/0.5.+) den Parameter "collapse" hinzugefügt.
Der ist entweder true oder false.
Standard ist false.
Um Blöcke also als Grundeinstellung auszublenden muss man einfach nur

Code: Select all

{content ... collapse=true}

hinzufügen.

[nicmare]

Dann auch noch ne andere Frage die wohlmöglich dich nicht tangiert. Aber kann man den "Erweiterten Inhalt" als Standard-Inhaltstyp definieren? In den Seitenvorgaben gibt es keine entsprechende Option und beim Modul selbst auch nicht. Ich verpeile immer den Typ zu wechseln bzw ist das ganzschön nervig.

[nockenfell]

Dann auch noch ne andere Frage die wohlmöglich dich nicht tangiert. Aber kann man den "Erweiterten Inhalt" als Standard-Inhaltstyp definieren? In den Seitenvorgaben gibt es keine entsprechende Option und beim Modul selbst auch nicht. Ich verpeile immer den Typ zu wechseln bzw ist das ganzschön nervig.

http://forum.cmsmadesimple.org/index.ph ... #msg215160

[nicmare]

thx, ich habs schon vermutet! weiß jemand ob das team dran interessiert ist diesen parameter in den seitenvorgaben aufzunehmen?

[nockenfell]

Du kannst ja mal einen Feature-Request machen.

[cyberman]

deswegen wäre es gut wenn es nen parameter gäbe der default mäßig den block ausblendet. nach dem motto status="collapse" oder einfach nur {content block="…" collapse}.

Vor längerem hat @Sonya ein Template erstellt (ist eher ein Template-Builder), in dem das Ein-/Ausblenden von Blöcken auf interessante Weise gelöst ist - schau es dir einfach mal an

http://www.icms.info/uploads/files/tpl/galapurity.zip

[NaN]

Vor längerem hat @Sonya ein Template erstellt (ist eher ein Template-Builder), in dem das Ein-/Ausblenden von Blöcken auf interessante Weise gelöst ist - schau es dir einfach mal an

Es ging um die Darstellung der Blöcke im Backend

[nicmare]

so ist es!
NaN! noch ne andere Frage! Für wie realistisch hältst du es dass man content blöcke zusammen in ein Fieldset legen kann? Bis jetzt gibt es ja für jeden Block ein eigenes Fieldset. Aber normalerweise ist ein fieldset ja dafür da, elemente semantisch zu gruppieren.
Ich fände es nämlich noch grandios wenn man das könnte.
Im Anhang siehst du mal ein Beispiel.
Von diesen paarweisen Feldern habe ich ca. 10 Stück! Hintereinanderweg würde das natürlich übersichtlicher aussehen wenn die sich ein fieldset (mit toggle) teilen würden. Ich denke das wäre ein weiterer Schritt richtung usability und komfort für den Redakteur.

BTW: der description parameter ist genial! so einfach und doch so sinnvoll…

[NaN]

Darüber habe ich auch schon nachgedacht.
Aber zum Gruppieren einzelner Blöcke hatte ich eigentlich die Blocktabs vorgesehen.
Die Fieldsets habe ich nur eingebaut, um die Blöcke besser voneinander abzugrenzen, weil man manchmal einen Contentblock vom Typ checkbox nicht mehr vom "WYSIWYG aktivieren/deaktivieren" unterscheiden konnte.

Wenn ich jetzt z.B. einen neuen Parameter "group" einführe, um einzelne Blöcke zusammen in einem Fieldset zu gruppieren, aber jeder Block einen anderen Pagetab bzw. Blocktab hat... da bin ich mir noch nicht ganz sicher wie ich das lösen soll bzw. welcher Parameter Vorrang hat.

Mein erster Gedanke wäre, groups pro Tab zu definieren.
(So wie ja die Blocktabs auch pro Pagetab gelten)
Bsp.:

{content block="block1" group="group1"}
{content block="block2" group="group1"}
{content block="block3" page_tab="custom tab" group="group1"}
{content block="block4" page_tab="custom tab" group="group1"}

Das würde sowohl im ersten Tab als auch im Custom Tab eine Gruppe 1 (also ein Fieldset) mit jeweils den Blöcken1,2 und 3,4 ergeben.
Sollte also machbar sein.

Ich verfolge übrigens einen neuen Ansatz, mit dem die meisten Sachen nicht mehr mit dem AdvancedContent Inhaltstypen, sondern über den {content_module} Tag realisierbar sind. Wenn es so klappt, wie ich mir das vorstelle, dann werden sowohl {AdvancedContent} Tag als auch Inhaltstyp überflüssig und ich dafür total happy sein

Und wie gesagt, ich versuche, die Ausgabe über Templates zu steuern, sodass sich jeder sein Backend selbst zurechtbasteln kann

Ich hab nur im Moment nicht viel Zeit, um das alles auszuprobieren.
Erstmal muss GBFilePicker fertig werden. (der wird echt cool, da kann sich dann auch jeder seinen eigenen filebrowser basteln )

Und dann hoffe ich mal, dass CMSms 1.9 nicht alzuviele Kompatibilitätsprobleme mit sich bringt. Da sehe ich nämlich schon die erste Flutwelle von Supportanfragen... 

[nicmare]

jo. ich sortiere schon mit tabs aber ich habe eben sehr viele felder und deswegen wäre das gruppieren in fieldsets ne feine sache. genau wie du es dir vorstellst...
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? weil aktuell steuer ich das backend über templates für den erweiterten inhalt und benutze in den templates selbst globale inhaltsblöcke für header und footer um schön flexibel zu bleiben

[NaN]

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.

[nicmare]

okay. na mal sehen!
derweil habe ich noch ein wenig nachgedacht und wenn wir schon dabei sind:
was hältst du von teilüberschriften nach diesem schema:
{content block="block2" headline="Eine Überschrift" block_type="dropdown"…}
Hat im Grunde garkeine Funktion für das Frontend aber soll dem Redakteur die Übersicht im Backend erleichtern. So kann er Felder schneller erfassen. Ich kann mich da nur noch mal wiederholen. Ich habe einfach sehr viele identische, sich wiederholende Felder. Und da wird das schon mal unübersichtlich