Umbau CMS Types/Forms/Tags, Generalisierung und Aufbau eines globalen Handlers Einstellungen

[STam]

Nicht nur wünschenswert sonder auch für die Zukunft wichtig
erscheint mir eine Umbau der Type-Form/Func-Type im Zusammenhang
mit den CMS-Tags.

Ziel sollte es sein das Typen- und Form-Handler flexibel erweiterbar
und ensprechende CMS-TAGS frei definierbar sind. Dabei könnten schon
bestehende Handler wie BBCODE oder WYSIWYG mit übernommen werden.

Dazu sollten Typen- und Form-Handler global erstellt und
generalisiert werden. Einfache Type wie LINK, IMAGE, TEXT oder TEXTAREA
sollten als Basis dienen und Erweiterungen des Basis-Typs in
Form von Callbacks entwickelt werden.

Beispielhaft sei aufgeführt das BBCODE und WYSIWYG
nur Handler ausprägungen des gleichen Type sind: TEXTAREA.
Über das Attribute 'transform' wird schon heute der Handler
BBCODE definiert, allerdings ist er fest verdrahtet. Andere Handler
müssten extra eingepflegt werden und das an diversen Stellen,
was spätestens bei der dritten Erweiterung müßig wäre.
Andersherum beim WYSIWYG, dieser ist nur direkt über
ein CMS-TAG ansprechbar obwohl ein TEXTAREA Attribut transform="wysiwyg"
die gleiche Entsprechung haben könnte/müsste.

Handler könnten als SF-Erweiterung über Plugins oder sogar Module
direkt über die Db (ein)gepflegt werden.

Ein Wiki-Handler könnte als Modul mit beigelegter 'class.type_wiki.php'
daherkommen. Ein TEXTAREA mit dem Attribut transform="wiki"
würde ausreichen um es zu aktivieren, ein CMS-TAG <wiki></wiki>
könnte analog dazu greifen.
Genauso wäre zB ein Handler für IMAGE::SVG oder IMAGE::MATH zu erreichen
ohne das jedesmal der halbe Core angepaßt werden muss.

Gruß

[smail]

Ok, nach dem zweiten mal Lesen hab ich verstanden, um was es geht :-)
(Nein, nicht der Beitrag ist kompliziert geschrieben, das Thema ist wohl so komplex.)

Aber zur Sache:
Eine Verallgemeinerung in diesem Sinne macht durchaus Sinn. Wenn ich es richtig verstanden habe, soll es nur noch ein einziges cms-Tag geben:

QUELLTEXT

<cms:mod type="type" transform="transform-type" />

Durch die Angabe des transform-type wird schließlich bestimmt, wie der Inhalt zu interpretieren ist und durch welchen Parser er geschickt wird (bsp. wysiwyg, bbcode, wiki, textile...). Die Parser selbst könnten als Plugins realisiert werden, wodurch jeder seinen bevorzugten Markup-Code verwenden kann, ohne in den Core einzugreifen.


Für mich stellt sich aber noch eine Frage:
Wenn es wirklich nur ein einziges cms-Tag geben soll, macht es dann nicht mehr Sinn, anstatt des transform-Attributs direkt das Attribut type zu verwenden?
Wenn das FR nur auf die Textarea bezogen ist, muss es natürlich ein anderes Attribut sein.

Viele Grüße
Jan

[STam]

Hallo smail,

Wenn ich es richtig verstanden habe, soll es nur noch ein einziges cms-Tag geben...

Nicht so schnell, das ist nicht ganz richtig.
CMS-Tags sind ja ganz praktisch und auch vielfältig in Verwendung.
Ich will sie nicht abschaften sondern erweitern.

QUELLTEXT

<cms:mod type="type" transform="transform-type" />

Ist aber schon der richtige Weg das zu beschreiben was ich erreichen will
Grundsätzlich sind CMS-Tags ja nichts anderes als Xhtml Interpretationen für
SF interne Parsing Optionen (TRANSFORMATOREN), nur sind diese bisher halt 'zu fest gezurrt' und
nicht durchgängig umgesetzt.
Beispiel:
Grundlage ist der Type TEXTAREA, daraus resultiert:

QUELLTEXT

<cms:mod type="textarea" transform="text" />

für eine Textarea wo kein Html erlaubt ist.
- Edit: Textarea, Rendering:Text
- Optional: keine

QUELLTEXT

<cms:mod type="textarea" transform="html" />

für eine Textarea die es auch so in der Html-Entsprechung gibt.
- Edit: Textarea, Rendering:Html
- Optional: keine

QUELLTEXT

<cms:mod type="textarea" transform="bbcode" />

für eine Textarea die durch die BBCODE-Klasse geparsed wird.
- Edit: Textarea, Rendering:BBCODE/Html
- Optional: <cms:mod type="bbcode" />

QUELLTEXT

<cms:mod type="textarea" transform="svg" />

für eine Textarea die durch die SVG-Klasse geparsed wird.
- Edit: BBCODE/Textarea, Rendering:SVG/Image
- Optional: <cms:mod type="svg" />

QUELLTEXT

<cms:mod type="textarea" transform="wiki" />

für eine Textarea die durch die WIKI-Klasse geparsed wird.
- Edit: Textarea, Rendering:WIKI/Html
- Optional: <cms:mod type="wiki" />

QUELLTEXT

<cms:mod type="textarea" transform="wysiwyg" />

für eine Textarea die durch die WYSIWYG-Klasse geparsed wird.
- Edit: Wysiwyg/Textarea, Rendering:Html
- Optional: <cms:mod type="wysiwyg" />

QUELLTEXT

<cms:mod type="textarea" transform="sourcecode" />

für eine Textarea die durch die SOURCECODE-Klasse geparsed wird.
- Edit: Editor/Textarea, Rendering:Html
- Optional: <cms:mod type="sourcecode" />
(besondere Attribute habe ich jetzt mal ausgelassen)

Der eine oder andere wird vieleicht sagen, was bringst mir, sind ja nur mehr CMS-Tags als vorher?
Die Vorteile die ich damit erreichen will beruhen auf Typisierung und Vererbung.
Es ist demnach einfach einen Content der einmal mit dem WYSIWYG erstellt wurde,
durch den Parser TEXT zu jagen und nur den Textanteil zu rendern oder einen BBCODE Inhalt
in eine WIKI-Seite zu übernehmen, weil der TYPE der gleiche ist: TEXTAREA

Eine Erweiterung der TRANSFORMATOREN über Plugins ist ein weiteres feines Gimmick auf man sich dann freuen kann


Gruß

[mistral]

Hallo zusammen

Wenn ich das richtig verstehe würde das auch in die Richtung der hier vorgeschlagenen Textfilter API gehen.
http://forum.sefrengo.org/index.php?showtopic=257

Gruss
Mistral

[STam]

Yep, zumindest zum Teil

Das ganze ist ja eingeschlafen...
Ich kann nur das wiederholen was JB damals gesagt hat und zitiere da auch Björn:

Alles wegschmeißen und neu machen!

Wobei dann natürlich die Rückwärtskompatibilität beachtet werden muss.
Dort wurde ja über eine Texttransformations-API nachgedacht, die aber trotzdem nicht
den Kern von SF berührt und somit zwar zweckmäßig ist aber nicht weit genug geht.

Grundsätzlich gehe ich aber den Schritt den Kern von SF aufzuräumen und
die tief vergrabenen CMS-Tags CMS-Types und CMS-Forms anzufassen.
Diese Klassen sind deprecated und nageln das System fest
Ich hatte schon 2005/06 Diskussionen mit Björn darüber und für SF als Milestone geplant.
Es ging darum die Content-Typen als Objekte zu betrachten die aufeinander Aufbauen
und Abhängigkeiten abbilden können. Ein Tansformator ist dann nur noch eine
Methode und kann in beliebige Richtungen angewandt/abgeleitet werden.

Leider wurde damals schon nichts draus... und das wiederholt sich wohl wieder.

Es ist sicherlich nicht so das ich schon wieder das Rad neu erfinden will,
ich möcht es nur wieder zum drehen bringen und darauf aufmerksam machen.

Das was Björn schon einmal angemerkt hatte, nämlich das bei einer offenen
Schnittstelle niemand im System mehr weiß auf welcher Grundlage ein Content
bereitgestellt wurde kann man sehr schön über abgeleitete Typen Objekte abbilden,
die erweiterbar sein sollten (Schnittstelle).

...


Gruß

[Chregu]

Eine Frage, ich will dir nicht auf die Füsse tretten, aber warum machst du dich nicht an die Arbeit? Was einem stört sollte man doch ändern...
Oder wer bzw. was steht im Weg?

gruss
chregu

[smail]

sollte man doch ändern...
Oder wer bzw. was steht im Weg?

Grundsätzlich: JA. Es ist nur so: Die Änderungen, die STam vorschlägt, sind ziemlich tiefgreifend und man müsste schon tief in den Core rein. Da wäre es dann wünschenswert, wenn später nicht alles verworfen wird.

Einige - wie ich finde - gelungene Ansätze nach dem "ich mach mir mal die Arbeit"-Prinzip verliefen letztlich so leider im Sande. Populäre Beispiele hierfür wären:

• Olafs Thickbox 2 Sefrengo Implementierung fürs Backend
• Tiggrs Extended-Header Plugin (ich habe da die Hoffnung noch nicht ganz aufgegeben)
• STams Frontend Filemanager

Ich glaube auch, STam ist nicht gerade zurückhaltend, wenn es ums "Anpacken" geht. Dazu reicht ein Blick in das Forum SF Core Bugs (teils sogar incl. Bugfix). Reine Spekulation, aber: ich glaube z.B. dass sein SF viele der dort genannten Fehler nicht mehr enthält...
Dann gibt es bald Sefrengo STam-Edition

In diesem Sinne
Viele Grüße
Jan

[STam]

@chregu,

das FR- oder das Hacks/Sonstiges-Forum sind doch voll mit Arbeiten/Vorschlägen und sogar vollständigen Patches,
unter anderem von mir. Eingesetzt oder implementiert werden sie beileibe nicht nur deswegen weil irgend jemand
sich die Mühe gemacht hat...

STams Frontend Filemanager

... lebt noch, ich baue nur gerade ein wenig JQUERY ein
und dachte ich bevor ich zuviel integriere warte ich noch auf ne neue Version oder auf das Extend-Header Plugin

Derzeitiger Stand (nicht IE safe!): https://extranet.nrc.de Login->tester/test

Gruß

[Chregu]

Ich sehe eure Argumente und sehe auch hier gewisse Problematiken. Was der Vorschlag von STAM ohne Core-Eingriff nicht bzw. kaum realisiert werden kann ist mir auch klar. Aber wenn es ein dringendes Bedürfnis ist, sollte man es halt für sich umsetzen. Verstehst du was ich meine? Ich finde die Idee mit dem "transform" sehr gut und sehe darin sehr viele Vorteile...

Aus meiner Sicht wäre es wichtig die API weiter aufzubauen und mit den zum Teil grundlegenden Methodik zu erweitern. Aus meiner Sicht sollte man da offener Kommunizieren damit man auch sieht was, wann, wie, wo.... (so in etwa ;-))

[hkuhrt]

Derzeitiger Stand (nicht IE safe!): https://extranet.nrc.de Login->tester/test

Gruß

Das ist ein sehr schönes teil, hoffe auf eine schnelle fertig Stellung. Könnte es zb. momentan auch sehr gut gebrauchen.

Muss momentan auch ein Extranet aufbauen.

Gruß
Holger

[STam]

Das ist ein sehr schönes teil, hoffe auf eine schnelle fertig Stellung. Könnte es zb. momentan auch sehr gut gebrauchen.

Schönen Dank für die schnellen Tests
Auf manche Sachen die ich da seit gesternn in den Logs gefunden
habe wäre ich sebst nicht gekommen.
Bemerkenswert ist die Akribie mit der nach Bugs gesucht wird
Beispielhaft sei der Ordner 'eingaben werden wohl nicht so recht geprüft'
genannt... nun das Modul nutzt den SF-Filemanager mit den Funktionen die
da so rumliegen, die gefundenen Bugs sind also allesammt auch im
Backend nachvollziehbar

Gruß

[feniweb]

Irgendwie vermisse ich verschieben, kopieren, umbenennen usw.

Gruss