Umbau CMS Types/Forms/Tags, Generalisierung und Aufbau eines globalen Handlers |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
Umbau CMS Types/Forms/Tags, Generalisierung und Aufbau eines globalen Handlers |
Fri. 11. January 2008, 13:55
Beitrag
#1
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
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ß |
|
|
Sun. 13. January 2008, 13:01
Beitrag
#2
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 587 Mitglied seit: 01.07.2006 Mitglieds-Nr.: 62 |
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 -------------------- Zufall ist das Pseudonym, das Gott sich zugelegt hat, wenn er unerkannt bleiben möchte.
|
|
|
Mon. 14. January 2008, 17:10
Beitrag
#3
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
Hallo smail,
ZITAT 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ß |
|
|
Wed. 16. January 2008, 22:38
Beitrag
#4
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 343 Mitglied seit: 26.06.2006 Wohnort: CH Mitglieds-Nr.: 5 |
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 -------------------- So einfach wie möglich, aber nicht einfacher!
(Albert Einstein) |
|
|
Wed. 16. January 2008, 23:16
Beitrag
#5
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
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: ZITAT 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ß |
|
|
Wed. 16. January 2008, 23:41
Beitrag
#6
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 334 Mitglied seit: 10.07.2006 Wohnort: luzern (Schweiz) Mitglieds-Nr.: 128 |
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 |
|
|
Thu. 17. January 2008, 00:26
Beitrag
#7
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 587 Mitglied seit: 01.07.2006 Mitglieds-Nr.: 62 |
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:
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 -------------------- Zufall ist das Pseudonym, das Gott sich zugelegt hat, wenn er unerkannt bleiben möchte.
|
|
|
Thu. 17. January 2008, 00:49
Beitrag
#8
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
@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... ZITAT STams Frontend Filemanager ... lebt noch, ich baue nur gerade ein wenig JQUERY einund 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ß |
|
|
Thu. 17. January 2008, 08:03
Beitrag
#9
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 334 Mitglied seit: 10.07.2006 Wohnort: luzern (Schweiz) Mitglieds-Nr.: 128 |
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 ;-)) |
|
|
Thu. 17. January 2008, 08:17
Beitrag
#10
|
|
Advanced Member Gruppe: Members Beiträge: 94 Mitglied seit: 01.07.2006 Wohnort: Paderborn Mitglieds-Nr.: 42 |
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 |
|
|
Thu. 17. January 2008, 09:29
Beitrag
#11
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
ZITAT 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ß |
|
|
Thu. 17. January 2008, 19:16
Beitrag
#12
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 627 Mitglied seit: 30.06.2006 Mitglieds-Nr.: 25 |
Irgendwie vermisse ich verschieben, kopieren, umbenennen usw.
Gruss -------------------- feniweb
_____________________________________________________________________________ Wer kämpft, kann verlieren. Wer nicht kämpft, hat schon verloren. (Bertolt Brecht) |
|
|
Vereinfachte Darstellung | Aktuelles Datum: 27.9.24 - 02:40 |