Hilfe - Suche - Mitglieder - Kalender
Vollansicht: Textfilter-API
Forum Sefrengo.org > Allgemeine Foren > Feature Request
Seiten: 1, 2
MaZderMind
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
gunwalt
Moin, ich steh gerade auf der Leitung oder der Kaffee ist nix. unsure.gif mellow.gif

Kannst Du mal ein Beispiel bringen, ich kann es mir im Moment nicht vorstellen.
saschapi
JAAAAAAAAAAAAA! Super Idee!
Damit könnte man dann auch so nützliche Markup"formatierungen" einfügen wie Überschrift erster Ordnung etc. wink.gif
Daniel
ZITAT(gunwalt @ Fri. 18. August 2006, 08:03) *
Moin, ich steh gerade auf der Leitung oder der Kaffee ist nix. unsure.gif mellow.gif

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:
  • <cms:mod type="textarea"/> hätte zwei neue Attribute, "filter" und "filterparameters". Wobei "filter" auswählen würde, welches Plugin benutzt wird ("standard", "bbcode", "fck", "tiny", "textile", "markdown", etc.) und "filterparameters" ein String wäre, der das gewählte Plugin konfiguriert.
  • Immer, wenn diese Textarea gerendert werden soll, wird das entsprechende Plugin als Filter aufgerufen, um seine Textformatierungen auszuführen.
  • Wenn der Inhalt der Textarea editiert werden soll, wird das Plugin auch konsultiert, um eventuell Toolbars etc. mit auszugeben.
Also z.B. könnte die base-Klasse so aussehen:
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.
MaZderMind
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
MaZderMind
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
Daniel
ZITAT(MaZderMind @ Sat. 19. August 2006, 16:09) *
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 unsure.gif .
MaZderMind
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
saschapi
ZITAT(Daniel @ Sun. 20. August 2006, 02:05) *
Urlaubsodyssee


Der ist gut smile.gif (wenn man weiß wo es hin geht! wink.gif )
Olaf
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 rolleyes.gif
saschapi
Ich finde deine Vorstellungen sensationell wink.gif
MaZderMind
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
bjoern
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.
bjoern
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 smile.gif ) 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.
alexander
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.
Olaf
Oho, hohe Hürden die da aufgestellt werden. Wenn sich das jemand zutraut die anzugehen, das ZIEL ist vergoldet wink.gif
bjoern
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.
MaZderMind
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
bjoern
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.
MaZderMind
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 wink.gif

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??
bjoern
ZITAT
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... smile.gif

ZITAT
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... smile.gif

ZITAT
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
ZITAT(bjoern @ Fri. 1. September 2006, 12:03) *
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.
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) smile.gif
MaZderMind
ZITAT(bjoern @ Fri. 1. September 2006, 01:00) *
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.


ZITAT(bjoern @ Fri. 1. September 2006, 01:00) *
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.

ZITAT(bjoern @ Fri. 1. September 2006, 01:00) *
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..

ZITAT(Olaf @ Fri. 1. September 2006, 01:45) *
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
ZITAT(MaZderMind @ Fri. 1. September 2006, 15:04) *
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 wink.gif
bjoern
ZITAT
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.

ZITAT
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. smile.gif Ich denke das Geheimnis ist da einfach die Funktionen als prototype auf eine Ausgangsvariable zu beziehen. Das wars dann schon.
MaZderMind
ZITAT(Olaf @ Fri. 1. September 2006, 21:21) *
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
ZITAT
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. biggrin.gif

ZITAT(MaZderMind @ Sat. 2. September 2006, 01:31) *
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
braendle
ZITAT(MaZderMind @ Sat. 2. September 2006, 14:20) *
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.


ZITAT(MaZderMind @ Sat. 2. September 2006, 14:20) *
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
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
ZITAT(MaZderMind @ Mon. 4. September 2006, 02:09) *
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
ZITAT
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 ( smile.gif ) 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...

ZITAT
Als Eingabe- oder Ausgabeformat?

ZITAT
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
bjoern
ZITAT
Ich sehe auch nicht wo das Problem mit z.B. einer PDF-Ausgabe sein soll

OK, kannst Du bei einfachen Dingen so machen. Das Ganze stösst aber an die Grenzen, wenn mehrere Parameter innerhalb eines Methodenaufrufs übergeben werden müssen. Ist für mich aber erst einmal so in Ordnung.

ZITAT
isSupported ([string $outputformat = null])

Hmm, dann hast Du ein Problem. Du kannst keine Information zum Ausgabeformat geben, ohne das Eingabeformat zu wissen. Natürlich kann man vorgeben, das setInputFormat(...) immer vorher aufgerufen werden muß, dies lässt aber Raum für Fehler. Kann vermieden werden in dem Du die isSupported Parameter tauscht: boolean isSupported ([string $inputformat = null], [string $outputformat = null]).
braendle
ZITAT
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.

Der Schwerpunkt bleibt natürlich auf den Implementierungen der verschiedenen Transform-Methoden in den entsprechenden Klassen. Es geht auch gar nicht darum, diese Implementierung zu vernachlässigen, aber hier handelt es sich ganz eindeutig um eine Probblematik, die sehr viele ähnliche Methoden-Implementierungen und auch Methoden-Aufrufe erzeugen würde. In jeder Klasse hast Du dann getAsHtml, getAsText und du unterscheidest die effektive Umwandlung anhand der Klasse, die instanziert werden muss.
Das setzt vorraus, das ich alle Klassen mir ansehe oder zumindest die Doku dazu lese.

Der Weg der Abstraktion über ein FactoryPattern - und das ist eigentlich im grossen und ganzen was ich vorschlage - ermöglicht genau die Reduktion aus das wesentliche. Ein simpler Aufruf und was unten drunter läuft interessiert nicht weiter, es funktioniert (sofern die Formate es supporten).

Die konkrete Implementierung zu privatisieren, ist eine Geschamckssache, das gebe ich zu. Aber wozu benötigst Du den direkten Zugriff auf eine Klasse, wenn ich eine simple, leicht verständlcihe Zugriffsversion habe? Keep it simple and stupid.

Dein Beispiel mit dem PDF sehe ich übrigens auch nicht ganz so. Klar kann es hier durch die Vielzahl der möglichen Parameter etwas umständlich werden. Aber das stört nur den, der viele Parameter benötigt. Vielleicht kann das ja später noch etwas umgebaut werden und durch typische Profile (eine Liste mit festen Parametern, die auf einen bestimmten Namen hören) ergänzt werden. Dann wird statt der Vielzahl von Parametern, einfach nur dieser Profilname übergeben und die PDF-Klasse weiss Bescheid.
Da schöne an der Factory ist, dass die Implementierung - weil privat - weiterentwicklet werden kann, ohne die Schnittstelle zu verändern.

Wenn ich deinen Weg gehe, dann wird diese PDF-Klasse so oder so in Set-/Get-Methoden absaufen, weil brauchen tue ich dann sowieso. Und meine Schnittstelle ändert sich mit jeder neuen Eigenschat, die gesetzt werden kann. Es entspricht zwar nicht ganz meiner Vorgehensweise, aber um sich auf's wesentliche zu konzentrieren kann man diesen angedachten Weg gehen.

Ein Vergleich mit den Objekten des APIs zeigt auch die Speicherung der Daten intern in einem Array ist nicht ganz OOP-like, nicht automatisch typsicher - aber superflexibel! So what?

Lass ihn mal machen, ich denke das wird ganz gut.
bjoern
Grund für die Public Implementieurng ist, das sich komplexer werdene Probleme nur noch unzureichend in einer Factory abhandeln lassen. Wie Du richtig festgestellt hast, handelt es sich um eine Reduktion, die per Definition reduzieren/ vereinfachen soll. Bei einem komplexen Gebilde von X Transformationsklassen ist dies bei zunehmender Größe nicht mehr möglich. Das will ich gleich im Vorhinein abdrehen.

Desweiteren bieten private Klassen auch immer die Möglichkeit, das Schnitstellen vernachlässigt werden und Funktionalität, die eigentlich in den Transform Klassen behandelt werden sollten, in die Factory wandern. Auch das möchte ich gleich im Vorhinein unterbinden.

Ansonsten bin ich sehr zufrieden mit dem hier vorliegenden Output.
MaZderMind
ZITAT(bjoern @ Tue. 5. September 2006, 00:28) *
Das Ganze stösst aber an die Grenzen, wenn mehrere Parameter innerhalb eines Methodenaufrufs übergeben werden müssen.

Naja wenn du dir die Definition ansiehst, dann siehst du dass du auch bei $ttransf -> transform ein ausgabe, ein eingabe und Parameter angeben kannst -- folgendes würde alsoauch Funktionieren:
QUELLTEXT
$ttransf -> transform('pdf', 'html', array('Quality' => 'High', 'Papersize' => 'A4'));

Was die abstraktion des Interfaces angeht muss ich Jürgen braendle zustimmen -- es ist einfach universeller.

ZITAT(braendle @ Tue. 5. September 2006, 01:15) *
Ein Vergleich mit den Objekten des APIs zeigt auch die Speicherung der Daten intern in einem Array ist nicht ganz OOP-like, nicht automatisch typsicher - aber superflexibel!

Klar dass PHP-Arrays nicht Typsicher sind, aber wie würdest du sonst die Daten sonst spreichern? Einzige alternative wären eigene Klassen die Schlüssel/Wert-Paare zu einer Ketter verknüpfen kann (eine Instanmz pro Schlüssel/Wert-Paar) -- aber das ist bei der gegeben Flexibilität durch die PHP-Arrays dch eigentlich überflüssig. Zumal ich versucht habe bei den get/set-Methoden über das strikte Typen-Casten eine gewisse Sicherheit zu rerreichen..

ZITAT(bjoern @ Tue. 5. September 2006, 02:18) *
Bei einem komplexen Gebilde von X Transformationsklassen ist dies bei zunehmender Größe nicht mehr möglich.
[...]
Desweiteren bieten private Klassen auch immer die Möglichkeit, das Schnitstellen vernachlässigt werden und Funktionalität, die eigentlich in den Transform Klassen behandelt werden sollten, in die Factory wandern.

Sorry.. das versteh ich nich biggrin.gif Warum soll es nicht weiterhin so laufen? Wo ist das Problem bei 10, 20 100 Transformern? Alle haben die selbe Schnittstelle?
Außerdem -- schau dir die Implementierung an -- die Factory hat nur Code um den richtigen Transformer zu finden und die Methodenaufrufe (isSupported, get/setParameter, transform) an den korrekten Transformer weiterzugeben. Was sollte denn da noch rein (oder besser nicht)??

Gruß, Peter
braendle
ZITAT(bjoern @ Tue. 5. September 2006, 02:18) *
Grund für die Public Implementieurng ist, das sich komplexer werdene Probleme nur noch unzureichend in einer Factory abhandeln lassen. Wie Du richtig festgestellt hast, handelt es sich um eine Reduktion, die per Definition reduzieren/ vereinfachen soll. Bei einem komplexen Gebilde von X Transformationsklassen ist dies bei zunehmender Größe nicht mehr möglich. Das will ich gleich im Vorhinein abdrehen.

Wenn Du an den Punkt kommst, kann man immer noch überlegen, ob man diese Funktionalität über eine losgelöste Klasse macht. Diese Diskussion geht immer mehr in Richtung eines Spezialfalls, der dann betrachtet werden kann, wenn er anfällt.

ZITAT(bjoern @ Tue. 5. September 2006, 02:18) *
Desweiteren bieten private Klassen auch immer die Möglichkeit, das Schnitstellen vernachlässigt werden und Funktionalität, die eigentlich in den Transform Klassen behandelt werden sollten, in die Factory wandern. Auch das möchte ich gleich im Vorhinein unterbinden.

Genau deswegen macht man die Implementierung private, dann kann ein ordentlicher Programmierer darin alles anstellen was er will, OHNE das Interface zu überfrachten oder zu ändern. Wenn ein Programmierer diesen Ansatz versteht, dann wird er sich auch diesen Ansatz zu nutze machen. Das Interface ist universell ausgelegt und austoben kann er sich im verborgenen - in den konkreten Klassen. Jeder neue kann diesen Ansatz ohne Probleme nutzen. Wenn wer die Factory aufbohrt, hat er sie nicht verstanden. Sorry, ich bin für private (und in dotnet würde hier sogar noch weiter gehen, sealed - keine ableitung, keine vererbung möglich), dann ist klar abgegrenzt was genutzt werden kann und was nicht.

ZITAT(bjoern @ Tue. 5. September 2006, 02:18) *
Ansonsten bin ich sehr zufrieden mit dem hier vorliegenden Output.

Ich auch biggrin.gif
bjoern
ZITAT
Was die abstraktion des Interfaces angeht muss ich Jürgen braendle zustimmen -- es ist einfach universeller.

Klar, aber auch immer schwammiger. Solche Funktionen haben wir in Sefrengo zu Hauf, und da blickt dann keiner mehr durch. Da hilft nur wegschmeißen und neu machen (als nächstes trifft dies den Redaktion->Seitenbereich). Da bin ich sehr vorsichtig geworden.

Aber mach mal, ich denke, in diesem Rahmen ist das OK. Sollte es dann mal irgendwann knallen werde ich die Argumente halt noch mal aufwärmen. smile.gif

ZITAT
Wenn Du an den Punkt kommst, kann man immer noch überlegen, ob man diese Funktionalität über eine losgelöste Klasse macht. Diese Diskussion geht immer mehr in Richtung eines Spezialfalls, der dann betrachtet werden kann, wenn er anfällt.

Bis jetzt bin ich immer besser damit gefahren, so weit es geht, alles in unabhängige Schichten aufzuteilen. Einen solchen Schnitt würde ich genau zwischen Factory und einzelnen Transformern sehen.

Aber gut jetzt. Macht einfach mal.
MaZderMind
ZITAT(bjoern @ Tue. 5. September 2006, 00:28) *
Hmm, dann hast Du ein Problem. Du kannst keine Information zum Ausgabeformat geben, ohne das Eingabeformat zu wissen.

Ja wie soll ich das denn auch können? Wenn es keine einheitliche Zwischensprache gibt (und wie wird es eben nicht geben), mussi ch immer beides wissen um sagen zu können ob eine Transformation möglich ist. Das ist aber kein Problem der Implementierung...

ZITAT(bjoern @ Tue. 5. September 2006, 13:43) *
Klar, aber auch immer schwammiger.

Hmm - eigentlich nicht. Gerade weil wir eine feste und unveränderliche Factory haben, an der keiner mehr basteln soll, ist doch alles mit graden Linien umrissen. Als Entwickler weiß ich genau dass ich die transform-Methode aufrufen kann und ein Ergebnis zurückbekomme -- was im Hintergrund passiert ist völlig uninteressant.
ZITAT(bjoern @ Tue. 5. September 2006, 13:43) *
Bis jetzt bin ich immer besser damit gefahren, so weit es geht, alles in unabhängige Schichten aufzuteilen. Einen solchen Schnitt würde ich genau zwischen Factory und einzelnen Transformern sehen.

Naja das ham wir doch dann??

Naja hmm ich bau jetz mal so weiter wie gehabt..
Gruß, Peter
bjoern
Naja, mach einfach mal, ich denke ist besser, als das jetzt hier totzudiskutieren. smile.gif
bjoern
ZITAT
Ja wie soll ich das denn auch können? Wenn es keine einheitliche Zwischensprache gibt (und wie wird es eben nicht geben), mussi ch immer beides wissen um sagen zu können ob eine Transformation möglich ist. Das ist aber kein Problem der Implementierung...

Zugegeben, ist eine Feinheit. Aber wenn Du die Methode mit einem Parameter anbietest, würde ich vorschlagen, als ersten Parameter das Eingabeformat in der isSupported Methode zu übergeben. Dies kannst Du immer prüfen. Darüber hinaus finde ich es gedanklich nachvollziehbarer erst den EIngabe und dann den Ausgabewert zu defineiren. Im normalen Leben holen wir den Kuchen ja auch nicht erst aus den Backofen und stellen Ihn dann in den Backofen. smile.gif

ZITAT
Hmm - eigentlich nicht. Gerade weil wir eine feste und unveränderliche Factory haben, an der keiner mehr basteln soll, ist doch alles mit graden Linien umrissen. Als Entwickler weiß ich genau dass ich die transform-Methode aufrufen kann und ein Ergebnis zurückbekomme -- was im Hintergrund passiert ist völlig uninteressant.

OK


ZITAT
Naja das ham wir doch dann??

War mir nicht klar, das Du das so vor hast, aber wenns so ist, OK.
MaZderMind
ZITAT
Aber wenn Du die Methode mit einem Parameter anbietest, würde ich vorschlagen, als ersten Parameter das Eingabeformat in der isSupported Methode zu übergeben.

Wo er recht hat... smile.gif

Das muss aber dann auch bei der Transform-Methode angepasst werden. Bedeutet also beim transformieren: entweder ich geb beide Parameter an oder keinen, weil eine Transformation mit nur einen Eingabeformat geht ja nich biggrin.gif

Gruß, Peter
Dieses ist eine vereinfachte Darstellung unseres Foreninhaltes. Um die detaillierte Vollansicht mit Formatierung und Bildern zu betrachten, bitte hier klicken.
Invision Power Board © 2001-2024 Invision Power Services, Inc.