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.


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]).

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.

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.

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:

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


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


Sorry.. das versteh ich nich 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

Der Beitrag wurde von MaZderMind bearbeitet: Tue. 5. September 2006, 06:14

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.


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.


Ich auch

Der Beitrag wurde von braendle bearbeitet: Tue. 5. September 2006, 09:20

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.


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.

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


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.

Naja das ham wir doch dann??

Naja hmm ich bau jetz mal so weiter wie gehabt..
Gruß, Peter

Naja, mach einfach mal, ich denke ist besser, als das jetzt hier totzudiskutieren.

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.


OK



War mir nicht klar, das Du das so vor hast, aber wenns so ist, OK.

Wo er recht hat...

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

Gruß, Peter

Der Beitrag wurde von MaZderMind bearbeitet: Wed. 6. September 2006, 06:25

Wieso kann man dafür nicht HTML als einheitliche Zwischensprache verwenden? Sefrengo ist ja ein Web CMS - da sollte doch alles mit (X)HTML darstellbar sein. Jeder Transformator bräuchte dann nur noch eine Methode string convertFromHTML(string $HTMLInput)
Macht mich schlauer, indem ihr mir erklärt warum es nicht geht.

PS: Auch mir gefällt, was ich hier lese und wie es gemeinschaftlich weiterentwickelt wird. Wirft meiner Meinung nach ein gutes Licht auf Sefrengo und seine Core-Entwickler.

Weil HTML viel zu vielschichtig und universell ist. Du kannst zwar alles was du in bbCode definieren kannst nach HTML transformieren aber nur einen Bruchteil dessen was in HTML dargestellt werden in ein entsprechendes bbCode-Format umwandeln.
Ich traue mir nicht zu eine solche Transformationsroutine (HTML -> bbCode) zu entwickeln.

Gruß, Peter

Naja, wie im Prinzip ist das so ähnlich wie wenn du noch ein neues format zur darstellung und speicherung von text auflegen willst. jedes in diesem thread schoneinmal genannt format hat seinen einsatzzweck, möglichkeiten und grenzen. nicht alle möglichkeiten werden von allen formaten unterstützt, also gibt es immer ein format das nicht alles darstellen kann.

ein format zu entwicklen, das alle mölichkeiten abdeckt (nur das wäre als zwichenformat wirklich sinnvoll) ist ein ziemlicher aufwand und imho das rad neu erfinden.
in allen anderen fällen musst du immer mit konvertierungsverlusten leben, die z.B. bei HTML-Tabellen nach BBCode o.ä. manchmal heftig ausfallen könnten.

Das ist sicher richtig. Aber ist es wirklich nötig alles aus (X)HTML z.B. in den BbCode zu transformieren. Es sollte doch möglich sein z.B. nur das von (X)HTML zum BbCode zu transformieren welches dem Verwendungszweck entspricht und den ganzen Rest als (X)HTML zu belassen.
Um beim Beispiel BbCode zu bleiben, es wird wohl kaum nötig sein damit ein vollständiges Pendent zum HTML-Editor zu schaffen. Primär sehe ich eher den Einsatz in Kombination mit Contentflex und allenfalls ähnlich einsetzbaren Modulen. Oder anders ausgedrückt, mit dem BbCode sollte alles was in Textform erscheint erstellbar und transformierbar sein.

Nein, es ist nicht nötig alles aus XHTML nach BBCode zu transformieren, auch nicht umgekehrt. Ergo braucht man kein einheitliches Zwischenformat - darum ging es Daniel. Es werden Transformationen entwickelt, die zwischen den Formaten vermitteln und gut ist.

Es geht da grad' nicht um die Textfilter-API, sondern um eine Metasprache zur einheitlichen Abbildung aller Textformate in Sefrengo. Und das ist imho overfeatured per se.

Der Beitrag wurde von braendle bearbeitet: Tue. 12. September 2006, 06:54

Hi
Ich hab noch ne Frage bzgl. der Links. Also im eingangstext stehen Links wie cms://idcat=2. Wenn ich jetzt eine Text->Html-Transformation ausführe werden diese mit <a href=".."> umschlossen. Soll da jetzt weiterhin cms://idcat=2 drinstehen oder der tatsächliche Pfad zu dieseM Ordner? Je nach verwendungszweck wäre erstes (versenden als HTML-Teil einer eMail, speichern als Datei) oder letztes (ausgeben im Browser) besser.
Bei einer Text->Text-Transformation stellt sich die selbe Frage -- auch hier ist je nach Ausgabemedium das eine oder das andere gewünscht.

Gruß, Peter

ich würde für diese Sache zwei Transformationen hintereinander schalten.
Text -> HTML baut um ohne den Link zu ändern

CMSLink -> URLRel baut Links der Variante cms://idcat=2 in eine relative URL um
CMSLink -> URLAbs baut Links der Variante cms://idcat=2 in eine absolute URL um
CMSLink -> URLRW baut Links der Variante cms://idcat=2 in eine sprechende URL um

Die Umwandlung CMSLink -> URLFormat ändert nur die Links, nicht das sie umgebende HTML-, PDF- oder Text-Konstrukt.
Diese Umwandlung kommt in eine eigene Transformklasse und schon ist das Problem gelöst.

Wenn Du beides benötigst, dann rufst Du erst die Transformation Text->HTML auf und im Anschluss CMSLink->URLFormat. Und so kann man seine Texte dann entsprechend umbauen in dem einfach der Baukasten an Transformationen benutzt wird.

Wichtig ist hier eben in einer Doku die Fähigkeiten der einzelnen Transformationen festzuhalten.

In einem zweiten Release kannst man ja weitere Transformationen implementieren, die sich aus diesen Grundtransformationen zusammensetzen: Text->HTMLURLAbs, die macht dann nix anderes als die beiden Transformationen Text->HTML und CMSLink->URLAbs nacheinander aufzurufen.
Aber erstmal würde ich die enfachen Transformationen bauen, testen und releasen.

Hmm okay das klingt sinnvoll.. auch wens doof aussieht ^^

Najut, machen wirs so

Gruß, Peter

Der Beitrag wurde von MaZderMind bearbeitet: Tue. 12. September 2006, 15:09

Find ich gut.

Über Geschmack kann man sich streiten ... funktionieren tut's umso besser

Es gibt aber noch die Kurzform, oder?