Grundsatzfrage Modulaufrufe

nicmare · 09. Juni 2011 09:05

Es ist ja sehr einfach, ein Modul in CMSms auszuführen. Man gibt einfach den entsprechenden Code mit {…} ein. Das ist besonders prima wenn man die Module im Template verankert.

Aber viele Module erfordern den Aufruf direkt im Content Block (zB Gallery).
Sicherlich läuft es auch außerhalb des Blocks. Aber um die vollste Funktionalität zu gewährleisten, muss es im Content Block eingefügt werden. Zumal es ja auch genug Kunden gibt, die gerne mal hier und da zu einer Inhaltsseite eine Galerie einbinden wollen. Und jetzt kommt das, was mich unheimlich nervt.

In TinyMCE wird ein einfacher Absatz (mit "Enter") erstellt:. Das finde ich super. Allerdings kann es dann passieren dass der Modulaufruf dann auch vom Paragraph gewrapped wird: {…} und das gibt dann Validierungsfehler. Sicherlich geht das auch in den TMCE Einstellungen mit aber das ist keine Lösung für mich.

Grundsätzlich finde ich die Art und Weise das Modul einzufügen mitlterweile ziemlich primitiv und rückständig. Früher fand ich es echt cool aber für viele Sekretärinnen ist das einfach nach wie vor zu kyrptisch. Da würde ich ein Checkboxliste mit zur Verfügung stehenden Modulen begrüßen, sodass der Kunde keine einzige Zeile Code schreiben muss.
Es gibt ansatzweise solche Funktionen. Allerdings bezieht sich das ja nicht auf den Content Block.

Vielleicht erreicht man sowas in der Art trotzdem mit dem AdvancedContent Modul? Man wähle das Modul aus und AC fügt es nach dem Speichern in den Block und bei erneuter Bearbeitung wird es wieder aus dem Block extrahiert?

Ich meine geht nur mir das so?? Bin ich der einzige der sich an dieser Methode stört? Ich habe irgendwo mal gelesen dass das dev Team der Ansicht ist, dass CMSms nichts für Sekretärinnen und Co ist sondern nur für Programmierer und Leute vom Fach. Diese Meinung teile ich nicht.

Andynium · 09. Juni 2011 10:55

nicmare schrieb:

Ich meine geht nur mir das so?? Bin ich der einzige der sich an dieser Methode stört? Ich habe irgendwo mal gelesen dass das dev Team der Ansicht ist, dass CMSms nichts für Sekretärinnen und Co ist sondern nur für Programmierer und Leute vom Fach. Diese Meinung teile ich nicht.

+1

Nach meinem Verständnis sind sich manche Leute zu fein oder zu bequem, umfassenden Support zu liefern. Damit meine ich, dass auch mal Fragen beantwortet werden, die über den CMSMS-Tellerrand hinausgehen (egal, ob nach oben oder unten auf der Kenntnis-Skala - eben so, wie wir es hier praktizieren)

Zur Lösung des von dir angesprochenen Problems waren ja nach meinem Verständnis unter anderem die Inhaltstypen vorgesehen ...

mike-r · 09. Juni 2011 11:11

Die Inhaltstypen helfen aber nicht, wenn man bspw. eine Galerie direkt im Inhalt haben möchte.

Ich bin Text.
{gallery}
Und nochwas dazu.

Zum Thema: kann ich mir schlecht vorstellen, wie man das Problem allgemeingültig - also auch sekretärinnenfreundlich - beheben könnte. Wie kommt eigentlich der CMS-Linker ins Tiny-Menü? Der macht doch was relativ ähnliches? Ginge da nicht was?
Würde allerdings immernoch nicht das p-problem lösen.

otter24 · 09. Juni 2011 11:33

Moin...

ja das mit den Galerien geht mir auch die Nerven... Aber ich hab da eben in den Tiny Einstellungen was gefunden. Ich hab im Augenblick keine weitere Zeit das zu testen. Vielleicht hilft das ja weiter.... siehe Sreenshot.

jeff1980 · 09. Juni 2011 12:05

@otter24: Jein - so kann man zwar die Gallery bzw. ein Formular in den Inhalt einbinden, ohne zu tippen (ist in etwa so wie der CMS-Linker) - allerdings bleibt das p-Problem.

Vor diesem Problem stehe ich auch oft. Ich stelle den Tiny in der Regel auch so ein, dass er Grundsätzlich schon mal den p-Tag setzt, da ich darüber dann den Text per CSS ansprechen kann. Falls nämlich nur ein Bild oder eine Zeile Text eingefügt wird, gibts kein p.
Im Falle der Gallery kommt dann ja leider sowas bei raus:

Hier klicken, um den Code zum Kopieren zu markieren

<p>
<div>
...
</div>
</p>

Ich habe mir bisher immer so beholfen, dass ich den WYSIWYG für die entsprechende Seite ausschalte und Inhalte über den Gallery-Kommentar eingegeben werden müssen. Nicht elegant und schon gar nicht flexibel.

Einen neuen Block für die Gallery einzurichten funktioniert leider auch nicht, da die Gallery standardmäßig im content-Block angezeigt wird.
Setze ich also den Gallery-Aufruf in ein {content block='gallery' wysiwyg='false'} und öffne dann eine Galerie, erscheint diese im eigentlichen Content und die Übergeordnete Galerie ist weiterhin sichtbar.

Helfen würde es, wenn man der Gallery sagen könnte, in welchem Block sie auftauchen soll. So etwas gibt es doch glaube ich beim Formbuilder und nennt sich "inline" bzw. eben nicht "inline".

nicmare · 09. Juni 2011 12:30

jeff1980 schrieb:

Helfen würde es, wenn man der Gallery sagen könnte, in welchem Block sie auftauchen soll. So etwas gibt es doch glaube ich beim Formbuilder und nennt sich "inline" bzw. eben nicht "inline".

habe ich schon als feature request abgeschickt aber der entwickler hats irgendwie nicht verstanden. aber das war jetzt auch nur EIN beispiel. finde ja die grundsätzliche Architektur ungünstig.

NaN · 09. Juni 2011 12:37

Könnte man das nicht auch einfach mit Hilfe der Ereignisverwaltung und eines UDTs lösen, der anhand eines regulären Suchmusters solche Sachen wie

Hier klicken, um den Code zum Kopieren zu markieren

<p>{...}</p>

rausfiltert und einfach nur

Hier klicken, um den Code zum Kopieren zu markieren

{...}

draus macht, sobald ein Inhalt geändert wird?

nockenfell · 09. Juni 2011 12:43

otter24 schrieb:

Moin...
ja das mit den Galerien geht mir auch die Nerven... Aber ich hab da eben in den Tiny Einstellungen was gefunden. Ich hab im Augenblick keine weitere Zeit das zu testen. Vielleicht hilft das ja weiter.

Damit das funktioniert, musst du diese beiden Befehle in die Menüleiste des Tinys einfügen. Also "gallery_picker" auf der Menuleiste einfügen.

nockenfell · 09. Juni 2011 12:45

NaN schrieb:

Könnte man das nicht auch einfach mit Hilfe der Ereignisverwaltung und eines UDTs lösen, der anhand eines regulären Suchmusters solche Sachen wie ....

Das wäre wahrscheinlich die einfachste Möglichkeit. Allerdings muss nicht jedes

Hier klicken, um den Code zum Kopieren zu markieren

<p>{...}</p>

auch so behandelt werden. Kommt immer darauf an ob {...} ein Modulaufruf oder auch nur eine Variable oder ein Plugin das dir die Zeit zurückliefert.

NaN · 09. Juni 2011 12:51

Hm, man könnte ja explizit nach {cms_module ... } suchen.
Dann kann man eben nicht mehr die moduleigenen Plugins wie z.B. {Gallery} nutzen.
Ansonsten sähe ich da keine Möglichkeit, wie das CMS wissen soll, wann ein Absatz sein darf und wann nicht.

mike-r · 09. Juni 2011 13:10

nockenfell schrieb:

Allerdings muss nicht jedes
Hier klicken, um den Code zum Kopieren zu markieren
{...}
auch so behandelt werden. Kommt immer darauf an ob {...} ein Modulaufruf oder auch nur eine Variable oder ein Plugin das dir die Zeit zurückliefert.

Ich glaube das wäre vernachlässigbar. Hinzu kommt, dass eine Ausgabe der Zeit (oder ein Link, oder irgendwas) semantisch nicht allein in ein p gehört, sondern eher in den vorigen Absatz. Ein anderes Szenario für ein alleinstehendes {...} fällt mir auch nicht ein.

kris29 · 09. Juni 2011 13:22

Mich stört das auch extrem mit den p-Tags um die {...}-Module. Außer mit jQuery den Modulinhalt zu 'unwrappen' ist mir nichts eingefallen. Eine Lösung mit UDT wäre da besser.

Andynium · 10. Juni 2011 05:40

NaN schrieb:

Könnte man das nicht auch einfach mit Hilfe der Ereignisverwaltung und eines UDTs lösen, der anhand eines regulären Suchmusters solche Sachen wie
Hier klicken, um den Code zum Kopieren zu markieren
{...}
rausfiltert und einfach nur
Hier klicken, um den Code zum Kopieren zu markieren
{...}
draus macht, sobald ein Inhalt geändert wird?

Da gibts ein (bereits etwas älteres) TinyMCE-Plugin namens CodeProtect, womit man bestimmte Bereiche von einer Formatierung via TinyMCE ausnehmen kann ... habs noch nicht mit der aktuellen Version getestet.

Klenkes · 10. Juni 2011 09:14

Das "Sekretärinnenproblem" ist sicherlich einer der Nervigsten und mir auch bekannt!

Momentan umschiffe ich es indem ich der Tinyconfig als zusätliche Styles für's Backend dies mitgebe:

Hier klicken, um den Code zum Kopieren zu markieren

div {border:1px dashed #009D00;}
p   {background-color:#FAFAFA;}

So hat man eine visuelle Orientierung was ein Absatz ist, und was ein DIV.
Mit einem laminierten Zettel von mir, neben den Bildschirm gepinnt, auf dem unter Anderem steht, daß Sachen mit {...} gün umrandet sein müssen, geht es meist ganz gut.
Von mir zwischen den Text gepackte Moduleaufrufe oder Smarty packe ich in class="mceNonEditable". So kann man nicht aus Versehen drin rumtippern.

Auch nicht optimal, aber was Besseres fällt mir auch nicht ein.

P.S. Dass Gallery außerhalb des Contents nicht geht, war mir gar nicht klar!

Bernd

nicmare · 10. Juni 2011 09:21

witzige/kreative "Umschiffung" Klenkes! So als Hinweis ne gute Sache. aber was machen wenn die Module erstmal in s "gefangen" sind? Dem Kunden sagen er soll die Codeansicht öffnen und den Übeltäter händisch entfernen? Das ist schon eine Zumutung für die meisten…
…Gallery geht schon außerhalb aber unter bestimmten Umständen kann es Probleme geben.

Andynium · 10. Juni 2011 09:37

mike-r schrieb:

Die Inhaltstypen helfen aber nicht, wenn man bspw. eine Galerie direkt im Inhalt haben möchte.
Ich bin Text.
{gallery}
Und nochwas dazu.

Sekretärinnen würde ich keinen Zugriff auf die Gallery geben wink - anstatt dessen eher 2 Inhaltsblöcke verwenden und {gallery} ins Template packen. Dann noch kombiniert mit Advanced Content für eine Modulauswahl und die Parameter in ein onerow-Feld oder eine Verzeichnisauswahl. NaN hatte da doch letztens was gepostet.

Klenkes · 10. Juni 2011 09:44

nicmare schrieb:

witzige/kreative "Umschiffung" Klenkes! So als Hinweis ne gute Sache. aber was machen wenn die Module erstmal in s "gefangen" sind? Dem Kunden sagen er soll die Codeansicht öffnen und den Übeltäter händisch entfernen? Das ist schon eine Zumutung für die meisten…

Na, so lange mceNonEditable gesetzt ist, und das mache ja nur ich, kann auch kein um den Modulaufruf sein.
Und sonst kann selbst auch mein unerfahrenster User den Cursor in den Aufruf setzen und aus dem Dropdown statt Absatz einenUnformatierten Bereich machen.

Klar! Codeansicht ist für den User ein NoGo.
("Hilfe! Herr Klenk! Das verstehe ich nicht und will es auch gar nicht")

nicmare · 10. Juni 2011 09:52

stört es dich nicht dass "mceNonEditable" dann auch im frontend erscheint oder hast du dafür auch ne lösung?

Klenkes · 10. Juni 2011 10:30

nicmare schrieb:

stört es dich nicht dass "mceNonEditable" dann auch im frontend erscheint oder hast du dafür auch ne lösung?

Warum? Das ist doch nur ein CSS Klassenname aus dem Tinyplugin.

nicmare · 10. Juni 2011 10:31

ja aber der wird doch dann auch im frontend angezeigt oder nicht?
und ich habs nicht so gern wenn im frontend unnötige klassen bzw divs ausgegeben werden big_smile

Klenkes · 10. Juni 2011 10:41

nicmare schrieb:

ja aber der wird doch dann auch im frontend angezeigt oder nicht?
und ich habs nicht so gern wenn im frontend unnötige klassen bzw divs ausgegeben werden

Da hast du allerdings recht.
Ich will eigentlich auch keinen Ballast, aber in einem speziellen Fall scheint mir dies das kleinere Übel zu sein. So schiesst sich die "Sekretärin" wenigstens nicht ins Knie und sonst auch nichts zusammen.

Ich wünsche mir auch eine sauberere Lösung.

Forum für CMS/made simple

#1 09. Juni 2011 09:05

Grundsatzfrage Modulaufrufe

#2 09. Juni 2011 10:55

Re: Grundsatzfrage Modulaufrufe

#3 09. Juni 2011 11:11

Re: Grundsatzfrage Modulaufrufe

#4 09. Juni 2011 11:33

Re: Grundsatzfrage Modulaufrufe

#5 09. Juni 2011 12:05

Re: Grundsatzfrage Modulaufrufe

#6 09. Juni 2011 12:30

Re: Grundsatzfrage Modulaufrufe

#7 09. Juni 2011 12:37

Re: Grundsatzfrage Modulaufrufe

#8 09. Juni 2011 12:43

Re: Grundsatzfrage Modulaufrufe

#9 09. Juni 2011 12:45

Re: Grundsatzfrage Modulaufrufe

#10 09. Juni 2011 12:51

Re: Grundsatzfrage Modulaufrufe

#11 09. Juni 2011 13:10

Re: Grundsatzfrage Modulaufrufe

#12 09. Juni 2011 13:22

Re: Grundsatzfrage Modulaufrufe

#13 10. Juni 2011 05:40

Re: Grundsatzfrage Modulaufrufe

#14 10. Juni 2011 09:14

Re: Grundsatzfrage Modulaufrufe

#15 10. Juni 2011 09:21

Re: Grundsatzfrage Modulaufrufe

#16 10. Juni 2011 09:37

Re: Grundsatzfrage Modulaufrufe

#17 10. Juni 2011 09:44

Re: Grundsatzfrage Modulaufrufe

#18 10. Juni 2011 09:52

Re: Grundsatzfrage Modulaufrufe

#19 10. Juni 2011 10:30

Re: Grundsatzfrage Modulaufrufe

#20 10. Juni 2011 10:31

Re: Grundsatzfrage Modulaufrufe

#21 10. Juni 2011 10:41

Re: Grundsatzfrage Modulaufrufe

Fußzeile des Forums