Textfilter-API, API zum Einbinden verschiednener Textfilter Einstellungen

[bjoern]

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 denke auch, das wir als Ausgabeformat mit Text und HTML am Besten fahren. Alle andere Formatierungen sehe ich als optional an, die implementiert werden können, wenn es erforderlich ist. Dabei sehe ich aber nicht, was an dem Konzept einseitig sein soll. Wenn Du viel Funktionalität haben willst, bedeutet das halt auch viel Aufwand. Eine andere Möglichkeit wäre natürlich alles in ein Zwischenformat umzuwandeln und von da aus wieder in alle anderen Formate. Allerdings möchte ich das Zwischenformat sehen, auf das sich komplett HTML, WIKIsyntax, BBcode, etc. abbilden lassen. Wenn Du das geschafft hast, bist Du der Held der OpenSource Bewegung, nebenbei dann aber auch 20 jahre älter...

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

Naja, verankern kann ich Dir das gerne, aber Du wirst sehen, das das gar nicht nötig ist. Einfach ins Package UTILS gehen und dann eine Klasse anlegen, die vom API Objekt erbt fertig.

Beispiel:
Ins Package UTILS wechseln und dort die Datei "class.SF_UTILS_TexttransformBbcode.php" anlegen.

Dann in der Datei die Klasse anlegen:

QUELLTEXT

class SF_UTILS_TexttransformBbcode extends SF_API_Object {
  function sagHallo() {
        return "Hallo Peter";
  }
}

Aufrufen kannst Du das dann mit

QUELLTEXT

$bb_trans =& sf_factoryGetObject('UTILS', 'TexttransformBbcode');
echo $bb_trans->sagHallo();

Immer mit der Ruhe mit dem entwickeln. kannst solltest erst mal den API Teil machen und dann an den JS Teil. Wobei Du beim JS Teil bitte vorher die Schnitstellen, die nach aussen hin sichtbar sein sollst im Wiki oder sonstwie erarbeitest, das wir diese zusammen durchgehen können. Damit vermeiden wir dann, das wir uns irgendwelche Nägel eintreten, die ja schmerzen sollen.

Sicher ist es ein projekt, was ein paar Monate dauern wird, aber wenn es dann am Ende alles funktioniert, ist die Freude um so größer...

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??

Bei Text halt ein ganz normaler Text und bei HTML ein formatierter Link. Bei den Links muss man dann natürlich optional den Linknamen und bei HTML auch das Target angeben können. Würde das dann so machen:
Text: Linkurl - [Name, wenn vorhanden]
HTML: <a href="[URL]" [target wenn vorhanden]>[Linkname wenn vorhanden ansonsten URL]</a>

[Olaf]

Was ich daran nicht verstehe ist, wieso wird eigentlich der BB-Code immer als solcher in der DB abgelegt? Aus meinem Verständnis würde es doch auch möglich sein immer HTML abzuspeichern. Dieser wird dann bei Bearbeitung transformiert, ist doch das gleiche wie jetzt, nur halt wird BB->HTML bei der Anzeige transformiert.

Sorry wenn das Blödsinn ist, einfach ignorieren und weitermachen.

[bjoern]

Naja, wenn Du Äpfel einkaufst, hast Du auch Äpfel in der Einkaufstüte.

[andre.5tz]

Naja, wenn Du Äpfel einkaufst, hast Du auch Äpfel in der Einkaufstüte.

aber wenn ich zu Hause die Tüte auspacke (im Frontend) werden doch dann Birnen (XHTML) ausgepackt (angezeigt).

Die gleiche Frage wie Olaf stelle ich mir auch schon eine Weile ... da ich aber hiervon keine Ahnung habe bin ich auch schon wieder still.

Der Beitrag wurde von andre.5tz bearbeitet: Fri. 1. September 2006, 11:33

[bjoern]

Nein, Das Frontend ist der Apfelkuchen, wo alle möglichen Elemente zusammengerührt sind und so hingebogen werden, wie sie da gebraucht werden.

[luxli]

Und das backend ist der Werkzeugkasten. Darin gibt es Messer (Texteditor) Spezialmesser (BbCode) und Elektromesser (HTML-Editor) womit der Apfel für den Kuchen geschnitten wird.

Der bearbeitete Apfel sieht danach immer gleich aus (HTML)

[MaZderMind]

Dabei sehe ich aber nicht, was an dem Konzept einseitig sein soll. Wenn Du viel Funktionalität haben willst, bedeutet das halt auch viel Aufwand.

Einseitig ist daran dass vn miraus html -> bbcode unterstützt wird aber nicht html -> wiki. D.h. wenn ich wiki-code bnutze habei ch nicht die gleichen möglichkeiten, die ich beim bbcode hätte. außerdem müsste ja dann auch wiki -> bbcode und bbcode -> wiki unterstützt werden. und wenn ein neues format hinzukommt (oder ein bestehendes erweitert wird, beispielsweise neue tags für den bbcode) müssen alle anderen Klassen mit-aktualisiert werden, und das halte ich nicht für praktisch.
Ich halte es auch irgendwie nich besonders sinnvoll aus wikicode bbcode machen zu wollen oder aus html wikicode...
Wenn jemand der bisher mit dem bbCode gearbeeitet hat und nun doch wikicode benutzen will, muss er halt akzeptieren dass seine bbcode-Auszeichnungen verlorengehen.

Naja, verankern kann ich Dir das gerne, aber Du wirst sehen, das das gar nicht nötig ist.

Naja mir gings eher darum, die Tag-Verarbeitung in Sefrengo zu erweitern, dass ein Tag ala <cms:mod type="transform-bbcode" /> oder <cms:mod type="transform" mode="bbcode" /> erkannt wird und die entsprechenden Klassen anspricht.

Wobei Du beim JS Teil bitte vorher die Schnitstellen, die nach aussen hin sichtbar sein sollst im Wiki oder sonstwie erarbeitest, das wir diese zusammen durchgehen können.

Hmm auch da weiß ich nicht wie eit ich das hinbekomme -- meine Kenntnisse über OOp in JS sind minimal..

Was ich daran nicht verstehe ist, wieso wird eigentlich der BB-Code immer als solcher in der DB abgelegt?

Naja stell dir mal vor, dui benutzt einen Tag ala . Daraus wird dank alwaysalt <img src="cms://idfile=1" alt="" />. Nach dem zurücktransformieren stünde also da [img=""]cms://idfile=1[/img], weil ja nicht erkannt werden kann ob tatsächlich explizit kein Titel angegeben wurde oder nicht. Ebenso kann nicht erkannt werden, ob die URL jetz feste so eingegeben wurde oder nicht.
Viel lustiger wirds bei den links -- es gibt dutzende Möglichkeiten, ein und den selben HTML-Link zu erzeugen. Eine eindeutige Rückführung in den Quellcode ist nicht möglich. Das ist als wollstest du durch disassemblieren aus einem Binary wieder Quellcode machen.

Gruß, Peter

[Olaf]

Viel lustiger wirds bei den links -- es gibt dutzende Möglichkeiten, ein und den selben HTML-Link zu erzeugen. Eine eindeutige Rückführung in den Quellcode ist nicht möglich. Das ist als wollstest du durch disassemblieren aus einem Binary wieder Quellcode machen.

Ich versteh das schon, es ist schwierig aus HTML BB-Code zu machen, richtig!? Frage mich aber immer noch ob dies so genau in den Einzeilheiten zurückgewandelt werden müsste. Was wäre so schlimm wenn aus
<img src="../image.jpg" />
immer
[img=""]../image.jpg[/img] würde. Wozu soll es unbedingt in sowas "cms://idfile=1" gewandelt werden!?

Und das [img=""]../image.jpg[/img] wird dann beim neu speichern wieder je nach Einstellung "alwaysalt" neu behandelt.

Gut, ihr denkt euch was bei, ich geb jetzt Ruhe. Schön zu lesen mit die Äppel und Birnen

[bjoern]

Einseitig ist daran dass vn miraus html -> bbcode unterstützt wird aber nicht html -> wiki. D.h. wenn ich wiki-code bnutze habei ch nicht die gleichen möglichkeiten, die ich beim bbcode hätte. außerdem müsste ja dann auch wiki -> bbcode und bbcode -> wiki unterstützt werden. und wenn ein neues format hinzukommt (oder ein bestehendes erweitert wird, beispielsweise neue tags für den bbcode) müssen alle anderen Klassen mit-aktualisiert werden, und das halte ich nicht für praktisch.
Ich halte es auch irgendwie nich besonders sinnvoll aus wikicode bbcode machen zu wollen oder aus html wikicode...
Wenn jemand der bisher mit dem bbCode gearbeeitet hat und nun doch wikicode benutzen will, muss er halt akzeptieren dass seine bbcode-Auszeichnungen verlorengehen.

Ich will das jetzt nicht totdiskutieren, das brignst nicht. Text und HTML ist fein.

Naja mir gings eher darum, die Tag-Verarbeitung in Sefrengo zu erweitern

Aso, denke das können Mistral oder ich machen. Ein neuer cms:tag wäre einfach <cms:mod type="bbcode" id="[1,2,3,...,n]" ... />. Was Du da dann reinhaben willst ist erst einmal Deine Definitionssache.

QUELLTEXT

Hmm auch da weiß ich nicht wie eit ich das hinbekomme -- meine Kenntnisse über OOp in JS sind minimal..

Momentan vermutlich besser als meine... In JS gibts aber auch nur eine minimale Objektorientierung. Ich denke das Geheimnis ist da einfach die Funktionen als prototype auf eine Ausgangsvariable zu beziehen. Das wars dann schon.

[MaZderMind]

Wozu soll es unbedingt in sowas "cms://idfile=1" gewandelt werden!?

Damit der Pfad auch mit angepasst wird, wenn die Datei mal verschoben oder umbenannt wird.

@björn: sry.. eine meienr schlechteren Eigenschaften ist, dass ich auf meiner Meinung sehr fest beharre. Ich könnte mir jedoch folgenden Kompromiss vorstellen:
Während des Konvertierungsvorganges wird erst -> isConvertable('wiki') aufgerufen. Wenn dabei true zurückkomt, wird anschließend -> get('wiki') gerufen und das Ergebnis als Wikicocode behandelt, sonst wird nur -> getText angenommen. Allerdings würde es meiner meinung nach volkommen langen, getHtml und getText zu implementieren.
Ich wüsste auch absolut nicht wie ich "vermurkste" HTML-Tags nach bbcode oder bbcode nach wiki wandeln sollte...

Gruß, Peter

[braendle]

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);

Hm, ich habe diesen Thread leider erst heute lesen können. Sorry, wenn ich also so spät mit meinen 2 Cent komme ...

Die Idee ist super, der Ansatz zur Umsetzung gefällt mir nicht. Warum? Ganz einfach, jedes neue Format oder jede spezielle Umwandlung wird in den Klassen als Methode der Form getAsFormatname(input) aufgebaut.
Wenn also was neues hinzukommt muss dieses explizit bekannt sein und auch so aufgerufen werden. Das ist schlecht für die Flexibilität und die Skalierbarkeit der Anwendung.
Besser wäre es schlicht und ergreifend erstmal eine Schnittstelle bereitzustellen, die überall benutzt werden kann und die flexibel genug ist, auch einige zukünftige Entwicklungen auszuhalten.
Diese Schnittstelle würde ich in die Klasse

class.UTILS_Transform.php

packen.

Als Eigenschaften der Schnittstelle wären folgende denkbar:

Inputformat
Outputformat
IgnorableElements
IgnorableIsRegXP
NotSupported

- Inputformat können sein:
HTML,XHTML,BBCODE,WIKI,PDF,RTF,DOC,TXT,ASCII,UTF8, ...

- Outputformat können sein:
HTML,XHTML,BBCODE,WIKI,PDF,RTF,DOC,TXT,ASCII,UTF8, ...

- IgnorableElements können sein:
HTML-Tagnamen, BBCode-Elementnamen, Reguläre Ausdrücke, ...

- IgnorableIsRegXP ist standardmäßig false, muss auf true gesetzt werden, wenn die IgnorableElements sich aus einem regulärem Ausdruck zusammensetzen.

- NotSupported:
Ein Wert der nur gelesen werden kann, signalisiert, ob die gewünschte Transformation unterstützt wird oder nicht.


Als Methoden besitzt die Schnittstelle erstmal nur eine Transformationsmethode mit verschiedenen Parametersätzen
Transform( input )
Transform( input, inputformat )
Transform( input, inputformat, outputformat )
Transform( input, inputformat, outputformat, ignoreelements )
Transform( input, inputformat, outputformat, ignoreelements, isignorearegxp )

und natürlich die Methoden zum Setzen der Eigenschaften.

So das, ist die Schnittstelle, die überall gleich aussieht und beliebige Formate erlaubt.

Wie funktioniert die Schnittstelle?
Ganz einfach, anhand des Eingangsformats wird die entsprechende Klasse mit Transformationsmethoden ausgerufen, die einen entsprechenden Ausgangstext zurückliefert. Unterstützt die Klasse einen bestimmte Transformation nicht, liefert sie immer den Eingangstext ohne Formatierungen zurück.
Ein Beispiel:
Die Umwandlung HTML->BBCode wird in der Klasse TransformHTML unterstützt, sie liefert also den HTML-Eingang als BBCode-Text zurück. Die Umwandlung HTML->DOC wird nicht unterstützt, die Klasse liefert nur den Text ohne HTML-Tags zurück und setzt den Wert NotSupported.

Jetzt kommt natürlich der Teil, der das ganze umsetzen muss:
Die einzelnen Klassen für die Transformationen, diese Klassen werden von der Schnittstelle geladen und sind nur über diesen Weg zu verwenden. Ein direktes Ansprechen der Klassen sollte vermieden werden, damit die Implementierung jederzeit geändert werden kann.

Die Klassen orientieren sich am Eingangsformat, das heisst alle Transformationen, die HTML-Code als Eingangsformat haben werden in der Klasse

class.UTILS_TransformHTML.php

implementiert.

Die Methoden und Eigenschaften unterscheiden sich von der öffentlichen Schnittstelle erheblich:

Jedes Ausgabeformat hat seine Methode:
TransformToBBCode
TransformToHTML
TransformToXHTML
TransformToXHTMLStrict
TransformToRDF
TransformToPDF
TransformToText
TransformToDefault
IsFormatSupported

Dazu kommen jede Menge private Methoden, die von den TransformTo-Methoden verwendet werden:
StripTags
ReplaceTag
GetText

Als Eigenschaften sind möglicherweise nur sehr wenige nötig:
LastError
Input
Output

Je nach Art der Implementierung ... liefert die TransformToXXX gleich das Ergebnis zurück, oder es über wird die Eigenschaft Output gesetzt und die Schnittstelle holt dieses Ergebnis ab.
Die Implementierung kann variieren, sollte aber für alle konkreten Transform-Klassen gleich sein.

So, jetzt ihr.



Apropos "warum man BBCode nicht als HTML in der DB ablegt":
Warum soll ich Äpfel in eine Birnenhülle packen um, wenn ich die Äpfel irgendwann noch bearbeiten will? Das die Frontend-Ausgabe als Birne erfolgt ist ja sinngemäß nur eine Einweg-Transformation zur Anzeige beim Endnutzer, in der DB muss aber der Apfel erhalten bleiben, weil der Bauer den ja von Zeit zu Zeit polieren will.

Ich wüsste auch absolut nicht wie ich "vermurkste" HTML-Tags nach bbcode oder bbcode nach wiki wandeln sollte...

Das gerade ist die Herausforderung :-)

[MaZderMind]

Hi
Ich würde pro Klasse nur eine Methode TransformTo($format, $input) definieren, die dann intern auf die Methoden zugreift. Daneben eine Methode Issupportet($format).
Und was du mit IgnorableElements bezweckst weiß ich auch nich so ganz.. kannst du dazu mal ein Praxisbeispiel liefern?

Gruß, Peter

Der Beitrag wurde von MaZderMind bearbeitet: Sat. 2. September 2006, 13:22

[braendle]

Und was du mit IgnorableElements bezweckst weiß ich auch nich so ganz.. kannst du dazu mal ein Praxisbeispiel liefern?

Das leitet sich aus dem Transformieren ab ... ich könnte ja zum Beispiel einen HTML-Code transformieren wollen und nur bestimmte Tags strippen wollen. Zum Beispiel könnte ich ein Modul bauen wollen, das HTML-Tags zum Formatieren erlaubt, aber den Tag <object> verbietet. In einer Transformation HTML->HTML würde ich damit die Tags angeben, die von der Transformation nicht berührt werden sollen.

Das ist Defacto zwar ein Filter, aber eigentlich ist es eben eine Umwandlung des Eingangsstrings. Man könnte diese Methoden dann statt "Transform" eben "FilterText" nennnen.

Ich würde pro Klasse nur eine Methode TransformTo($format, $input) definieren, die dann intern auf die Methoden zugreift. Daneben eine Methode Issupportet($format).

Ich habe nur eine Klasse auf die Du als Programmierer zugreifst: class.UTILS_Transform.php. Alle anderen klassen werden aus dieser Klasse heraus aufgerufen und sind "privat". Also für die Entwickler nicht direkt zu nutzen.

Und woher nimmst Du das wissen, in welchem Format der Eingangstext verfasst ist? Ich habe nur eine Klasse, die nach aussen sichtbar ist. Ich muss dieser Klasse sagen, was bekommt sie und was soll sie zurückliefern. Das was sie bekommt entscheidet, welche Transform-Klasse ich intern verwende. Das was die Klasse zurückliefern soll, entscheidet welche Methode in der Transform-Klasse intern aufgerufen wird.

Eine zusätzliche Methode in der Schnittstelle für die Abfrage der unterstützten Umwandlung ist soweit okay, muss aber auch hier eine komplette Beschreibung der Umwandlung beinhalten, d.h. Eingangs- und Ausgangsformat sind zu übergeben.

Nichtsdestortrotz wäre es schön, wenn die Klasse einfach aufgerufen werden könnte und im Falle eines unbekannten Ausgangformates eben den Text ohne jegliche Formatierung zurückliefert.

[MaZderMind]

Hi
Ich hab das Interface mal soweit implementiert wie ich mir das vorgestellt habe, nur die Doku-Texte sindn och nich fertig. Schaus dir mal an. Ein Aufruf kann z.B. so aussehen:

QUELLTEXT

<?PHP

$ttransf =& sf_factoryGetObject('UTILS', 'Texttransform');

$ttransf -> setInputFormat('bbCode');
$ttransf -> setOutputFormat('Html');
echo 'isSupported: ' . ($ttransf -> isSupported() ? 'ja' : 'nein') . '<br />';
echo 'isSupported ->text: ' . ($ttransf -> isSupported('text') ? 'ja' : 'nein') . '<br />';
echo 'isSupported ->wiki: ' . ($ttransf -> isSupported('wiki') ? 'ja' : 'nein') . '<br />';
echo 'isSupported wiki->html: ' . ($ttransf -> isSupported('html', 'wiki') ? 'ja' : 'nein') . '<br />';

?>

Hier die Interface-Definition: http://3easysteps.de/.peter/SF_UTILS_Texttransform/

Gruß, Peter

Der Beitrag wurde von MaZderMind bearbeitet: Mon. 4. September 2006, 00:46

Angehängte Datei(en)

 UTILS_Texttransform.zip ( 3.53KB ) Anzahl der Downloads: 16

 

[braendle]

Jep, so kann man es machen ... sieht ganz okay aus, jetzt kommen aber erst die wichtigen Sachen ... die Transformationen :-)

[MaZderMind]

Naja bbCode->HTML und bbCode->Text liegt ja schon 3/4 fertig hier rum.. werd mal drangehen das jetz an das Interface anzupassen. Ich poste demnächst aber erstmal die Text- und HTML-Transformer.

Gruß, Peter

[MaZderMind]

Hi
Eine Frage hab ich noch: Es wäre eigentlich sinnvoll eine Mutterklasse für die Transformer, welche die Methoden setParameter und getParameter stellt. Natürlich kann das auch jeder Transformer selbst implementieren, aber schöner wärs wenns geerbt würde.. oder was meint ihr?

Gruß, Peter

[braendle]

Hi
Eine Frage hab ich noch: Es wäre eigentlich sinnvoll eine Mutterklasse für die Transformer, welche die Methoden setParameter und getParameter stellt. Natürlich kann das auch jeder Transformer selbst implementieren, aber schöner wärs wenns geerbt würde.. oder was meint ihr?

Gruß, Peter

jo, schöner wär's schon. dann kannste bei deinem ansatz aber auch gleich fast alle methoden in einer mutterklasse bereitstellen und in den konkreten klassen die entsprechenden implementierungen machen, die nicht allgemein sind.

[bjoern]

Die Idee ist super, der Ansatz zur Umsetzung gefällt mir nicht. Warum? Ganz einfach, jedes neue Format oder jede spezielle Umwandlung wird in den Klassen als Methode der Form getAsFormatname(input) aufgebaut. Wenn also was neues hinzukommt muss dieses explizit bekannt sein und auch so aufgerufen werden. Das ist schlecht für die Flexibilität und die Skalierbarkeit der Anwendung.

Besser wäre es schlicht und ergreifend erstmal eine Schnittstelle bereitzustellen, die überall benutzt werden kann und die flexibel genug ist, auch einige zukünftige Entwicklungen auszuhalten.
Diese Schnittstelle würde ich in die Klasse class.UTILS_Transform.php packen.

Die Idee einer Mutterklasse hat ich auch, habe ich aber fallengelassen, weil ich das für das jetztige Projekt als Overfeatured angesehen habe. Bei genauerer Betrachtung sind Die TransformTo Klassen das Gleiche, wie meine getAs Klassen. Darüber wird eine Mutterklasse gebaut, mit der man alles ansprechen kann. Wichtig ist mir, das die Methoden in den einzelnen TransformTo Klassen einzeln definiert sind, damit eine Nachvollziehbarkeit da ist (also kein set('xysonstwas'), sondern setA(), setB() ).

QUELLTEXT

Ich habe nur eine Klasse auf die Du als  Programmierer zugreifst: class.UTILS_Transform.php. Alle anderen  klassen werden aus dieser Klasse heraus aufgerufen und sind "privat".  Also für die Entwickler nicht direkt zu nutzen.

Prinzipiell ist das richtig. Ich würde meinen Schwerpunkt aber erst auf die TransforTo- Klassen legen. Erst wenn diese in ausreichender Zahl vorhanden sind, steht ja erst überhaupt fest, welche Methoden in der Mutterklasse gebraucht werden. Versteht mich nicht falsch, gegen eine einfache Implementierung der Transform Klasse habe ich nichts, aber passt auf, das Ihr am Haus nicht zuerst das Dach baut.

Die TransformTo Klassen sind nicht als Privat sondern als Public zu implementieren. Es muß möglich sein, mit Ihnen auch ohne der Mutterklasse zu arbeiten. Spätestens, wenn einer so wahnsinnig ( ) ist, und sich an eine Implementierung einer PDF Transformation macht, kann die Mutterklasse nur noch eine Teilmenge von dem abbilden, was die TransformTo Klassen bieten, würde sonst in set Methoden absaufen.

QUELLTEXT

Nichtsdestortrotz wäre es  schön, wenn die Klasse einfach aufgerufen werden könnte und im Falle  eines unbekannten Ausgangformates eben den Text ohne jegliche  Formatierung zurückliefert.

Was soll das bringen?

QUELLTEXT

Es wäre eigentlich  sinnvoll eine Mutterklasse für die Transformer, welche die Methoden  setParameter und getParameter stellt. Natürlich kann das auch jeder  Transformer selbst implementieren, aber schöner wärs wenns geerbt  würde.. oder was meint ihr?

Kommt darauf an, wie komplex es ist. Ich habe mir angewöhnt, es erst einmal wegzulassen und dann gegebenenfalls nachzuziehen, wenn ich merke, das es wirklich nötig ist. Lieber erst mal im kleinen anfangen, für genau den Zweck den man benötigt, als alles super riesig aufzubalsen und dann am Ende nicht fertig zu werden oder/ und nen Haufen Schrott zu haben. Gerade dadurch, das Du in Klassen alles genau definieren muß, kannst Du da schnell in einer Sackgasse landen, wenn zu viel gewollt ist.

Daher: Behalte bitte im Auge, was Du JETZT benötigst und mach erst einmal das. Natürlich sollte man als guter Programmierer immer ein Auge darauf haben, was später damit auch möglich sein soll.

QUELLTEXT

$ttransf -> isSupported('text')

Als Eingabe- oder Ausgabeformat?

[MaZderMind]

Hi
Wie gesagt ich finde die jetzige Implementierung eig. ganz gut weil sie universell ist. Um ein neues Ausgangsformat hinzuzufügen muss ich nur die Klasse in den richtigen Ordner kopieren. Wenn ich die Klasse updatre und ein neues Zielformat hinzufüge, kann das direkt benutzt werden, ohne dass ich irgendwo noch einen neuen Funktionsnamen eingeben müsste. Denkbar wäre z.B. auch, dass beim Konvertieren von Inhalten eine Liste angezeigt wird, in welche Formate transformiert werden kann. Das geht nicht wenn die funktionen feste Namen haben.

Ich sehe auch nicht wo das Problem mit z.B. einer PDF-Ausgabe sein soll:

QUELLTEXT

$ttransf -> setInputFormat('html');
$ttransf -> setOutputFormat('pdf');
$ttransf -> setParameter('quality', 'high');
$ttransf -> setParameter('papersize', 'A4');
$s = $ttransf -> transform($i);

Allerdings solltest du im Auge behalten dass es sich hierbei um ein Framework zur TextTransformation handelt...

Als Eingabe- oder Ausgabeformat?

isSupported (line 158)

Returns if the requested transformation is supportet

* access: public
* see: SF_UTILS_Texttransform::setInputFormat()
* see: SF_UTILS_Texttransform::setOutputFormat()

void isSupported ([string $outputformat = null], [string $inputformat = null])

* string $outputformat: Outputformat from which a transformation is requested. If not set the default outputformat (which could be set via setOutputFormat) is assumed.
* string $inputformat: Inputformat into which the transformation is requested. If not set the default inputformat (which could be set via setInputFormat) is assumed.

Sprich wenn setInputFormat und setOutputFormat genutzt wird, kann isSupportesd auch ohne Parameter benutzt werden. Wird es mit einem Parameter aufgerufen, wird getestet ob das gewünschte ausgabeformat auf dem gesetzen Eingabeformat verfügbar ist. Das ist praktiosch wenn ich z.B. bbCode in mehrere Formate transformieren will:

QUELLTEXT

$ttransf -> setInputFormat('bbcode');
if($ttransf -> isSupported('html')) echo $ttransf -> transform($i, 'html');
if($ttransf -> isSupported('text')) echo $ttransf -> transform($i, 'text');
if($ttransf -> isSupported('xml')) echo $ttransf -> transform($i, 'xml');
if($ttransf -> isSupported('wiki')) echo $ttransf -> transform($i, 'wiki');
// .  .  .

Oder man benutzt sie mit zwei Parametern, dann kann man ein beliebiges Ausgabeformat auf einem beliebigen Eingabeformat prüfen: isSupported('html', 'bbcode') testet ob bbcode zu html transformiert werden kann.

Gruß, Peter

Der Beitrag wurde von MaZderMind bearbeitet: Mon. 4. September 2006, 22:25