Textfilter-API, API zum Einbinden verschiednener Textfilter |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
Textfilter-API, API zum Einbinden verschiednener Textfilter |
Thu. 17. August 2006, 23:47
Beitrag
#1
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
Hallo
Während der Diskussion um den bbCode kam die Idee zu einer Textfilter-API auf. Gemeint ist eine Schnittstelle, über die ein Plugin einen Textfilter wie z.B. bbCode, Textile, WikiCode oder MarkDown installieren kann, der dann nach bedarf auf eine Textarea angewendet werden kann. Eine solche API müsste aber beide Seiten unterstützen: Die Einbindung eines Filters, der die Markup-Markierungen im Text durch HTML-Tags ersetzt und das erstellen einer Toolbar und eines Formularsystems, dass den Redakteur beim Formatieren des Textes unterstützt. Ich finde das ist ein Sinnvoller FR für die Zukunft. Gruß, Peter |
|
|
Fri. 18. August 2006, 07:03
Beitrag
#2
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 1.126 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 7 |
Moin, ich steh gerade auf der Leitung oder der Kaffee ist nix.
Kannst Du mal ein Beispiel bringen, ich kann es mir im Moment nicht vorstellen. -------------------- ------
Ich gehe spazieren durch Gelsenkirchen |
|
|
Fri. 18. August 2006, 08:24
Beitrag
#3
|
|
Advanced Member Gruppe: Moderators Beiträge: 911 Mitglied seit: 26.06.2006 Wohnort: Essen; Ruhrgebiet Mitglieds-Nr.: 4 |
JAAAAAAAAAAAAA! Super Idee!
Damit könnte man dann auch so nützliche Markup"formatierungen" einfügen wie Überschrift erster Ordnung etc. -------------------- |
|
|
Fri. 18. August 2006, 14:49
Beitrag
#4
|
|
Advanced Member Gruppe: Members Beiträge: 54 Mitglied seit: 26.06.2006 Wohnort: Karlsruhe Mitglieds-Nr.: 3 |
Moin, ich steh gerade auf der Leitung oder der Kaffee ist nix. Kannst Du mal ein Beispiel bringen, ich kann es mir im Moment nicht vorstellen. Man kann es als Abstraktion der bbCode-Integration verstehen. Sefrengo müßte dafür eine allgemein gefaßte Schnittstelle für eine solche Integration anbieten. Sefrengo selbst würde dann z.B. zwei Plugins anbieten, eines, dass Text in einer textarea einfach mit QUELLTEXT $html = nl2br(htmlentities($textarea, ENT_COMPAT, 'UTF-8')); in HTML umwandelt und als Eingabe-Element einfach nur eine textarea ohne Toolbar oder ähnliches anbietet.Ein zweites Plugin wäre z.B. der fck Editor. Der liefert ja gleich HTML braucht aber keine einfache textarea als Eingabe, sondern den fck-Editor mit all seinen schönen Toolbars. bbCode wäre dann einfach ein neues Plugin, dass beides hätte: Eine Umsetzung von Text zu HTML und ein mit einer Toolbar aufgemöbeltes textarea. Textile, MarkDown etc. wären dann natürlich einfach nur weitere Plugins... Was eine solche Textfilter-API aus meiner Sicht können sollte:
CODE class SF_GUI_Textfilter extends SF_API_Object { var $_API_object_version = '$Revision$'; function filter($text, $parameters) { return nl2br(htmlentities($text, ENT_COMPAT, 'UTF-8')); } function generateTextarea($name, $text, $parameters) { return "<textarea name=\"$name\">". htmlentities($text, ENT_COMPAT, 'UTF-8'). "</textarea>"; } } Diese Klasse würden andere Plugins überschreiben, um ihre eigene Funktionalität zu implementieren. Ich red hier die ganze Zeit von Plugins, mein dabei aber nicht die jetzt schon vorhandenen Sefrengo-Plugins (Zu denen ich übrigens Starthilfe gebrauchen könnte), sondern eine Softwarekomponente, die diese Textfilter-API nutzen würde. -------------------- Technikwürze - Design & Webstandards Podcast |
|
|
Sat. 19. August 2006, 15:09
Beitrag
#5
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
Hi
Ja so ähnlich hab ich mir das auch vorgestellt... nur leider habe ich von OO (noch) nicht genug Ahnung um durch die Sefrengo Klassenstruktur zu steigen. Ich schätze mal eine solche Schnittstelle zu integrieren ist eine Aufgabe die ich noch nich hinbekomme. Wenn jemand in der Lage wäre sie zu implementieren würde die Komponenten dafür schreiben (FCK, Tiny, bbCode, Markdown, Textile und was halt so anliegt). Gruß, Peter |
|
|
Sun. 20. August 2006, 01:05
Beitrag
#6
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
Nochwas was ein jeder Textfilter können sollte: Strippen. Ein Anwendungsbeispiel ist das von mir geplante Newsletter-Plugin in dem der eingegeben Text einmal geparst (HTML-Teil) und einmal gestrippt (HTML-Teil) verwendet werden soll. Einie Plugins müssen garnicht strippen können -- Wikicode z.B. aber HTML und bbCode sollte es können.
Gruß, Peter |
|
|
Sun. 20. August 2006, 01:05
Beitrag
#7
|
|
Advanced Member Gruppe: Members Beiträge: 54 Mitglied seit: 26.06.2006 Wohnort: Karlsruhe Mitglieds-Nr.: 3 |
Hi Ja so ähnlich hab ich mir das auch vorgestellt... nur leider habe ich von OO (noch) nicht genug Ahnung um durch die Sefrengo Klassenstruktur zu steigen. Ich schätze mal eine solche Schnittstelle zu integrieren ist eine Aufgabe die ich noch nich hinbekomme. Wenn jemand in der Lage wäre sie zu implementieren würde die Komponenten dafür schreiben (FCK, Tiny, bbCode, Markdown, Textile und was halt so anliegt). Gruß, Peter Ich habe zwar mitlerweile Ahnung von der Sefrengo-API, weiß aber dafür sehr wenig, wo ich denn eine solche Textfilter-API ins System verankern müßte. Anyway, ich bin erstmal auf Urlaubsodyssee - in einem Monat schau ich mir mal an, ob ich die richtigen Stellen finde . -------------------- Technikwürze - Design & Webstandards Podcast |
|
|
Sun. 20. August 2006, 01:08
Beitrag
#8
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
Hi
Wenn dann sollte es in der Funktion type_form_textarea in der fnc.type_forms.php (Formularausgabe) und der type_output_textarea in der fnc.type.php (Inhaltsausgabe) im backend/inc-Verzeichnis implementiert werden. Gruß, Peter |
|
|
Sun. 20. August 2006, 08:04
Beitrag
#9
|
|
Advanced Member Gruppe: Moderators Beiträge: 911 Mitglied seit: 26.06.2006 Wohnort: Essen; Ruhrgebiet Mitglieds-Nr.: 4 |
Urlaubsodyssee Der ist gut (wenn man weiß wo es hin geht! ) -------------------- |
|
|
Mon. 21. August 2006, 12:46
Beitrag
#10
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 613 Mitglied seit: 30.06.2006 Mitglieds-Nr.: 30 |
Ich schreib mal meine Vorstellung von der Bedienung dieser API auf. Ob es möglich ist das schon in die jetzigen Arbeiten am BB-Code aufzunehmen müsst ihr sehen.
Eingestellt wird das Ganze in den Projekteinstellungen. Einstellungen für Textarea im Backend 1. alle Textareas verwenden BB-Code/Textile/Markdown, 0=kein, 1=BB-Code, 2=Textile, 3=Markdown usw. 2. BBcode/Textile/Markdown-Konfig, ebend die Features einzeln auszuwählen Einstellungen für Textarea im Frontend wie oben Ist bei Backend irgendwas aktiviert, werden alle Textareas in jedem Modul damit ausgestattet. Betrifft dann ContentFlex, Newssystem usw. ebend alles. In den Modulen gibt es einen Schalter, globale Konfig verwenden oder hier konfigurieren. Wenn zweiters ladt es die Konfig. nach und man kann einzeln Freigeben und Features auswählen usw. DiTo im Frontend, betrifft dann z.B. das Gästebuch. Tja, meine Vorstellungen halt -------------------- |
|
|
Mon. 21. August 2006, 13:09
Beitrag
#11
|
|
Advanced Member Gruppe: Moderators Beiträge: 911 Mitglied seit: 26.06.2006 Wohnort: Essen; Ruhrgebiet Mitglieds-Nr.: 4 |
Ich finde deine Vorstellungen sensationell
-------------------- |
|
|
Mon. 21. August 2006, 16:14
Beitrag
#12
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
Okay ich hab wie gesagt nich so viel Ahnung vom API daher hier mal ein paar allgemeine (Stil-)Fragen an die Core-Entwickler:
Der Textfilter wäre ein eigenes Package mit dem Namen TEXTFILTER. Also lege ich eine "class.SF_TEXTFILTER_Filter.php" unter "/API/TEXTFILTER" an. Dann darin eine Klasse "SF_TEXTFILTER_Filter extends SF_API_Object" mit den Standardmethoden wie sie Daniel umrissen hat. Dann lege ich eine Klasse "SF_TEXTFILTER_Filter_BbCode extends SF_TEXTFILTER_Filter" in einer entsprechend benannten Datei im selben Verzeichnis an und überschreibe darin die vorher definierten Methoden. Jetzt muss ich die Klasse in der fnc.type.php und der fnc.type_forms.php verankern. Wie kann ich denn eine Instanz von einer der Klassen erstellen? Über die SF-Object-Factory? oder Manuell? Wie sollten Helferklassen heißen die zum bbCode dazugehören? Wie kann ich über das API auf die Seiten-/Ordnernamen und Dateinamen zugreifen? Laut PEAR-Coding-Standards sind Klassenvariablen nicht direkt zu verwenden sondern durch Methoden zu kapseln. Muss ich also statt $c -> xhtml = true; auf $c -> setXhtml(true); umsatteln? Wenn ich diese fragen beantwortet habe könnte ich vllt. auch einen wiki-artikel zum erweitern des API ansetzen. Danke & Gruß, Peter |
|
|
Sat. 26. August 2006, 13:30
Beitrag
#13
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
OK, ist bei mir angekommen und wird gerade gedanklich verarbeitet. Antwort kommt, braucht aber ein wenig Zeit. Ich muß mir erst klar werden, wie das alles mit meiner Roadmap/ Planung umsetzbar ist.
-------------------- Es wird, es wird...
|
|
|
Thu. 31. August 2006, 01:15
Beitrag
#14
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
Dann werde ich mal versuchen, das alles auseinanderzutüddeln. Da alles irgendwie zusammgehört, hab ich hier auch meine Gedanken zum Thema bbcode niedergeschrieben.
Thema TextfliterAPI Zuerst sei die Bemerkung gestattet, das es sich um eine Transformation und um keinen Filter handelt. Wir tranformieren ja von einer Ausgabe (bbcode) in eine andere (HTML, Text). Filter "reinigen" nur eine Ausgangsbasis von nicht gewünschten Elementen, das ist ka hier nicht der Fall. Die "Texttransform" Klasssen sollten nur eins machen und zwar von Format A nach Format B transformieren. Das ganze sollte soweit unabhängig sein, das der Code wiederverwendbar ist. Das kann dann so aussehen, das auch das Suchmodul die Klasse benutzen kann, um Beschreibungstexte zu einem Suchergebnis vernünftig formatiert darzustellen. Weitere Denkbare ANwendungen wären das Versenden eines BBcode Textes als Textemail oder die Generierung von RSS Feeds. Das Paket, wo das reingehört, gibt es schon und heißt UTILS. Als Klassenname schlage ich jetzt einfach mal Texttranform vor. Somit gibt es folgende, neue API Klassen: class.UTILS_TexttransformBbcode.php class.UTILS_TexttransformHtml.php class.UTILS_TexttransformText.php class.UTILS_TexttransformSfLink.php (Die Klasse "TexttransformSfLink" soll die Möglichkeit geben, das auch die cmstags link und filelink in andere Formate transformiert werden können, weitere Klasssen für Radiobutton, Selectbox, Date sind ebenfalls denkbar). Sinn dieser Klassen ist nun das beliebiger Content in einen anderen transformiert werden kanns. Jede Klasse sollte zumindest die Transformation in Text und HTML bieten. Beispiel: $bbcode =& sf_factoryGetObject('UTILS', 'TexttransformBbcode'); $html_out = $bbcode->getAsHtml($bbcode_input); $text_out = $bbcode->getAsText($bbcode_input); Bei Transformatoren kann es Sinn machen, a: mit set Methoden Konfigurationsoptionen zu übergeben b: neben den Output HTML und Text noch andere Transformationen zuzulassen $html =& sf_factoryGetObject('UTILS', 'TexttransformHtml'); $html->setRenderer('Xhtml'); $bbcode_out = $html->getAsBbcode($html_in); Also kurz: Ziel der Texttranform API ist, den Programmierer eine möglichst einfach zu bedienende Schnitstelle zu geben, womit man jeden cmstag Content in einen anderen transformieren kann. Was fangen wir jetzt damit an? Wir haben nun die Möglichkeit, jeden COntenttyp in einen anderen umwandeln zu können. Im Falles des BBcodes ist damit der PHP Unterbau da, den wir in der fnc.type.php benötigen. Auch Suchmodul, Content zu Textmail, Gästebuch mit bbcode etc. können davon partizipieren. Thema: Textareas können beliebige Tranformationen zugewiesen werden Idee war (auch im bbcode Thread), das z.B. dem cms:tag Textarea durch die Tagconfig eine beliebige Formatierung zugewwiesen werden kann. Dem muß ich eine klare Absage geben, den ich halte es für einen fatalen Fehler. Diese Funktionalität wird es nicht geben. Begründung: Die Texttransformationen werden im cms:tag dynamisch zugewiesen. Damit kann rein theoretisch jeder Content anders formatiert sein. Stehen die Inhalte für sich alleine, ist das kein Problem, aber sobald Module wie der Categorywalker über den Content gehen, weiß dieser nicht mehr, wie die Inhalte zu formatieren sind, den darüber sind im System keine Informationen gespeichert. Jedes Modul, welches dann auf den Content zugreift, kann höchstens raten, wie dieser darzustellen ist. Im einem C>MANAGEMENT<S kann das nicht unser Ziel sein. Meine Alternative: Für jeden neuen Contenttype gibt es ein eigenens cms:tag. Das wird ja erst einmal nur der bbcode Editor sein (Aus Gründen der Abwärtskompatibilität wird die Textarea dieses Feature auch erst einmal erhalten, allerdings in Vorhinein gleich als Deprecated gekennzeichnet. Die Textarea mit bbcode auszustatten war ein riesen Fehler und hat im DeDi Forum ja auch für einigen Trouble gesorgt, als den Leuten auf einmal Suchmodul und Categorywalker um die Ohren geflogen sind). Damit hat der bbcode eine feste Definition und jeder Modulprogrammierer weiß, das es sich um bbcode und nicht um xyz handelt. Wir haben durch die schicken neuen Texttransformationsklassen nun die Möglichkeit, jeden Content in einen anderen umwandeln zu können. Nun möchte ich aus meinem Inhalt, den ich bis jetzt als HTML im WYSIWYG eingegeben habe, als bbcode weiterpflegen. Also brauche ich eine Funktionalität, welche mir den Inhalt vom cms:tag wysiwyg in den cms:tag bbcode überführt. Das kann so aussehen, das ich einen Konfigurationsbidschirm habe, wo ich die gesamten Inhalte einer Seite sehe und dort Typ, Id, Container, Seite (nicht vergessen: Wir unterhalten uns hier in erster Linie um den Typ ) neu zuweisen kann, bzw. den Content dorhin konvertieren kann. Damit ist genau das Ziel erreicht, welches auch von euch verfolgt wird: Jeder Inhalt kann beliebig formatiert werden. Bei genaueren Hinsehen ist diese Methode auch weitaus mächtiger und man tritt sich einige Nägl nicht ein, die mit der "eine Textarea für alles" Methode ganz schön schmerzen würden. - Mit der Textareamethode dürfte man alle Inhalte manuell nachziehen, sobald man einen anderen Transormator verwenden würde. Mit dem zusätzlichen Configbereich passiert das nicht, den alles ist wohl definiert. - Mit der Textareamethode crashen alle davon abhängigen Module oder müssen jedes mal nachgezogen werden, bei dem zusätlichen Configbereich nicht - Der neue Configbereich gibt weitreichene Möglichkeiten für das "Geradeziehen" von Fehlkonfigurationen. Thema JS bbcode Wichtig hierbei ist erst einmal, das wir ein in sich gekapseltes JS Framework habe. Im Idealfall ist das das Basisframework, welche eine Konfiguration ermöglicht, die man sich recht flexibel anpassen kann. Was da dann PHPseitig mit gemacht werden kann, ist erst einml nebensächlich. Siehe FCK Editor. Einfach Klasse initialisieren, betroffene Textarea angeben, Configs reinschieben, rennen lassen. Ich möchte die bbcode JS Editorklasse so haben, das man sich die Toolbar recht frei zusammenstellen kann. Das sollte soweit gehen, das man für einfach- ([hr]) und zweifach- (...) Ersetungen auch eigene Tags defineiren kann (<hr /> <b>....</b>), damit der Editor nicht nur mit bbcode läuft, sondern auch z.B. als Ersatz für den Sourcecodeeditor laufen kann, wenn vielleicht auch nicht mit allen Features (der Sourcecodeeditor gehört einfach ersetzt, der war einmal...). Bei speziellen Dialogen wie Dateiauswahl, sollte zum einen der Ressourcebrowser zum Einsatz kommen, zum anderen sollte auch hier die endgültige Formatierung der AUsgabe nach Möglichkeit beinflussbar sein. Das könnte dann soweit gehehn, das man auch unter Design->Layouts mit dem JS Framework Bilder auswählen kann, die man ins layout packt. Sowas könnte man dann später auch um weitere Dialoge erweitern, wie einem CMS:LAY Tag Wizard. -------------------- Es wird, es wird...
|
|
|
Thu. 31. August 2006, 07:52
Beitrag
#15
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 853 Mitglied seit: 16.06.2006 Wohnort: Wien / Österreich Mitglieds-Nr.: 2 |
ZITAT Also brauche ich eine Funktionalität, welche mir den Inhalt vom cms:tag wysiwyg in den cms:tag bbcode überführt. und die muss auch vollständig automatisiert sein, um z.b. websites die mehrere hundert seiten haben in einem rutsch zu konvertieren. ein manuelles umstellen jeder einzelnen seite ist da nicht drinnen. -------------------- SEFRENGO | a free choice ... again!
|
|
|
Thu. 31. August 2006, 11:28
Beitrag
#16
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 613 Mitglied seit: 30.06.2006 Mitglieds-Nr.: 30 |
Oho, hohe Hürden die da aufgestellt werden. Wenn sich das jemand zutraut die anzugehen, das ZIEL ist vergoldet
-------------------- |
|
|
Thu. 31. August 2006, 11:48
Beitrag
#17
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
In erster Linie geht es hier um die TransformationsAPI. Die "beliebige Transformation" soll aufzeigen, wohin die Reise gehen soll, und was der Sinn und Zweck ist, es so zu machen und nicht irgendwie anders. Das dies kein zwei Wochen Projekt ist,sondern eher das lasngfriestige Ziel, sollte jeden klar sein. In der ersten Phase soll der bbcode Integriert werden.
-------------------- Es wird, es wird...
|
|
|
Thu. 31. August 2006, 16:18
Beitrag
#18
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
Hi
Also als Primäres problem stellt sich für mich folgendes da: wie soll der wysiwyg wissen, was bbcode ist? kann er nicht. also brauchen wir eine einheitliche Formatierungssprache. alle Transformatoren transformieren dann dahin. Ansonsten finde ich deine Ideen ziemlich gut. Gruß, Peter |
|
|
Thu. 31. August 2006, 20:50
Beitrag
#19
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
Ist sehr simpel. Die class.UTILS_TexttransformHtml.php Klasse hat dafür die Methode getAsBbcode. Da schiebst Du HTML rein und bekommst bbcode raus.
Natürlich kann eine solche Klasse nicht das gesamte Spektrum von HTML abdecken. Ich würde das so machen, das einfache Formatierungen, bzw. bestimmte Textauszeichnungen wie <strong>, <i>... in bbcode [b], [i],... umgewnadelt werden und ansonsten alle weiteren HTML Tags gestipt werden. Niemand kann erwarten, das die wildesten und exotischten HTML Anweisungen sich in bbcode umwandeln lassen. Da muß dann halt von Hand nachgezogen werden. Ich sehe diese Transformation aber auch als Optional an. Für die Implementierung des bbcodoes ist sie nicht notwendig. Die Methode getAsText() würde durchaus auch reichen, wenn man aus <cms:mod type="wysiwyg" ... /> <cms:mod type="bbcode" ... /> machen wollte. Ein Zwischenformat ist nicht notwendig. Mich würde jetzt interessieren, ob Du Dich auf der von mir vorgestellten Grundlage an eine Konzeption des Sefrengo bbcodes rantrauen würdest. -------------------- Es wird, es wird...
|
|
|
Thu. 31. August 2006, 21:08
Beitrag
#20
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
ZITAT Ist sehr simpel. Die class.UTILS_TexttransformHtml.php Klasse hat dafür die Methode getAsBbcode. Da schiebst Du HTML rein und bekommst bbcode raus. Hmm. und was ist mit getArWiki, getAsTextile, getAsMarkDown getAsWasWeißIch...? Ich mag dieses einseitige Konzept nicht... Wenn du gegen eine zwischensprache wäre (was ich nachvollziehen kann!) wäre ich eher dafür dass jede Klasse eben nur getAsHTML und getAsText unterstützt. Beim konvertierungsvorgang in einen anderen Typ wird dann getAsText verwendet, sodass dann zwar alle Formatierungen weg sind aber zumindest der Text erhalten bliebe. Der Verlust der Formatierungen ist beim Wechsel der Formatierungssprache durchaus vertretbar. Ich wäre gerne bereit diese API zu implementieren, sofern sie ein anderer für mich im System verankern kann, denn das kann ich glaub ich nich ^^. Ich weiß nur nicht wieviel Zeit ich investieren kann. Die 13. Klasse schlägt ganzschön rein.. aber ich werde mein bestes geben Gruß, Peter [edit] eine Frage noch: die HTML-Transform-Klasse würde doch bei getAsHTML nur den Input wiedergeben, bei getAsText die HTML-Tags strippen. bbCode würde bei getAsHTML Parsen, bei getAsText die bbCodes ausfiltern. Was genau würde TexttransformSfLink ausgeben?? Der Beitrag wurde von MaZderMind bearbeitet: Thu. 31. August 2006, 21:15 |
|
|
Vereinfachte Darstellung | Aktuelles Datum: 19.3.24 - 08:13 |