Fehler TinyIMG - Umgang mit der WSC-API

  • TinyImg ersetzt in einem EventListener bei Uploads die AttachmentAction-Klasse durch eine eigene. Folge:


    Andere Plugins, die auf upload der AttachmentAction hören, funktionieren damit nicht mehr.
    (Und ja, es gibt mindestens eines, auf das dies zutrifft...)

  • Mir sind die Probleme mit der Umsetzung einer Skalierung der Dateianhänge nicht bekannt; brauche ich auch nicht. Es ist aus meiner Sicht aber keine vernünftige Lösung, Funktionen umzusetzen, die die API kompromittieren und damit andere Plugins 'zerstören'.


    Bedauerlicherweise ist das nicht der erste Fall in der jüngsten Vergangenheit. Der eine verbiegt einfach mal so die ThreadList-Klasse, der andere die AttachmentAction-Klasse und dann einer die xyz-Klasse, damit er was Tolles hat, was sich ansonsten nicht umsetzen lässt. Und Kunden/Nutzer schauen in die Röhre und haben Probleme, weil Sachen nicht mehr so funktionieren, wie gedacht / beworben.


    Im erstgenannten Fall war das wohl nur ein einfacher Fehler (schlicht die Folgen übersehen), aber dass das nun offensichtlich trotz Kenntnis der Folgen gemacht wird, ist schon irgendwie bedenklich und kann eigentlich nicht sein.

  • Nun, wenn die alternative ist unser Plugin einzustampfen weil es schlicht keine alternative Möglichkeit gibt, dann tut es mir wirklich leid.
    Ich verstehe durchaus deinen Frust, aber wir haben uns über die Probleme seit der ersten Version des Plugins Gedanken gemacht (also noch zu beginn des WCF2.1) und leider keine alternative Möglichkeit gefunden dies zu lösen.

  • Welches Plugin funktioniert denn nicht korrekt von dir @UdoZ? Vielleicht sollte man das hier direkt ansprechen, so dass Leute, die das TinyIMG Plugin nutzen wollen, sich eben bewusst sein müssen, dass dann dein Plugin nicht mehr korrekt funktioniert.


    Ist sicher nicht die beste Lösung, aber so kann Jeder selbst entscheiden, welches Plugin wichtiger ist. :)

  • Ich verstehe durchaus deinen Frust


    aber so kann Jeder selbst entscheiden, welches Plugin wichtiger ist

    Es geht (mir) nicht um Frust oder um eine Entscheidung für ein bestimmtes Plugin. Die Entscheidung könnte man Nutzer, BTW, auch mit der Paketdatei (package.xml - excludedPackages) abnehmen.


    Vielmehr geht es mir um die grundsätzliche Frage, wie sakrosankt die API sein sollte und wie kooperativ die Entwickler sind. Wenn immer mehr Entwickler die API verbiegen, dann gibt es zwangsläufig immer mehr Chaos / Unzuverlässigkeit in der Plugin-Szene. Man kann ganz einfach nicht jedes Plugin kennen und auch nicht eigene Plugins 100%ig dahingehend prüfen, ob sie mit allen anderen einwandfrei funktionieren. Wenn die API unangetastet bleibt, gibt es nur wenige Fälle, in denen es zu Konflikten kommen könnte. Die sind aber in der Regel leicht zu beheben.


    Fälle wie diese lassen sich aber schlichtweg nicht beheben und zwingen die Benutzer tatsächlich, sich zwischen Plugins zu entscheiden. Dies wird mittelfristig wahrscheinlich auch negative Folgen für WoltLab haben. Und bitte nicht vergessen:
    Thema wird das bei Nutzern/Kunden meist erst, wenn sie das 2. Plugin installieren und dann eines der beiden nicht mehr funktioniert. Sie haben aber zumindest in DEU (theoretisch) Anspruch darauf, dass beide funktionieren, und könnten auch versuchen, diesen durchzusetzen. Und dann?!? Wer ist verantwortlich? Wer muss nachbessern?

  • Thema wird das bei Nutzern/Kunden meist erst, wenn sie das 2. Plugin installieren und dann eines der beiden nicht mehr funktioniert. Sie haben aber zumindest in DEU (theoretisch) Anspruch darauf, dass beide funktionieren, und könnten auch versuchen, diesen durchzusetzen. Und dann?!? Wer ist verantwortlich? Wer muss nachbessern?

    So hatte ich das gar nicht gesehen... :thinking:

  • Fakt ist: Ja, es gibt einen Konzipierungsfehler und nein, er liegt nicht bei uns. Es kommt nicht selten vor, dass man derartige "Workarounds" nutzen muss, um sein Vorhaben umzusetzen. Ebenso selten kommt es vor, dass sich die Entwickler untereinander auf entsprechende Lösungen einigen müssen. Ich erinnere mich noch daran, wie ich das Nutzungsbestimmungen-Plugin umbauen musste, weil Peter oder Chris (ich weiß es nicht mehr genau) ein Template in der eigenen EA so genannt haben, wie ich in meinem Plugin.


    Ich bin natürlich gewillt, auch hierfür eine Lösung zu finden oder anzunehmen, die deine Probleme lösen würde, obgleich ich den Fehler halt bei WoltLab sehe. Das Plugin einzustampfen kommt allerdings nicht in Frage.

  • Ja, es gibt einen Konzipierungsfehler und nein, er liegt nicht bei uns.

    Bei wem denn? Doch nicht etwa bei WL, weil die EventListener ermöglichen? Oder gar bei anderen Entwicklern, die die API korrekt nutzen? Bei Nutzern, die eine dann wohl doofe Kombination von Plugins nutzen wollen? Das klingt mir irgendwie nach der Geschichte, bei der der Messerhersteller daran schuld war, dass einer erstochen wurde.

    Es kommt nicht selten vor, dass man derartige "Workarounds" nutzen muss, um sein Vorhaben umzusetzen.

    Du verharmlost das meiner Bewertung nach und unterschätzt die (abstrakten) Folgen eines solchen "Workarounds". Tatsächlich wird die API in diesem speziellen Fall unbrauchbar gemacht. Davon sind - habe mittlerweile nachgezählt - allein drei meiner Plugins (2x schon lange veröffentlicht, 1x in der noch unveröffentlichten Version) betroffen. Und es sind natürlich alle anderen Plugins betroffen, die Ähnliches machen, und es werden immer mehr betroffene Plugins sein, wenn andere sich an diesem Vorgehen ein Beispiel nehmen.


    Meine Maxime bisher: wenn sich ein Vorhaben nicht korrekt und mit legitimen Mitteln umsetzen lässt, sollte man sich ein anderes Vorhaben suchen. Bringt nach meiner Erfahrung deutlich mehr als etwas zu Lasten anderer und mit nicht wirklich absehbaren Folgen durchzudrücken.

    Ebenso selten kommt es vor, dass sich die Entwickler untereinander auf entsprechende Lösungen einigen müssen. Ich erinnere mich noch daran, wie ich das Nutzungsbestimmungen-Plugin umbauen musste, weil Peter oder Chris (ich weiß es nicht mehr genau) ein Template in der eigenen EA so genannt haben, wie ich in meinem Plugin.

    Ich glaube, dass mein Punkt nicht richtig verstanden wurde. Du lieferst hier ein Beispiel dafür, dass die API funktioniert und solche Konflikte verhindert. Klar müssen die Entwickler sich in solch einem Fall irgendwie einigen. Ist zwar ätzend, aber letzlich völlig unkritisch. In diesem Fall, ich wiederhole mich, wird die API unbrauchbar gemacht. Entwickler können sich nicht mehr auf die API verlassen, sind von tollen Ideen anderen im negativen Sinne abhängig und können faktisch nichts dagegen machen. Natürlich überall einen weiteren EL einbauen, der den des anderen Plugins wieder aushebelt. Aber das kann keine vernünftige Lösung sein; funktioniert auch nur kurz. niceValue...


    Konkret:
    Was sage ich meinen Kunden, deren Plugins nicht mehr in Gänze funktionieren, weil die API von einem Drittplugin verbogen wird? Oder übernimmst Du den Support?
    Wie erkläre ich WL, dass es deren Fehler ist, ohne mich gänzlich lächerlich zu machen?

  • Doch nicht etwa bei WL, weil die EventListener ermöglichen?


    Wo kein EL existiert, kann auch keiner genutzt werden. Und wenn sich aufgrund dessen nur Plugins mittels Workaround umsetzen lassen um am Ende so zu funktionieren wie sie sollen, dann ist das leider so. Ist ja nicht so, dass ich nun werweiß wie scharf auf unsere Lösung bin, aber es gibt halt keine andere. Ansonsten bin ich auf deine Vorschläge gespannt.

  • Wo kein EL existiert, kann auch keiner genutzt werden.

    Ja, und auch ich könnte einige zusätzliche gebrauchen, damit ich endlich einige Sachen umsetzen kann.


    Ansonsten bin ich auf deine Vorschläge gespannt.

    ?
    Kurzanalyse: das Event upload Klasse AttachmentAction wurde gekillt, existiert also nicht mehr, wird aber gebraucht.
    Vorschlag: dieses Event wiederherstellen, emulieren, was weiß ich. Du hast da sicher mehr drauf als ich.

  • Hast du denn mal versucht das Event inherit zu setzen ?
    Denn unsere Klasse erbt von der AttachmentAction (wir wollten wie gesagt die möglichen Probleme minimal halten) und daher sollte das eigentlich genügen, wenn dein Plugin funktioniert wie ich es vermute.


    Das Problem an der Sache ist, dass das verschieben aus dem upload ordner (bei dem man im allgemeinen keinen Schreibzugriff hat) im selben schritt erfolgt in dem auch die Daten über den upload selbst zusammen gefasst werden, sodass man hier die Daten die an den Client übermittelt werden nicht mehr verändern kann.
    Hätten wir also mit regulären Events gearbeitet hätte es Anzeigefehler gegeben die so nicht behebbar sind.

  • Hast du denn mal versucht das Event inherit zu setzen ?
    Denn unsere Klasse erbt von der AttachmentAction (wir wollten wie gesagt die möglichen Probleme minimal halten) und daher sollte das eigentlich genügen, wenn dein Plugin funktioniert wie ich es vermute.


    Ja, war schon immer bei den betroffenen Plugins gesetzt.


    Aber gut, dass Du das mit dem Erben angesprochen hast. Ich habe beim Debuggen nicht daran gedacht und es deswegen tatsächlich an der falschen Stelle abgefragt. Das Event kommt doch an. Es läuft aber trotzdem ins Leere, weil der Klassenname ja durch Euer Plugin geändert wird. Also streiche oben EL und setze Klassenname. Die Kernaussage ändert das nicht.

  • Daran kann ich leider nichts ändern, aber zeig mal deinen EL, eventuell fällt mir was ein wie du das sinnvoll umsetzen kannst.

    Danke für das Angebot, aber das kann ich dann auch selbst. Mittlerweile habe ich etwas Routine darin, meine, mal ganz frech behauptet, WCF-/WSC-konformen Plugins wegen anderer Plugins zu modifizieren und Nutzer mit Updates zu nerven ;-)


    Dieser Teil meines Themas ist auch nur einer von zweien. Der zweite ist mir deutlich wichtiger, aber irgendwie sehe ich dabei eher Windmühlen als 'Erfolge'. Für Entwickler, die für das Forum freigeschaltet sind: 261324-freischaltung-von-plugins-die-grundfunktionen-verändern

  • Kann deinen Link leider nicht öffnen, daher keine Ahnung wovon du sprichst^^
    Und ja, wir versuchen, sofern dies möglich ist, unsere Plugins WSC/WCF konform zu programmieren, aber wenn dies eben aufgrund der technischen Gegebenheiten nicht möglich ist hat man die Wahl es bleiben zu lassen, oder eben die Konformität beiseite zu legen und anders an das Problem ran zu gehen.
    Die einzige gangbare alternative wäre es gewesen, die return values via reflection zu manipulieren, damit wäre zwar dein Plugin nicht betroffen gewesen, allerdings halte ich den Ansatz für deutlich unschöner als den aktuellen :P