Plugin zum Erstellen von Plugins

Der Copyright Hinweiß (den dein Tool ja auch sicher in die Paketbeschreibung einbaut) wäre vor allem ja für Woltlab Interessent. Lädt jemand ein kostenpflichtiges Plugin hoch und in der package.xml steht, ne ist nicht, dann kann Woltlab das Plugin gleich ablehnen. Zudem wird sich der Prüfer denken: "Hurra ein ramius Paket, ich kann mir die Arbeit sparen, bestimmte Dinge zu kontrollieren."

Das Problem an solchen Sicherheitsmechanismen ist, dass man sie meistens recht leicht umgehen kann (für dein Beispiel könnte man einfach nach dem Exportieren das .tar Archiv und die darin enthaltene package.xml öffnen und den Hinweis entfernen [aktuell baue ich übrigens gar keinen Hinweis ein]). Man muss sich dann letztendlich fragen, ob sich der Aufwand, eine unrechtmäßige Nutzung zu unterbinden, überhaupt rechnet oder man die Zeit lieber in die Weiterentwicklung investiert.

WoltLab wird den Kauf unter Garantie nicht in Erwägung ziehen. Wenn der Bedarf besteht, baut man das selbst, wobei ich auch keinen Bedarf für die Allgemeinheit sehe.

Daher wäre es m.M.n. das Naheliegenste, das für ein paar Pfennig im Store (oder sonstwo) anzubieten. So verdienst du dir etwas dazu, WoltLab verbaut das WCF nicht mit noch mehr - für den Otto-Normal-Communitybetreiber - mit Zeugs und du weißt deine Erweiterung beim gewünschten Clientele.

Quote from SoftCreatR

WoltLab wird den Kauf unter Garantie nicht in Erwägung ziehen. Wenn der Bedarf besteht, baut man das selbst, wobei ich auch keinen Bedarf für die Allgemeinheit sehe.

Was den ersten Teil betrifft, kann ich mir gut vorstellen, dass du recht hast beziehungsweise mache ich mir dahingehend wenig Hoffnung. Was den zweiten Teil bezüglich des Bedarfs für die (Entwickler) Allgemeinheit betrifft, ist dieser, zumindest nach dem was man im Ausblick WoltLab Community Framework 2.2 lesen konnte, ganz offensichtlich vorhanden. Denn durch die Nutzung eines solchen Tools wird die komplette Einarbeitung in das Paketsystem des WCF obsolet. Entsprechend bräuchte man dafür auch keine Dokumentation mehr, sondern könnte sich erst mal um eine Dokumentation bezüglich der Struktur und Programmierung mit dem WCF widmen (DatabaseObjects; Pages, Forms und Actions; Templates; JavaScript, Ajax; etc.).

hm, ich lese da ein wenig mit .. und auch ich, die gerne mal bissl rumbastelt, aber nur schafft, ihre Smilieplugins zu bauen, fände dies interessant..
ich kann mir aber ehrlich gesagt nicht vorstellen, dass das Team von woltlab darauf eingehen wird, denn ein jedes Paket, was offiziell zum Download angeboten wird, benötigt auch eine gewisse Pflege .. Support usw.. dann kommen wieder Leute, dies funktioniert nicht richtig, da ist eine Sprachvariable nicht korrekt formuliert, an jener Stelle ist ein Grammatikfehler und lauter Erbsenzählerei ... dies dann alles zu hüten, würde ja auch wieder dem woltlab-team Zeit kosten... die ihnen aufgrund des doch recht kleinen Teams einfach so schon fehlt ...

daher wärs wohl besser, du selbst kümmerst dich um dein Plugin .. und bietest es privat an ...
dabei find ich dies hier schon eigentlich ne gute Idee

Quote from veneanar

Die Community Edition
Kostenfrei. Voll Funktionsfähig. Setzt aber hinter bzw. neben das Coypright "erstellt mit ramius SuperPluginPackGedöns". Zudem verbietet deine Nutzungslizenz die Erstellung kommerzieller Plugins.

Die Professional Edition
Kostenpflichtig. Setzt keine Copyrightergänzung, kommerzielle Plugins erlaubt.

wobei ich dieses mit dem Copyright auch rausnehmen würde, das ist ein Schmarren.. wie du selbst schon sagst, das würde nur dein eigenes Ego stärken .. und so, wie ich das verstand, befindet sich das Plugin ja eh hauptsächlich im ACP und hat m.E. nach dann kein Copyright dazu im Frontend was verloren ...

allerdings find ich das gut, wenn du sagst, okay, wer damit kommerzielle Pakete bastelt, der kann auch was zahlen dafür !
wo ich dann dies aber auch streng sehen würde und sagen würde.. nicht nur, wer kommerzielle Pakete baut, sondern, alle, die ein kommerzielles Forum führen, haben sich eine Lizenz zu holen, egal, ob sie auch Gratispakete damit bauen, die sie auf ihrer kommerziellen Seite mit anbieten !

Quote from ramius

Natürlich setzt das ein gewisses Vertrauen voraus, dass zumindest ein Teil, welcher kommerzielle Plugins damit erstellt, auch die Lizenz kauft.

und exakt hier wirds wohl leider wieder haken:

a) wer will das kontrollieren
b) gibts ja leider immer wieder schwarze Schafe, die zwar Geld mit ihrer Seite verdienen wollen, aber selbst nix ausgeben möchten...
hat man damals ja schon beim Werbeplugin gesehen, welches Geld gekostet hat, dass die Leute dann nölten, obs da nix gratis gäbe ..

insgesamt sollte man jedenfalls auf beiden Seiten bedenken, dass so ein Plugin wirklich viel Pflege bedarf, dass es immer wieder User gibt, denen die Features nicht genug sind und sie immer mehr wollen .. und dass für sowas ein guter Support eine Grundvorrausetzung wäre, dass es auch wirklich viele Leute nutzen würden.. ohne Support ist das schönste, sinnvollste Plugin leider nicht sehr viel wert, wenn mans zwar nutzen kann, aber keiner hilft ..

Quote from ramius

Denn durch die Nutzung eines solchen Tools wird die komplette Einarbeitung in das Paketsystem des WCF obsolet. Entsprechend bräuchte man dafür auch keine Dokumentation mehr, sondern könnte sich erst mal um eine Dokumentation bezüglich der Struktur und Programmierung mit dem WCF widmen (DatabaseObjects; Pages, Forms und Actions; Templates; JavaScript, Ajax; etc.).

Wo wir wieder an dem Punkt wären, dass das nichts für die Allgemeinheit ist und Entwicklertools im WCF nichts zu suchen haben.

Gut, das wäre tatsächlich eine Möglichkeit. Aber wie gesagt - Ich bezweifle ganz stark, dass WoltLab da irgendwas macht.

Quote from SoftCreatR

Wo wir wieder an dem Punkt wären, dass das nichts für die Allgemeinheit ist und Entwicklertools im WCF nichts zu suchen haben.

Nur weil es dann offiziell von WoltLab wäre, müssten man es ja nicht ins WCF integrieren, sondern könnte es weiterhin als optionales Paket anbieten. (Edit: zu langsam)
Aber gerade der Punkt von @Bibini bezüglich der Pflege des Plugins macht ein Aufkaufen Seitens WoltLab vermutlich unmöglich. Ich habe zwar versucht mich an viele der Codingstandards von WoltLab zu halten, aber hier und da gibt es sicherlich Eigenheiten meines Programmierstils. Mit mittlerweile knapp 25k Zeilen würde ich auch niemanden zumuten wollen sich in den Code einzuarbeiten.

Letztendlich muss ich jetzt sowieso erst mal den Feinschliff fertig bekommen und meine Community auf das WCF2 umziehen. Dafür habe ich letztendlich den Projekt Manager gemacht: Ich war es Leid die Plugins, welche ich für meine Community geschrieben habe, von Hand packen und manuell die XML Dateien schreiben zu müssen.

Quote from ramius

... der Punkt von @Bibini bezüglich der Pflege des Plugins macht ein Aufkaufen Seitens WoltLab vermutlich unmöglich.

Mit etwas gutem Willen geht auch das: Woltlab könnte dich als externen Entwickler beauftragen die Pflege zu übernehmen.

Ich spreche mal als der 0/8/15 Entwickler:
Nein, mich reizt so ein Plugin nicht. Wie @SoftCreatR sagt, haben wir alle unseren eigenen Workflow. Bei dm einem wirds besser funktionieren, bei dem anderen eher mager
Den riesigen Nachteil den ich bei deinem Plugin sehe ist, dass du vergisst, dass jeder halbwegs ernshafte Entwickler auf github/bitbucket und Co baut. Wo hätte ich die Möglichkeit bei dir? Ich würde (Sorry!), keinen Pfifferling dafür investieren, nur das dein Programm die XML Dateien, die sowieso der geringste Aufwand in einem Plugin sind, selbstständig schreibt. Aber selbst deinem Programm muss ich doch irgendwie sagen, welche Datei zu welchem PiP gehört etc. Und wieso dann nicht direkt schreiben?
Alles andere geschieht bei mir innerhalb von 4 Klicks (1. Klick Ordner auswählen, 2. Klick Ordner als Paket packen, 3. und 4. Klick Repro Ordner mit dem wcf Installationsordner abgleichen. Fertig ist das "Umständliche" Entwickeln mit dem wcf.

Wofür benötige ich dein Plugin? oO

Quote from Marcel Beckers

nur das dein Programm die XML Dateien, die sowieso der geringste Aufwand in einem Plugin sind

Naja, bis auf das Finden von Sprachvariablen, aber dafür habe ich mir vor ein paar Monaten ein kleines Tool (Java-basierend) geschrieben.

Quote from Marcel Beckers

Aber selbst deinem Programm muss ich doch irgendwie sagen, welche Datei zu welchem PiP gehört etc. Und wieso dann nicht direkt schreiben?

Was ich mich hier auch frage: Was passiert, wenn man selbst PIPs mitliefert? Wird das unterstützt, oder sagt er dann, dass er keine Lust hat?

Ich schließe mich hier auch @Marcel Beckers an.
Zum Einen ist die Anbindung an GitHub (oder einen anderen git-Anbieter) essentiell für eine vernünftige und vorausschauende Entwicklung sowie die Sicherung der aktuellen Entwicklungsstände.
Zum Anderen sind die meisten Entwickler ihre IDE gewohnt und müssten sich erst umgewöhnen. Selbst danach ist nicht sicher, ob der gleiche Workflow erreicht werden kann.
Abgesehen davon hat der Entwickler dann (sollte es alles automatisiert laufen) keinen Überblick, was passiert und wieso etwas wo steht. Macht man alles manuell, denkt man sich etwas dabei und die Wahrscheinlichkeit, dass man seine Gedanken später nachvollziehen kann, dürfte höher sein.

Ich würde mir das Teil zwar mal ansehen und ausprobieren, aber nie ernsthaft für größere Projekte verwenden.

Wo habe ich denn geschrieben, dass mein Plugin die IDE oder Git ersetzt? Die Wahl der IDE und die Nutzung eine Repositories ist nach wie vor problemlos möglich. Der Workflow mit meinem Plugin sieht wie folgt aus (davon ausgehend, dass eine lokale Installation von WCF/WBB und dem Projekt Manager vorliegen):

1. Man erstellt im ACP über ein Formular ein neues Package. Dieses wird auch richtig erstellt, sodass man quasi ein leeres Package installiert hat.
2. Man legt über die Formulare, welche der Projekt Manager bereitstellt, für alle Standard PIPs die entsprechenden Einträge an (Optionen, Menüs, Sprachvariablen, etc.).
3. Ebenfalls legt man mithilfe des Projekt Managers die Datenbank Definition an.
4. In der IDE eurer Wahl (einschließlich Nutzung von Git und ähnlichem) programmiert ihr die Logik. Natürlich können währenddessen die Punkte 2 und 3 beliebig wiederholt bzw. bereits angelegte Einträge bearbeitet werden.
5. Ihr könnt den Code live testen, da alle Optionen, Menüeinträge, Datenbanktabellen, etc. vorhanden sind.
6. Sobald ihr mit eurer Version des Pakets fertig seid, drückt ihr im ACP auf exportieren und bekommt das fertige Archiv.
7. Ihr legt eine neue Version des Pakets an und alle Änderungen die ihre jetzt an Optionen, Menüs, der Datenbank oder den Dateien vornehmt werden verfolgt, sodass korrekte Updateroutinen beim Exportieren der neuen Version angelegt werden.

Wo genau schränkt euch dieser Workflow ein? Vielleicht kann ich an den entsprechenden Stellen dann nachbessern.

Ab ich will natürlich niemanden zwingen, das ganze zu benutzen. Es richtet sich hauptsächlich an Einsteiger, welche noch nichts mit dem WCF zu tun hatten. Erklärt diesen mal, um den entwickelten Code zu testen müssen sie entweder das Paket immer neu packen und installieren oder die Einträge manuell in der Datenbank anlegen. Die werden große Augen machen und sich ein anderes Framework suchen.

Edit: Zum Thema eigene PIPs - ich kann natürlich nicht vorhersagen, was spezielle PIPs für Eingaben ermöglichen. Deswegen ist der Projekt Manager erweiterbar, sodass man ihn mit einem Plugin um eine Eingabemaske und den Export der Daten eurer PIPs erweitern kann.

Quote from ramius

4. In der IDE eurer Wahl (einschließlich Nutzung von Git und ähnlichem) programmiert ihr die Logik.

Interessehalber: Wie erkennt dein Plugin die Dateien ?

Quote from Morik

Interessehalber: Wie erkennt dein Plugin die Dateien ?

Dafür gibt es zwei Möglichkeiten:
1. Falls man die Dateien direkt im WCF Verzeichnis (bzw. im Verzeichnis einer Endanwendung) anlegt, zeigt der Projekt Manager alle Dateien an, welche nicht in der wcf1_package_installation_file_log Tabelle eingetragen sind. Man muss dann die Dateien, welche zum eigenen Paket gehören auswählen oder kann auch alle auf ein mal (sollte man nur an dem einen Paket gearbeitet haben) dem eigenen Paket hinzufügen lassen. Es werden dann für die gewählten Dateien Einträge in der file_log Tabelle angelegt.
2. Ich habe eine Erweiterung für den Projekt Manager erstellt, welche es erlaubt, Pakete auch in eigenen Verzeichnissen außerhalb des WCF (bzw. der Endanwendung) zu entwickeln. Die Erweiterung sorgt dafür, dass die Dateien trotzdem im WCF verfügbar sind. Da die Dateien jetzt pro Paket in einem eigenen Verzeichnis sind, ist eine manuelle Zuordnung durch den Entwickler nicht mehr notwendig. Ich selbst nutze diese Erweiterung, da ich ungern in Ordnern des WCF nach meinen Dateien suche (beispielsweise eine Form zwischen den 25 Forms des WCF).

Klingt schon mal interesannt, werde ich auf jeden Fall mal testen wenn es denn verfügbar wird

Quote from ramius

zeigt der Projekt Manager alle Dateien an, welche nicht in der wcf1_package_installation_file_log Tabelle eingetragen sind

Das eskaliert aber, sobald man Attachments oder Bilder oder Dateien hochgeladen hat oder schließt du das irgendwie aus?

Naja, der Workflow wäre insofern anders, als, dass man das komplette WCF als Projekt in der IDE hätte oder die Dateien per Dateisystem öffnen muss, was ich persönlich als extrem umständlich empfinde gegenüber einem Source-Tree in der ID.
Oder denke ich hier falsch?

Quote from MysteryCode

Das eskaliert aber, sobald man Attachments oder Bilder oder Dateien hochgeladen hat oder schließt du das irgendwie aus?

Frei heraus weiß ich gerade nicht mehr, welche Dateien ausgeschlossen werden, aber prinzipiell ja, Attachments werden natürlich nicht zur Auswahl gestellt geschweige denn in die file_log Tabelle eingetragen (was in der file_log Tabelle steht, wird nämlich später beim exportieren über das Files-PIP installiert und die Attachments gehören für gewöhnlich nicht zum Paket dazu). Bilder hingegen (sprich der Inhalt des images Ordner) wird ebenfalls durchsucht, da man mit dem Paket durchaus auch Bilder installieren kann. Der Unterordner avatars wird aber ausgeschlossen.

Quote from MysteryCode

Naja, der Workflow wäre insofern anders, als, dass man das komplette WCF als Projekt in der IDE hätte oder die Dateien per Dateisystem öffnen muss, was ich persönlich als extrem umständlich empfinde gegenüber einem Source-Tree in der ID.
Oder denke ich hier falsch?

Ich kann es mir gerade nicht richtig vorstellen, was du meinst, aber ich entwickle ja bereits mit dem Projekt Manager und mein Aufbau sieht wie folgt aus: Ich habe eine IDE und in ihr meine lokale WCF Installation als Projekt angelegt. Alle Pakete, welche ich erstellt habe, sind eigene Projekte in der IDE. In diesen Projekten habe ich das WCF Projekt in den Class Path eingefügt, damit ich zum einen bei der Verwendung von WCF Klassen die Autovervollständigung habe (zusätzlich werden automatisch use-Statements eingefügt) und zum anderen auch per Strg+Klick in die Klasse springen kann. Nach diesem Sprung befinde ich mich in der Datei im WCF Projekt, welche auch beim Aufruf der lokalen Installation im Browser verwendet wird. Daher kann ich dort direkt Debug Anweisungen reinschreiben (beispielsweise kurz mal ein print_r($x); exit;) und mir das Ergebnis im Browser ausgeben lassen. Ins Dateisystem muss ich prinzipiell nie.
Falls ich dich falsch verstanden habe, es nach meiner Erklärung deinem Workflow widerspricht oder noch immer nicht ganz klar ist, wie ich das meine, sag hier einfach nochmal kurz Bescheid.