Pluginentwicklung: Projekt Manager

  • Hallo an alle professionellen und Hobby-Pluginentwickler, sowie an jene, die es noch werden wollen!


    Im Folgenden möchte ich ein Hilfsmittel zur Pluginentwicklung vorstellen, welches sich im Moment auf der Zielgerade zur Veröffentlichung befindet. Angepeilt ist das erste Quartal 2016. Vor der ersten Veröffentlichung gibt es für mich allerdings noch ein paar Fragen abzuklären und ich möchte schon mal erstes Feedback einholen, um gegebenenfalls direkt darauf reagieren zu können.


    Projekt Manager
    Zuerst ein mal möchte ich erklären, was der Projekt Manager ist, was er macht und auch was er nicht ist. Der Projekt Manager ist ein Plugin für das WCF 2.1, welches man sich als Entwickler in seiner lokalen WCF Installation hinzufügt. Der Projekt Manager bietet dann über das ACP die folgenden grundlegenden Funktionen, auf welche ich noch näher eingehen werde:

    • Pakete hinzufügen
    • Daten von PIPs (wie Optionen und Sprachvariablen) dem Paket hinzufügen und die Datenbankstruktur des Pakets anlegen
    • Das Paket exportieren
    • Eine neue Version des Pakets anlegen und diese mit entsprechenden (automatisch generierten) Update Anweisungen erneut exportieren
    • Live zwischen Versionen des Pakets wechseln


    Der Projekt Manager ist keine IDE! Die Nutzung einer IDE wird durch den Projekt Manager in keiner Weise eingeschränkt.


    Paket hinzufügen
    Ein Paket wird über ein Formular im ACP angelegt. Nachdem das Paket hinzugefügt wurde, ist es wie ein frisch installiertes leeres Paket in der WCF Installation vorhanden. Das heißt, es wird ein Eintrag in der wcf1_package Tabelle vorgenommen (ebenso, je nach Angaben, auch in den Tabellen wcf1_package_exclusion und wcf1_package_requirement sowie in der vom Projekt Manager stammenden Tabelle wcf1_package_optional). Pakete, an welchen gearbeitet wird, werden als Projekte bezeichnet. Ein Projekt kann deaktiviert werden, damit es nicht mehr unter "Projekte auflisten" zu sehen ist. In der Paketliste kann jedes Paket als Projekt aktiviert werden.



    Projekt Übersicht
    Gehen wir davon aus, wir haben ein Paket hinzugefügt und es steht nun als Projekt zur Verfügung. Unter "Projekte auflisten" finden wir das Projekt und klicken es an, um in die Übersicht des Projekts zu kommen. In der Übersicht bekommen wir alles angezeigt, was zu dem Paket des Projekts gehört, das umfasst aktuell:


    Hier Beispielhaft die Übersicht für ein Plugin, welches ich für meine Community mithilfe des Projekt Managers entwickelt habe. Zu beachten ist, dass es ein paar nette Features wie die Filter Funktion oder das Ändern der ShowOrder per Drag 'n' Drop gibt.


    Die Datenbank Struktur, welche das Plugin mitbringen soll, wird ebenfalls vollständig über den Projekt Manager verwaltet. Der Projekt Manager lässt dabei in den Formularen nur Eingaben zu, welche der SQLParser des WCF auch versteht.


    PIP Daten hinzufügen
    Für jedes PIP, welches in der Übersicht zu sehen ist, sowie für die Datenbank gibt es entsprechende Formulare, über welches man Einträge hinzufügen oder bearbeiten kann. Beispielsweise:


    Dateien
    Bleibt die Frage zu klären, wie man eigentlich seine PHP und Javascript Dateien verwaltet. Hierbei gibt es zwei Optionen: Entweder kann man die Dateien direkt in der WCF Installation anlegen und bearbeiten oder mit einer Erweiterung für den Projekt Manager können die Dateien pro Projekt auch extern abgelegt werden und der Projekt Manager sorgt dafür, dass das WCF darauf zugreifen kann. Entscheidend ist hierbei, dass man einen beliebigen Editor beziehungsweise eine frei wählbare IDE benutzen kann, um die Dateien zu bearbeiten.


    Meine Projektstruktur sieht beispielsweise so aus, dass die WCF Installation im Verzeichnis xampp\htdocs\workspace\wcf2_1 liegt und die Projekte sind alle in eigenen Ordnern im workspace, beispielsweise xampp\htdocs\workspace\LatestPostsAndThreads. Als IDE nutze ich Eclipse und dort sieht das dann so aus:


    Der Projekt Manager erkennt bei extern abgelegten Projekten automatisch über die Ordner, zu welcher Anwendung die Dateien gehört. Daher befindet sich im LatestPostsAndThreads Projekt der Ordner wbb, damit der Projekt Manager weiß, dass die Dateien in das WBB sollen. Auf diese Weise kann man leicht die Dateien seines Plugins auch in mehreren Anwendungen ablegen, wenn dies sinnvoll erscheint. Diesen Fall hatte ich zum Beispiel gerade bei den Neuesten Beiträgen und Themen mit der .less Datei, welche ins WCF muss, obwohl das Plugin eigentlich für das WBB gedacht ist.


    Live Testen
    Da alle Teile des Pakets sich in einer WCF Installation befinden, sowie alle Angaben wie Optionen und Sprachvariablen vorhanden sind, können alle Änderungen am Paket live beobachtet und getestet werden. Man kann auch einfach mal eine Debug Ausgabe einbauen (beispielsweise ein print_r($var); exit;) und sich das Ergebnis ansehen.


    Paket exportieren
    Sobald alles funktioniert wie es soll, alle Sprachvariablen, Datenbanktabellen und Listener angelegt sind, alle PHP Dateien sauber kommentiert und das Plugin live getestet wurde, geht es ans exportieren. Durch das Exportieren wird der aktuelle Zustand des Plugins zusammen mit der aktuellen Versionsnummer fixiert und als .tar Archiv exportiert, welches im WCF installiert werden kann.


    Versionierung
    Aktuell kann der Projekt Manager nur damit umgehen, wenn die Versionsnummer des Pakets immer weiter erhöht wird. Das heißt, nachdem die erste Version des Pakets exportiert wurde, gibt man eine höhere Versionsnummer für das Paket an. Man behebt im Anschluss Fehler, fügt neue Funktionen hinzu und stellt die nächste Version fertig. Exportiert man diese, wird das Paket automatisch mit den richtigen Update Anweisungen in der package.xml ausgestattet.


    Was aktuell noch nicht möglich ist, aber bis zum Erscheinen Möglich sein soll: Nachdem man beispielsweise Version 1.0 seines Pakets exportiert hat, legt man Version 2.0 an, um mit der Entwicklung der neuen Major Version mit neuen Features zu arbeiten. Man beginnt mit der Arbeit, legt neue Optionen an und verändert bestehende Dateien. Jetzt bekommt man Fehlerberichte über Version 1.0 und möchte eine Version 1.1 mit behobenen Fehlern rausbringen. Es soll nun mit dem Projekt Manager möglich sein, eine Version 1.1 des Pakets anzulegen und von Version 2.0 auf 1.1 zu wechseln, ohne dass die Änderungen, welche man für 2.0 vorgenommen hat, Einfluss auf 1.1 haben oder verloren gehen. Nachdem man die Fehler behoben hat, exportiert man Version 1.1 und kann wieder zu 2.0 wechseln. Dabei fügt man die Änderungen von 1.1 und 2.0 zusammen (ein Merge, ähnlich wie mit Git oder SVN, nur dass man hier neben Dateien auch Optionen, Sprachvariablen und ähnliches zusammenführt). Jetzt kann man weiter an Version 2.0 arbeiten. Hierbei ist allerdings für mich noch die Frage ungeklärt, in wie weit das mit Repository Systemen wie Git und SVN funktionieren wird. Gegebenenfalls müsste dann auch der Entwickler für jede Version seines Pakets einen entsprechenden Zweig anlegen und wenn er die Version im Projekt Manager wechselt auch den Zweig bei seinem Repository wechseln.


    Lizenz und Kosten
    Hier habe ich Fragen an die Fachkundigen unter uns. Ich strebe folgendes Modell an: Der Projekt Manager soll an sich kostenfrei erhältlich und nutzbar sein. Benutzt man den Projekt Manager aber kommerziell, um entweder Plugins zu verkaufen oder Plugins herzustellen, welche auf kommerziellen Plattformen benutzt werden, soll eine extra Lizenz erforderlich sein. Mit ist klar, dass es einige schwarze Schafe geben wird, welche die Lizenz trotz kommerzieller Nutzung nicht erwerben werden, aber ich möchte es für Hobbyentwickler und Einsteiger so einfach wie möglich machen. Unter welcher Lizenz sollte der Projekt Manager veröffentlicht werden, damit ich das genannte Modell umsetzen kann? Was gilt es dabei zu beachten?


    Zweiter Punkt ist meine persönliche Absicherung: Angenommen der Projekt Manager macht irgendetwas falsches, löscht beispielsweise alle Dateien eines Projekts unwiederbringlich. Kann ich Haftung in diese Richtung ausschließen? (Natürlich nicht für Fälle, bei welchen ich absichtlich so etwas eingebaut oder grob fahrlässig gehandelt hätte) Wie müsste ein solcher Haftungsausschluss aussehen, damit ich vor Ansprüchen gesichert bin?


    Zusammenfassung
    Der Projekt Manager ist ein WCF Plugin, welches Entwicklern eine Oberfläche zum Anlegen, Verwalten, Exportieren und Versionieren ihrer Plugins bietet. Er soll im ersten Quartal 2016 veröffentlicht werden. Die Wahl des Texteditors oder der IDE wird durch ihn nicht eingeschränkt. Die Nutzung von Git oder SVN wir durch die Versionierung des Projekt Managers beeinflusst, aber nicht verhindert. Der Projekt Manager soll für nicht-kommerzielle Entwickler kostenfrei sein. Bitte beachtet meine Fragen unter "Lizenz und Kosten".



    Ich bin gespannt, was euer erster Eindruck ist, was für Fragen und Feedback ihr habt. Zudem würde ich mich freuen, wenn ihr mir bezüglich Lizenz und Haftung weiterhelfen könnt :)

  • mit der .less Datei, welche ins WCF muss

    Nur zur Info. Die .less Dateien müssen nicht im WCF abgelegt werden, sondern können auch in der Anwendung sein, die dazu benötigt wird.


    Unter welcher Lizenz sollte der Projekt Manager veröffentlicht werden, damit ich das genannte Modell umsetzen kann?

    Puh. Die gängigen Lizenzen sind meist auf Open Source ausgelegt oder basieren auf dem Kreativität-Recht welche eingeschränkt weiterverarbeitbar ist.


    Hierzu solltest du eventuell eine eigene Lizenz mit deinen persönlichen Lizenzrechten erstellen/ erstellen lassen.


    Angenommen der Projekt Manager macht irgendetwas falsches, löscht beispielsweise alle Dateien eines Projekts unwiederbringlich. Kann ich Haftung in diese Richtung ausschließen?

    Das kann dir wohl nur ein Rechtsanwalt genauer sagen. Schätze nicht, dass hier Leute mit Rechtsbeistand verlässlich helfen können.



    Grundsätzlich zur Versionierung: Sogenannte Forks sind immer sehr nützlich (wie du es bis zum Release einplanst). In wie weit das technisch aber möglich sein wird, werden wir ja dann sehen. Das ist ein schwieriger Teil des Plugins.


    Zu Kosten: Das Kosten-Modell finde ich sehr gut. Mal schauen wie hoch du dann den Preis für kommerzielle Projekte anlegen wirst..


    Ohne das Plugin generell selber zu testen, ist es schwierig hierzu genaueres zu sagen. Ich sage vorerst mal top, da ich solch ein Projekt sowieso im Kopf hatte und die Umsetzung sehr gut ausschaut. Weiteres werden wir dann sehen..


    Ich würde dir vor dem Release aber definitiv raten, viele und große Tests durchzuführen. Das Plugin kann natürlich sehr viel Frust einbringen, wenn eine Funktion nicht mehr funktioniert und dann die Entwicklung der eignen Plugins gestoppt / verlagert werden muss.

  • Nur zur Info. Die .less Dateien müssen nicht im WCF abgelegt werden, sondern können auch in der Anwendung sein, die dazu benötigt wird.

    Gilt leider nicht für die ACP CSS Datei.



    Zu Kosten: Das Kosten-Modell finde ich sehr gut. Mal schauen wie hoch du dann den Preis für kommerzielle Projekte anlegen wirst..

    Ich denke da an nichts besonders hohes. Vielleicht niedriger dreistelliger oder sogar zweistelliger Betrag.

  • Ich finde das ist eine Klasse Idee. Dürfte auch einigen Anfängern und Interessierten im Bereich Pluginentwicklung das Leben deutlich erleichtern.


    Schade, dass Woltlab sowas nicht kostenlos zur Verfügung stellt. Hast Du mal Woltlab gefragt, ob sie Interesse daran haben?


    Grüße, CCFF

  • Bisher gab es leider wenig Feedback von Entwicklern.

    Das kommt sicherlich, wenn das Plugin verfügbar ist und man es ausprobieren kann. Da habe ich keine Zweifel.


    Dennoch wollte ich nachfragen, ob du schon einen Plan zur Veröffentlichung hast?

    An meinem im einleitenden Beitrag beschriebenen Ziel, eine erste Version im ersten Quartal 2016 zu veröffentlichen (man sollte hier eher von Ende Februar oder März ausgehen), hat sich nichts geändert. Vielleicht schaffe ich es vorher eine stabil wirkende Betaversion für erstes Feedback und Debugging an Interessierte zu verteilen. Das würde ich aber entsprechend nochmal bekanntgeben. Ich habe letzten Sonntag ein erstes Plugin in den Store gestellt (wartet noch auf Freischaltung), welches ich mit dem Projekt Manager entwickelt und exportiert habe. Ein weiteres Plugin werde ich in Kürze ebenfalls in den Store stellen. Im Grunde ist an den Paketen aber nichts besonderes zu sehen, da sie ja regulär strukturiert und gepackt sind. Viele weitere Plugins, welche ich mit dem Projekt Manager entwickelt habe, laufen bereits in meiner Community, welche ich vor fünf Wochen vom WBB 3 auf WBB 4.1 umgezogen habe.


    Schade, dass Woltlab sowas nicht kostenlos zur Verfügung stellt. Hast Du mal Woltlab gefragt, ob sie Interesse daran haben?

    Im Endeffekt entstand aus dem Mangel seitens WoltLab überhaupt meine Motivation so etwas zu entwickeln. Hätte ich nicht schon mit dem WCF 1.1 und WBB3, sowie der dort vorhandenen Dokumentation gearbeitet, wäre es mir wohl nur unter hohem Zeitaufwand und großem Fehlerpotential möglich gewesen, für meine Community für das WCF 2.X Plugins zu entwickeln oder gar den Projekt Manager anzufertigen. Glücklicherweise hatte ich das Vorwissen, um mich recht gut in das WCF 2 einzuarbeiten und durch die Entwicklung des Projekt Managers bin ich auch sehr tief in die Arbeitsweise und den Quellcode des neuen WCF vorgedrungen, um herauszufinden, worauf ich bei den vielen Abstraktionen zu achten habe. Damit anderen das aber erspart bleibt, ist es nur sinnvoll, das Ganze zu veröffentlichen. Dazu noch eine schöne Dokumentation und man kann in der Tat als WCF-Neuling recht schnell die ersten einfachen Plugins entwickeln.


    Eine Dokumentation für das WCF kann ich zwar nicht bieten, aber natürlich soll es für den Projekt Manager eine Dokumentation geben. Es ist dann nur logisch, dass ich dort auch die einzelnen Komponenten des WCF, welche man mit dem Projekt Manager verwalten kann, beschreibe. Vielleicht reicht das schon aus, um die Einstiegsschwelle soweit zu senken, dass sich mehr Entwickler für das WCF interessieren und wir im Endeffekt alle davon profitieren können.


    WoltLab selbst habe ich nicht kontaktiert. Ich hatte anfangs mal die Idee, bei WoltLab anzufragen, ob sie den Projekt Manager nicht aufkaufen möchten und dann komplett kostenfrei (auch für kommerzielle Entwickler) anbieten wollen. Als ich diese Idee in einem anderen Thema in den Raum gestellt habe, hat mir SoftCreatR hier aber eine recht deutlich Prognose gestellt, weswegen ich von einer (zeit-)aufwändigen Präsentation des Projekt Managers gegenüber WoltLab abgesehen und mich für eine schlichtere Präsentation im Pluginentwicklung Forum entschieden habe. Sollte WoltLab mir in irgendeiner Form entgegenkommen wollen, beispielsweise indem sie auf den Projekt Manager verweisen, sobald er veröffentlicht ist und fehlerfrei seine Dienste verrichtet, bin ich für jegliche Kooperation offen.

  • Da mittlerweile einige das Projekt beobachten und auf eine erste Beta Version warten, möchte ich in einer kurzen Zusammenfassung beschreiben, was sich die letzten drei Monate alles getan hat:


    Aufgaben bis zur ersten Beta Version


    1. Versionierung fertigstellen: Aktuell können bereits Paketversionen erstellt und zwischen verschiedenen Versionen gewechselt werden. Es fehlt noch der "Merge" Prozess, wie man ihn von Git und ähnlichem kennt - mit dem Unterschied, dass hier nicht nur Dateien, sondern auch die Daten aus den PIPs und Datenbankmodifikationen beim Merge erfasst werden müssen.


    2. Alle Funktionen ein mal testen, um letzte offensichtliche Fehler zu beheben.


    3. Tutorials zu den verschiedenen Funktionen vorbereiten.


    4. Zeitlich sollte ich am Plan mit einer Veröffentlichung im 1. Quartal, also noch im März, festhalten können, wobei es nur eine Beta Version sein wird, welche aber schon ziemlich stabil läuft.


    Änderungen an der geplanten Lizenzierung und den Nutzungskosten


    1. Die vollständige Entwicklung von Paketen mit dem Projekt Manager ist nicht vollständig kostenfrei.


    2. Der Projekt Manager wird in zwei Pakete geteilt: Zum einen gibt es den kostenfreien "Projekt Manager", welcher für das Anlegen und Entwickeln der Pakete zuständig ist. Man kann sich also den vollen Funktionsumfang kostenfrei anschauen. Zum anderen gibt es den "Projekt Manager: Exporter", welcher die Pakete dann mit den passenden Installations- und Updateanweisungen packt. Sollte man mit den Funktionen des Projekt Managers zufrieden sein und diesen als Unterstützung für die Entwicklung von Plugins nutzen wollen, erwirbt man entsprechend den Exporter.


    3. Der Exporter wird für nicht-kommerzielle Nutzung rund 20 - 40 Euro kosten. Werden Pakete, welche mit dem Exporter exportiert wurden, kommerziell vertrieben, ist der Erwerb einer zusätzlichen Lizenz notwendig.



    Für eure Fragen oder Vorschläge steht ich gerne zur Verfügung :)

  • Fragen:


    1.) Wie sieht die Timeline aus? Wann kann man mit einem finalen Produkt rechnen?
    2.) Wird das Ganze auch WCF 2.2- / WBB 4.2-kompatibel sein; d.h. auch weiterentwickelt werden?
    3.) Kann man bestehende Plugin-Entwicklungen / Plugins importieren?


    Grüße, CCFF

    Edited 2 times, last by CCFF ().

  • 1.) Wie sieht die Timeline aus? Wann kann man mit einem finalen Produkt rechnen?

    Geplant ist das zweite Quartal. Da ich aber von früheren Projekten weiß, dass es häufig länger dauert als geplant, sollte man im Falle, dass das Erscheinen des finalen Produkts wichtig ist, lieber vom dritten Quartal 2016 ausgehen. Es ist aber so, dass man je nach Umfang und Updatezyklus der eigenen Plugins, potentiell schon mit der Beta Version arbeiten kann. Meine zwei Plugins in WoltLabs Plugin-Store sind beispielsweise mit dem Projekt Manager entwickelt und exportiert. Das regelmäßige Erstellen von Backups von den eigenen Plugins ist, sowohl in der Beta als auch in der finalen Version, selbstverständlich.


    Bezüglich einer Timeline: Neben den oben genannten Punkten wird es neben den Tutorials auch eine Auflistung von ausstehenden Arbeiten geben. Dort werde ich dann im Detail darauf eingehen können, mit welcher der fehlenden Funktionen wann zu rechnen ist. Prinzipiell werden aber alle diese Funktionen noch im Rahmen der Beta Version integriert.


    2.) Wird das Ganze auch WCF 2.2- / WBB 4.2-kompatibel sein; d.h. auch weiterentwickelt werden?

    Das habe ich vor. Da ich selbst Plugins entwickle und eine Community mithilfe eines WBB betreibe, werde ich den Projekt Manager allein schon für die Eigennutzung für das Update kompatibel machen.


    3.) Kann man bestehende Plugin-Entwicklungen / Plugins importieren?

    Prinzipiell ist das jetzt schon möglich, bis auf eine Ausnahme, welche aber problemlos im weiteren Verlauf der Entwicklung noch eingebaut wird. Es fehlt noch die Übernahme der bereits vorhandenen Updateanweisungen. Geht es hingegen um ein Plugin, welches bisher nur in einer Version vorliegt und entsprechend nur eine Installationsanweisung enthält, funktioniert eine Integration in den Projekt Manager bereits jetzt.

  • Sehr cool und meiner Meinung gut angedacht mit der Lizenz. Bin schon sehr auf eine Beta-Version gespannt und werde versuchen, fleißig mit zu testen und Fehler/Besserungen mitzuteilen.

  • Ich strebe folgendes Modell an: Der Projekt Manager soll an sich kostenfrei erhältlich und nutzbar sein. Benutzt man den Projekt Manager aber kommerziell, um entweder Plugins zu verkaufen oder Plugins herzustellen, welche auf kommerziellen Plattformen benutzt werden, soll eine extra Lizenz erforderlich sein.

    Der Exporter wird für nicht-kommerzielle Nutzung rund 20 - 40 Euro kosten.

    Der Projekt Manager soll für nicht-kommerzielle Entwickler kostenfrei sein.

    Die vollständige Entwicklung von Paketen mit dem Projekt Manager ist nicht vollständig kostenfrei.


    Bei spitzfindiger Betrachtung der hervorgehobenen Texte stellt sich zwar heraus, dass Du Dir bereits in der Erstformulierung ein Hintertürchen offen gelassen hast, die anscheinend für nicht-kommerzielle Nutzung kostenfreie Verwendung doch noch gebührenpflichtig zu machen, aber dennoch nehme ich mir als einer, der wirklich bisher nie etwas für seine Pakete (die zugegebenermaßen von Anspruch und Aufwand auch nicht unbedingt an das heranreichen, was Du anbieten möchtest) verlangt hat, das Recht heraus, meine Enttäuschung über diese für mein Empfinden "Blendung" der potentiellen Verwender zum Ausdruck zu bringen.


    Anfangs habe ich mir gesagt: "Hut ab!", dass jemand so etwas umfangreiches und anspruchsvolles kostenfrei zur Verfügung stellen will!


    Angesichts der jetzt veröffentlichten "Konkretisierung" der ursprünglich gemachten Aussagen fühle ich mich schlicht und ergreifend von den anfangs getätigten Ankündigungen getäuscht.


    Sag mir bitte einen vernünftigen Grund dafür, dass ich Geld in etwas investieren sollte, damit ich anderen etwas kostenfrei überlassen kann.





    Gruß norse

  • Der Projekt Manager soll kostenfrei sein und der Exporter ist kostenpflichtig der benötigt wird um Plugins zu erstellen welche in einem WBB/WCF installiert werden.


    Angenommen, jemand möchte für ein WBB/WCF ein Plugin mittels Projekt Manager kostenlos erstellen, so besteht die Wahl lediglich darin den Projekt Manager (ein Entwicklungstool) in eine produktiven Forum zu installieren um dann das selbst erstellte Plugin Vorort nutzen zu können, oder aber doch den besagten Exporter kostenpflichtig zu erwerben.


    Schöner hätte ich eine Kostenpflicht auch nicht verstecken können, denn so oder so, bezahlen wird man dafür müssen. Es sei denn, man haut sich ein Entwicklungsplugin(oder Entwicklungsanwendung) mit in das WBB/WCF. Und das birgt auch Risiken.

  • @ramius Ich hätte an deinem Teil wirklich Interesse gehabt, aber solch eine Verschleierungstaktik (um dann doch Geld damit zu machen) ist unterste Schiene (ganz Unterste). Entweder man hält sich an die voraus gegangenen Mitteilung oder postet erst gar keine Angaben zum Preis und hampelt nicht mit Teils/Teils-Kostenlos/Kostenpflichtig herum.


    Wie @Serana es beschrieben hat, würde ich kein Entwicklungs-Plugin in mein Produktives Forum installieren, nur damit ich dann damit Plugins dort (nur dort) entwicklen und einsetzen kann. So ein Entwicklungs-Plugin gehört in einer nicht öffentlich zugängliches WBB/WCF-Umgebung. Das entwickelte Plugin sollte Exportiert werden und dann in das produktiv genutzte WBB/WCF zum Einsatz kommen. Alles andere ist - verzeihe mir die offenen Worte - Bockmist!


    Schöner hätte ich eine Kostenpflicht auch nicht verstecken können, denn so oder so, bezahlen wird man dafür müssen.

    :thumbup:

    proSidor - Wir haben die aktuellen Nachrichten der WoltLab-Szene!

  • @norse
    Ich hätte nicht erwartet, dass das solche Wellen schlägt. Ich habe zuvor nie versichert, dass er vollständig kostenlos wird, sondern nur gesagt, dass ich plane es kostenlos rauszubringen. Es tut mir leid, wenn man das nicht richtig verstanden hat und es bereits als Tatsache hingenommen hat. Das hatte im ursprünglichen Post auch nichts mit Hintertürchen offen lassen zu tun, sondern ich war mir einfach selbst noch keines Modells bewusst und habe eben noch geplant.


    Wieso ich auf dieses Modell mit dem kostenpflichtigen Exporter gekommen bin: Gerade um den potentiellen Entwicklern entgegen zu kommen. Sie müssen nicht die Katze im Sack kaufen, sondern können den vollen Funktionsumfang des Projekt Managers testen, können beliebig viele Plugins komplett entwickeln. Nachdem sie den Projekt Manager und die mit ihm einhergehende Erleichterung eingehend studieren konnten, können sie entscheiden, ob ihnen die Hilfestellung rund 30€ rum Wert ist.


    Sag mir bitte einen vernünftigen Grund dafür, dass ich Geld in etwas investieren sollte, damit ich anderen etwas kostenfrei überlassen kann.

    Die Logik aus deinem Satz erschließt sich mir nicht. Du entwickelst das kostenfreie Plugin doch nicht, weil du den Projekt Manager erworben hast, sondern aus anderen Gründen. Möchtest du es nun leichter haben, kannst du den Projekt Manager dafür nutzen. Ist dir die daraus gewonnene Erleichterung den Preis nicht wert, lässt du es und entwickelst ohne Projekt Manager.


    so besteht die Wahl lediglich darin den Projekt Manager (ein Entwicklungstool) in eine produktiven Forum zu installieren um dann das selbst erstellte Plugin Vorort nutzen zu können

    Bitte den Projekt Manager auf keinen Fall in einer produktiven Umgebung installieren. Ich habe zwar entsprechende Rechte angelegt, welche nach der Installation des Projekt Managers nur die Benutzergruppe der Adminstratoren haben, aber trotzdem ist das kein Plugin, welches man außerhalb der eigenen Entwicklungsumgebung installieren sollte. Es werden die Dateien der Plugins durch das Dateisystem kopiert, ein eigener Autoloader registriert, Cache Dateien verändert, die Datenbank in Teilen verändert. Das ist nichts für eine produktive Umgebung.


    Schöner hätte ich eine Kostenpflicht auch nicht verstecken können, denn so oder so, bezahlen wird man dafür müssen.

    Verstecken vor wem? Vor den Lesern hier? Wie ich bei norse bereits geschrieben hatte, habe ich zuvor nie konkrete Aussagen gemacht, sondern nur Möglichkeiten ausgelotet und hier um Hilfe gebeten. Falls du die späteren Entwickler meinst: Diesen wird natürlich von Anfang an klar gemacht, sollte sie den Projekt Manager nutzen wollen, wird später auch der kostenpflichtige Exporter notwendig sein.


    @ramius Ich hätte an deinem Teil wirklich Interesse gehabt, aber solch eine Verschleierungstaktik (um dann doch Geld damit zu machen) ist unterste Schiene (ganz Unterste). Entweder man hält sich an die voraus gegangenen Mitteilung oder postet erst gar keine Angaben zum Preis und hampelt nicht mit Teils/Teils-Kostenlos/Kostenpflichtig herum.

    Ganz langsam: Das Tool war noch nicht veröffentlicht, noch nicht mal in einer Beta. Ich habe keine festen Preise genannt, sondern nur gesagt, dass ich plane es kostenfrei zu veröffentlichen. Wie kann man hier von einer konkreten Ansage ausgehen? Und dann bei Änderungen empört sein? Der Projekt Manager ist auch nicht teilweise kostenpflichtig, sondern der Exporter ist vollständig kostenpflichtig, sodass man wie oben beschrieben sich alle Funktionen des Projekt Managers ohne Verpflichtungen in Ruhe anschauen und dann entscheiden kann.


    Wie @Serana es beschrieben hat, würde ich kein Entwicklungs-Plugin in mein Produktives Forum installieren, nur damit ich dann damit Plugins dort (nur dort) entwicklen und einsetzen kann.

    Natürlich installiert man den Projekt Manager nicht in einer produktiven Umgebung. Wo habe ich das erwähnt? Sowohl vor dem Download als auch in der Lizenz wird explizit darauf hingewiesen werden, dass dies nicht gemacht werden soll / darf.


    @all
    Ich verstehe, dass man gerne ein vollständig kostenloses Plugin gehabt hätte. Aber anscheinend ist das größte Problem an dieser Stelle, dass einigen einfach nicht der Unterschied zwischen Planung und konkreter Ankündigung klar war. Ich ziehe also für mich den Schluss daraus, hier nicht mehr bei meiner Planung nach Hilfe zu fragen, da dies offensichtlich mit konkreten Ankündigungen verwechselt und dann gegen einen verwendet wird.

  • Hallo ramius,


    super Projekt, erstmal ;)


    Ich ziehe also für mich den Schluss daraus, hier nicht mehr bei meiner Planung nach Hilfe zu fragen, da dies offensichtlich mit konkreten Ankündigungen verwechselt und dann gegen einen verwendet wird.

    Ich habe den Text gestern noch vor deiner Bearbeitung gelesen und da war überhaupt nicht klar, dass das lediglich einen Gedanke darstellen soll. Du hast ganz klar ausgedrückt, dass dein Paket für nicht-kommerzielle Zwecke gratis sein soll.


    Deine Angst ist wahrscheinlich, dass ein kommerzieller Entwickler dein Plugin nicht kaufen wird - berechtigt. Allerdings musst du auch betrachten, dass zumindest meiner Erfahrung nach, diesen Schritt kein professioneller Entwickler wagen würde, weil hier deine Schadensersatzansprüche viel zu hoch sind. Wenn man im kommerziellen Kontext mit Raubkopien arbeitet, gehen die Summen in den 4 stelligen Bereich über.


    Ich bin mal gespannt, wie sich das Paket auf die Entwicklungsgeschwindigkeit auswirkt. Ich vermute nämlich, dass man beispielsweise Sprachvariabeln in der XML File deutlich schneller schreiben kann, als im Browser (schnelles Copy-Paste der Zeile und Text eingeben. Bei dir müsste ich erst 2-3 Klicks tätigen und kann dann erst schreiben).

  • Ich habe den Text gestern noch vor deiner Bearbeitung gelesen

    Ich habe den Startbeitrag nie bearbeitet.




    Du hast ganz klar ausgedrückt, dass dein Paket für nicht-kommerzielle Zwecke gratis sein soll.

    Nein, ich habe geschrieben, was ich anstrebe, was meinem Wortverständnis nach keine feste Zusage ist, wie es am Ende aussehen wird. Vielleicht weicht hier mein Verständnis bezüglich der Formulierung einfach von anderen ab:

    Ich strebe folgendes Modell an: Der Projekt Manager soll an sich kostenfrei erhältlich und nutzbar sein.



    Ich bin mal gespannt, wie sich das Paket auf die Entwicklungsgeschwindigkeit auswirkt. Ich vermute nämlich, dass man beispielsweise Sprachvariabeln in der XML File deutlich schneller schreiben kann, als im Browser (schnelles Copy-Paste der Zeile und Text eingeben. Bei dir müsste ich erst 2-3 Klicks tätigen und kann dann erst schreiben).

    Sprachvariablen sind wohl ein Beispiel, wo einem nicht so viel Arbeit abgenommen wird, aber auch hier würde ich sagen, dass die Eingabe über entsprechend Formulare angenehmer ist als in XML Dateien. Allgemein gilt wohl für alle PIPs, dass es angenehmer sein dürfte, gerade für Einsteiger in die WCF Entwicklung, Formulare geboten zu bekommen, wo sie genau gesagt bekommen, welche Möglichkeiten man hat (ersetzt ein Stück weit auch die fehlende Dokumentation).


    Neben der Hilfe mit den PIPs sollte man aber nicht das viel wichtigere Vergessen: Die Installations- und vor allem Updateroutinen, welche automatisch generiert werden. Das ist die viel größere Arbeitserleichterung meiner Ansicht nach.


    Trotz alle dem fände ich es toll, wenn du dir einfach nochmal eine Meinung dazu bildest, sobald die Beta Version erhältlich ist. Ich denke es in der Praxis zu nutzen gibt einen viel besseren Eindruck als alles was ich hier schreiben kann. Ich bin gespannt, was du dann dazu sagst :)

    Edited once, last by ramius ().

  • Ich hatte das Gefühl, dass im Startbeitrag gestern noch weniger stand als heute, daher ging ich von einer Bearbeitung aus.



    aber auch hier würde ich sagen, dass die Eingabe über entsprechend Formulare angenehmer ist als in XML Dateien

    Hier fände ich eine Funktion, ähnlich wie in phpmyadmin passend: Man hat eine per JS erweiterbare Tabelle und kann mit einem Doppelklick auf den Text, inline den Text arbeiten, Werte verändern usw.
    In deinem Fall hättest du eine Tabelle mit 2-3 Einträgen: Variabel, Text (de, en). So benötige ich kein eigenes Formular zum Bearbeiten und wäre schneller.