Beiträge von UdoZ

    man kann durchaus auch eigene Oberflächen mit den gegeben Mitteln gestalten.

    Ich bin nicht wirklich der CSS-/HTML-Freak. Aber ich bezweifele, dass man in einer Anwendung ohne eigenes CSS auskommen kann; insbesondere nicht, wenn gleichzeitig mehr Kreativität gewünscht wird. Und sobald ein Fitzelchen eigenes CSS dabei ist, sind wir wieder mitten im o.a. Thema.

    Wir haben ja jetzt schon mindestens vier Endanwendungen die annähernd identisch aussehen, ist das wirklich eine für Anwender vorteilhafte Situation und das was gewünscht ist?

    Ich schließe aus dem Feedback und den (seltenen) Diskussionen über dieses Thema, dass es so gewünscht ist.

    Als Beispiel kann man die Filebase, den Marktplatz und die POI-App anführen. Alle Apps verwenden in der Übersicht die selbe Darstellung, da der Code der Filebase aber nicht frei verfügbar ist, baut jeder die Darstellung nach.

    Ja, das ist tatsächlich so. Ist ist aber, Achtung Unwort, alternativlos, wenn man die Anwendung optisch zum Rest passend gestalten will. Mit Bordmittel (des WSC) ist es einfach nicht möglich, weswegen das ein potenzielles Problem mit jeder Drittanbieter-Anwendung ist.


    Das ist noch irgendwo ein konzeptioneller Schachpunkt im Framework. Man stellt zwar eine Basis bereit, aber dann doch nicht so wirklich.

    ACK.

    Auch wenn man sich selbst an alle Standards und Vorgaben hält und noch so penibel nach Fehlern aus schau hält sind Fehler nicht ausgeschlossen.

    Korrekt. Es gibt keine fehlerfreien Plugins, wenn diese einen gewissen Umfang haben, und man kann solche Plugins naturgemäß nicht 100%-ig durchtesten und alle Fehler beseitigen. Deswegen ist es nicht ausgeschlossen, dass trotz tagelanger eigener Tests und öffentlicher Beta-Tests auch banale Fehler es in den Release schaffen. Wenn dann der Support stimmt, ist doch alles in Ordnung.



    Der Klassiker dabei ist das Doppelte-Lottchen.

    Was mich jedoch verwundert ist, das keiner die anderen Pakete ausschließt via


    <excludedpackages>, so wie es eigentlich üblich ist.

    Es gibt nach meinem Verständnis nur genau einen Grund, andere Pakete auszuschließen: technische Unverträglichkeit.
    Identische Funktion ist kein valider Ausschlussgrund, denn 1. belebt Konkurrenz das Geschäft und 2. sollte man immer von mündigen Nutzern ausgehen, die selbst entscheiden können, was sie installieren.


    Zu der Stil-Geschichte: agree to disagree ;)



    Am Ende sind es die Anwender die sich über plötzlich auftauchende Fehler und Problemen aufregen.

    Ja, in der Regel zurecht. Aber da Fehler unvermeidbar sind, müssen beide Seiten damit leben und ganz einfach nur vernünftig damit umgehen.

    Testet ihr eure Plugins nur im Standard-Stil und bei einem von Plugins von Drittenentwickler freien WoltLab Suite?

    Das ist irgendwie eine seltsame Frage. Die Antwort ist natürlich ja.
    Zum einen ist es unmöglich, alle möglichen Kombinationen von Stilen und Erweiterungen zu testen. Und zum anderen sollte das ausreichen, wenn man sich an Stil- / API-Vorgaben von WL und deren 'Best Practices' hält.


    Probleme mit Stilen gibt es in der Regel nur, wenn Stile fehlerhaft sind. Und Probleme mit anderen Plugins (im Betrieb) gibt es nur, wenn diese nicht systemkonform bzw. unkooperativ geschrieben sind; Klassiker dürfte ein verbogene EventListener sein, der andere Plugins alt aussehen lässt, die diesen EL auch nutzen.

    Hat man mit Kauf von EasyMedia für WSC auch Zugriff auf die WCF-Version?


    Ich plane EasyMedia statt WL-Galerie unter WoltLab Suite einzusetzen, will aber schon jetzt meine Seite umbauen, die noch unter WCF läuft.

    Danke, aber genau deswegen fragte ich.


    Der Hinweis soll unbedingt weg. Kunde investiert ungerne ein paar hundert Euro, um alle genutzten Pakete branding free zu bekommen, um dann ständig den Stil-Hinweis zu sehen. Er würde natürlich auch einen kostenpflichtigen Stil kaufen. Aber wenn nun mal ausgerechnet der kostenlose Stil gefällt ...