Diskussion:Liste von Dependency Injection Frameworks

Kategorie

Hilfsweise unter Programmiersprache eingeordnet, bitte prüfen und ggf. ändern šùþërmØhî (Diskussion) 10:27, 4. Jan. 2013 (CET)

done --Sebastian.Dietrich ✉ 10:52, 4. Jan. 2013 (CET)

Links

This page is clearly advertising for 1 framework, (there is only 1 link with visible title, and is a php related (and a minor one)). For equality all other frameworks should have links, I tried to add a few and was coming back now to provide all missing links, however seems the authors already rolled back my change, should I propose the page for deletion instead? 93.51.34.38 17:02, 17. Mai 2016 (CEST)

do not add external links, instead write the missing entries and link to them. --Sebastian.Dietrich ✉

Google Dagger

The probably most used Java DI framework Google Dagger is missing, i'll add it. NyxCode (Diskussion) 16:05, 1. Feb. 2017 (CET)

Please write a wikipedia article on google dagger as well. There you can add usage statistics which should be available if it is "the most used Java DI framework". --Sebastian.Dietrich ✉ 20:36, 2. Feb. 2017 (CET)

Belege fehlen

1. Manche Frameworks sind überhaupt nicht in ihrer Existenz belegt. 2. Bei multifunktionalen Frameworks ist nicht belegt, dass diese auch Dependency Injection unterstützen. zur Info: Ich habe ganz gründlich gesucht und selber keine Belege gefunden. --TheRandomIP (Diskussion) 21:02, 18. Aug. 2020 (CEST)

@Sebastian.Dietrich: Bevor du dir vergebene Mühe machst, ein Beleg muss grundsätzlich die Anforderungen WP:Q erfüllen, also zuverlässig sein. Eine Webseite eines angeblichen Herstellers ist kein reputabler Beleg, da im Internet jeder Hinz und Kunz eine Webseite mit einem angeblichen Produkt erstellen könnte obwohl es in Wahrheit keines ist, sondern z.B. ein Fake, eine Abofalle, Plagiat, Virus etc. Hier gilt dann auch klar WP:KTF was noch einmal betont dass ein Beleg eine Sekundärliteratur sein muss, also eine Quelle von einer dritten Organisation (Fachmagazin, Presse, Wissenschaftliche Veröffentlichung) die den Artikelinhalt belegt und man nicht einfach die ursprüngliche Quelle verwenden darf. --TheRandomIP (Diskussion) 18:06, 19. Aug. 2020 (CEST)

@TheRandomIP: Anscheinend hast du es wirklich darauf abgesehen hier alles kurz und klein zu schlagen. Den LA nach deinen Löschungen hast zurückgezogen, aber jetzt stellst ein Ultimatum und drohst alles zu löschen, was nicht perfekt belegt ist. Klarer Fall von WP:BNS

Also ignoriere ich mal dein Ultimatum und werde die Dinge langsam und gründlich belegen. Das kann schon Monate dauern, so lange wirst du warten können und die Wikipedia wird das auch verkraften. --Sebastian.Dietrich ✉ 19:12, 19. Aug. 2020 (CEST)

Diese Regel wende ich überall an, nicht nur hier, denn es sind die offiziellen Regeln der Wikipedia! Wenn du es drauf ankommen lassen willst, gerne. --TheRandomIP (Diskussion) 19:13, 19. Aug. 2020 (CEST)

Lies mal WP:Belege#Fehlende_Belege - an diese offizielle Regel der Wikipedia hältst du dich nicht. --Sebastian.Dietrich ✉ 19:17, 19. Aug. 2020 (CEST)

Doch, hiermit über diese Disk habe ich die fehlenden Belege ja angemahnt. --TheRandomIP (Diskussion) 19:22, 19. Aug. 2020 (CEST)

Aber erst nachdem du Dinge gelöscht hast. Ich meine aber nicht das Papperl. Ich meine den Absatz "Unbelegte Aussagen können und sollten sofort aus einem Artikel entfernt werden, wenn sie Schaden anrichten können (etwa Negatives zu einer noch lebenden Person – WP:BIO beachten! – oder dubiose Aussagen in medizinischen Artikeln). Die Löschung sollte im Bearbeitungskommentar oder auf der Diskussionsseite kommentiert werden." - keine der durch dich entfernten unbelegten Aussagen richten Schaden an - also entferne sie nicht.

Das Papperl ist ja jetzt gesetzt und allen ist klar dass vieles in dieser Liste nicht belegt ist. Die Belege werden nachgebracht und inzwischen ist die Liste für die Leser, die für ihre Programmiersprache nach DI-Frameworks suchen sehr hilfreich. --Sebastian.Dietrich ✉ 19:27, 19. Aug. 2020 (CEST)

Vielleicht verbirgt sich hinter dem ein oder anderen angeblichen Framework ja ein Computervirus, ein trojanisches Pferd, dann wäre es tatsächlich gefährlich... --TheRandomIP (Diskussion) 19:30, 19. Aug. 2020 (CEST)

Das ist aber bei OS-Frameworks extrem weit hergeholt - also eine rein hypothetische Gefahr. Für hypothetische Gefahren sind die Regeln nicht gemacht. --Sebastian.Dietrich ✉ 21:43, 19. Aug. 2020 (CEST)

Da müssen Belege rein! Wenn du keine Lust hast für Belege, fliegen die Einträge halt raus. Ich habe durchaus mal selber recherchiert, aber man findet kaum sinnvolle Ergebnisse. Irgendwelche Links auf github, Threads auf Reddit, irgendwelche Blogs von Privatpersonen usw. (alles keine gültigen Belege) Für die ActionScript-Frameworks findet man das hier noch: [1] aber vieles sind tote Links, und da steht auch nicht ob das wirklich "Dependency Injection Frameworks" sind. Das alles ist nur mit sehr viel Rechereaufwand zu bestätigen, damit hast du Belege zu nennen, die WP:Q erfüllen. So einfach ist das. Wie gesagt, in einem Monat schaue ich rein, und dann sind hier hoffentlich ein paar mehr Belege... --TheRandomIP (Diskussion) 10:36, 26. Aug. 2020 (CEST)

Hör bitte endlich auf Drohungen auszusprechen. Lies dir bitte die Infos hinsichtlich deiner Sperre durch, dann wirst erkennen, dass deine Drohungen leere Worte sind. --Sebastian.Dietrich ✉ 14:37, 27. Aug. 2020 (CEST)

Gehen wir doch mal die Checkliste durch:

• Selbst Belege suchen. Keine gefunden?  Ja (wie oben dargestellt)
• Dann Diskussion  Ja
• Baustein Frist  Ja
• dann immer noch Unbelegtes entfernen. (demnächst)

Hier läuft nun also alles nach den Vorgaben. --TheRandomIP (Diskussion) 15:06, 27. Aug. 2020 (CEST)

P.S. Habe immerhin noch das hier gefunden: [2] Das kann ein paar Einträge retten. --TheRandomIP (Diskussion) 10:55, 28. Aug. 2020 (CEST)

zurückrück Die Checkliste ist aber keine Vorgabe, sondern deine persönliche Verkürzung der WP:Belege:Fehlende Belege. Ich lese aber nirgendwo, dass es Vorgaben gäbe zum Baustein eine Frist dazuzuschreiben oder Unbelegtes zu entfernen. Aber auf jeden Fall danke das du den Punkt 1 selbst etwas entschärft hast (hoffentlich sagst nicht später, dass die von dir gefundenen Belege keine gültigen sind). --Sebastian.Dietrich ✉ 11:31, 29. Aug. 2020 (CEST) P.S. Die Liste hab ich 2013 von Dependency Injection hierher kopiert, da sie den Artikel schlechter lesbar gemacht hat. D.h. viele der Frameworks haben u.U. eh nie eine Marktreife oder halbwegs wahrnehmbare Community erhalten - die gehören mMn gelöscht. Was aber immer noch existiert (und gewartet wird) und auch eine größere Community hat sollte mMn bestehen bleiben - auch wenn es keine unabhängigen Infos dazu gibt. "unabhängige" Infos zu OS-Frameworks (inkl. Infos über die Community / Wartung) findet man übrigens bei https://www.openhub.net/ --Sebastian.Dietrich ✉ 11:36, 29. Aug. 2020 (CEST)

Nichts anderes sage ich doch. Frameworks, die "nie eine Marktreife oder halbwegs wahrnehmbare Community erhalten" haben, sind für die Wikipedia nicht geeignet. Danke für den Link, das wäre ein Anhaltspunkt. Natürlich sehe ich die von mir gefundenen Belege als gültig ein. Sie stammen von einer dritten Instanz (nicht dem Autor selbst), sie Belegen eine minimale Wahrnehmung nach außen. Mehr will ich gar nicht darstellen. --TheRandomIP (Diskussion) 11:43, 29. Aug. 2020 (CEST)

Noch zu der Fristsetzung. In der Vergangenheit gab es oft die Rückmeldung, bei dem Baustein würde man gar nicht sehen, wann er eingesetzt wurde und was dieses "Angaben ohne ausreichenden Beleg könnten demnächst entfernt werden." genau bedeuten soll. Ich versuche daher einerseits, ein ungefähres Datum der Einfügung des Bausteins zu nennen (ähnlich wie es in der enWP Standard ist) und andererseits das "demnächst" zu konkretisieren, was ich denke, was ein angemessener Zeitraum wäre. Oftmals wird den Bausteinsetzern vorgeworfen, einfach nur den Baustein einzufügen und sich dann nicht mehr darum zu kümmern, dann steht der Baustein jahrelang und niemand weiß mehr was das Problem war. Ich versuche daher, den Prozess von Anfang bis Ende zu begleiten. Von Erkennung des Belegmangels bis hin zur finalen Entfernung nicht belegbarer Inhalte. --TheRandomIP (Diskussion) 12:14, 29. Aug. 2020 (CEST)

@Valanagut: Kannst du dich bitte mal ausgehend von dieser Diskussion äußern, inwiefern deine neu eingefügten Belege eine zumindest minimale Außenwahrnehmung der Einträge belegen? Es war hier gefordert, dass Frameworks, die "nie eine Marktreife oder halbwegs wahrnehmbare Community erhalten" haben, hier nicht hin gehören. Indem du bloß Hersteller-Websites hier einfügt, die auf eine 404-Seite leiten (Beispiel) sehe ich nicht, wie das hilfreich ist. --TheRandomIP (Diskussion) 15:54, 29. Aug. 2020 (CEST)

Am besten untersuchst Du Deine aufgerufene URL nochmal auf Tippfehler, die Seite hat Status 200. --77.116.111.138 16:01, 29. Aug. 2020 (CEST)

Für mich ist jetzt entgültig klar, das du nur auf Streit aus bist. die URL ist gültig. Deine Anforderungen an Belege sind an den Haaren herbeigezogen. Symfony ist ein sehr weit verbreitetes Framework. Zend und Laravel ebenfalls. Hier ist die Relevanz der Frameworks nicht zu belegen sondern das sie Inversion of Control, Dependency Injection als eines ihrer Merkmale aufweisen. Um was geht es dir. Vergraulen von Mitarbeitern? ไม่เป็นไร (Valanagut) (Diskussion) 16:09, 29. Aug. 2020 (CEST)

Danke für den Hinweis, habe ich selber gemerkt dass der Link doch geht, ändert aber nix daran, dass es bloß Produkt-Websites von unbekannten Herstellern sind, also weder belegen, ob das Produkt überhaupt eine gewisse (Markt)reife erhalten hat, noch ob es überhaupt ein Mensch da draußen benutzt hat. Ihr verweist doch immer alle auf eure IT-Kompetenz. Jeder Hinz und Kunz kann sich eine Webseite zusammenklicken und dort irgend ein Produkt bewerben. Vielleicht hat der Autor es nie geschafft, eine wirklich stabile, lauffähige Version seines Produktes herzustellen, das auch von Außenstehenden als "Dependency Injection Framework" identifiziert werden würde. Gerade der Open Source-Bereich ist doch durchsät mit angekündigten, gestarteten Projekten, die aber nie irgendwas geschafft haben. Dennoch hatten diese Projekte meist eine Website. Es geht hier einfach darum, wie wir uns hier als Enzyklopädie verstehen. Einfach irgendwas reinschreiben ohne Prüfung, ohne Kontrolle, da kommt das bei raus... Prima. Dann doch lieber mit Kontrolle und Nachprüfbarkeit, dafür halt ein paar weniger Einträge. --TheRandomIP (Diskussion) 16:10, 29. Aug. 2020 (CEST)

zurückrück (hab das dazwischen nicht gelesen)

Nein - du sagtest bislang schon was anderes. Nämlich das alles unbelegtes rausfliegt. Da gings dir nicht um Marktreife oder wahrnehmbare Community, sondern nur um (reputabel) belegt oder nicht belegt. Das ist schon was anderes.

Lies dir bitte mal das durch, was du beim Papperl geschrieben hast: "1. Manche Frameworks sind überhaupt nicht in ihrer Existenz belegt. 2. Andere Frameworks sind nicht durch reputable Sekundärliteratur belegt 3. Bei multifunktionalen Frameworks ist nicht belegt, dass diese auch Dependency Injection unterstützen." Du hast jetzt an 1. gearbeitet, aber weder 2. noch 3. ist durch deine Belege sichergestellt. Darum fürchte ich, dass du in Zukunft vielleicht sogar von dir Belegtes wieder löschst.

Das das Papperl verbesserungswürdig ist, mag schon stimmen. mMn dient es aber nicht den Autoren, damit sie wissen was sie noch brav tun sollen, sondern dem Leser, dass er weiß, dass hier Unbelegtes und somit potentiell Unwahres steht. Darum sind mMn deine Forderungen (wann wurde der Baustein eingefügt, bis wann muss der Autor handeln) kontraproduktiv.

Mein Fazit: Ich denke du hättest gerne eine ordentlich aufgeräumte Wikipedia. Das hätten vermutlich viele Autoren und auch Leser gerne. Aber leider ist das Wissen per se nicht aufgeräumt (z.B. etabliert es sich erst sukzessive, und wird auch nur sukzessive gesammelt) und zumindest bei neueren Themen wie IT-Frameworks niemals aktuell korrekt. In der Wikipedia ist daher Geduld ein extrem wichtige Eigenschaft. Auch wenn was jahrelang unbelegt ist, so wird es doch meist langsam gepflegt und besser und besser. Also würde ich dir folgendes raten: Übe dich in Geduld und Mut zur Lücke - ist auch in beinahe allen anderen Lebensbereichen (Politik, Gesellschaft, Psychologie, ...) sinnvoll. Einen Marathon schafft man auch nicht mit Sprinten bzw. Perfektionierung seiner Muskelkoordination. Wenn dir Belege so wichtig sind, dann könntest deine Energien (und die hast du massig - was toll ist) konstruktiv in die Belegung eines/weniger Artikel deines Interessensgebietes reinstecken. Da lernst auch ungemein selbst zu dem Gebiet dazu. --Sebastian.Dietrich ✉ 16:13, 29. Aug. 2020 (CEST)

Für @77.116.111.138: Es ist das gleiche wie mit dem Anwalt, der behauptete, er könne erkennen welche Vereine gegen die DSGVO verstoßen und das ohne Beleg, ohne Nachprüfung, in die Artikel der Vereine schreiben. Der Anwalt war sich seiner sehr sicher, hielt es für trivial wie "die Sonne geht im Osten auf". Ich habe widersprochen, du auch, weil wir keine Anwälte sind. So ist es nun auch hier: Du bist dir deiner Sache sehr sicher, weil du dich als Experten siehst. Du realisiert aber nicht, dass du total durch deine Fachkenntnis verzerrt bist um zu erkennen, was trivial ist und was man belegen sollte. Würde ich jetzt nicht darauf dringen, dass Belege gefunden werden, würde irgendjemand in 10 Jahren draufschauen und könnte das dann noch weniger nachvollziehen, hätte vielleicht noch viel mehr Erfolg darin, alles kahlzuschlagen. Es geht darum, jetzt noch möglichst viele Belege zu finden, solange diejenigen wie Sebastian.Dietrich noch anwesend sind. In 10 Jahren ist vielleicht niemand mehr da der einem Kahlschalg widerspricht und auch niemand mehr, der Belege für viele teilweise eingestellte aber dennoch vielleicht historisch relevante Einträge finden kann. Ich sage daher immer, bitte gebt Belege an auch wenn ihr euch eurer Sache sehr sicher seid. Das hilft, dass auch Außenstehende wie zukünftige Generationen das erkennen und eure Ergänzungen die Zeiten überdauern!

@Sebastian.Dietrich: Dinge, die sich schnell ändern, die nicht belegt werden können, sind schlicht nicht für eine Enzyklopädie geeignet. Da würde ich eher sagen, muss der Autor geduldig sein, bis die Einträge durch Sekundärliteratur nachgewiesen sind. Wie willst du denn sonst eine Enzyklopädie aufbauen? So kann ja jeder bei Dissens immer behaupten, musst halt warten, bis das belegt ist, im Moment gibt es nur noch keine Belege etc. Der nächste kommt und sagt, die Erde sei flach und es wird bestimmt jemand in Zukunft geben, der das beweist, und schreibt das dann in die Wikipedia, und er hätte formal recht weil wir hier auch nicht anders gehandelt haben. Prinzipien sind wichtig. Ich sehe nicht, wieso die Wikipedia ihre Prinzipien opfern sollte nur um so eine Liste unbedeutender Programme möglichst vollzustopfen. Da wiegt mir der Verlust der Prinzipien deutlich schwerer. Im übrigen halte ich codeguru.com sowie cplusplus Reference für geeignete Belege! Insbesondere cplusplus Reference, das ist die Anlaufstelle für alle C -Programmierer schlechthin. Sollte man als IT-Experte eigentlich wissen. (und es belegt auch Punkt 3, alle Belege sprechen explizit von "Dependency Injection", danach habe ich die Belege ja ausgewählt) --TheRandomIP (Diskussion) 16:28, 29. Aug. 2020 (CEST)

Wir haben hier auch archivarische Funktion. Auch Programme/Frameworks, die einmal relevant waren (und vielleicht seinerzeit als selbstverständlich angesehen und daher nicht explizit belegt) sollen erhalten bleiben. Dein (für ITler in der Tat schmerzhafter) Kahlschlag querfeldein in allen IT-Bereichen der Wikipedia fegt all das hinweg. U.a. daran krankt Deine ganze Argumentation, aber ich habe nicht vor, die Diskussion auf VM hier auszulagern oder fortzuführen. --77.116.111.138 17:03, 29. Aug. 2020 (CEST)

Noch einmal. Es muss hier nicht belegt werden das Symfony relevant ist, dafür gibt es den Artikel Symfony. Und was hat das Ganze mit einem Anwalt und DSGVO zu tun? Das hier ist nur eine Liste von Frameworks die Inversion of Control Funktionalität aufweisen. Ich kann deine Beweggründe nicht verstehen. Ich habe mehrere Links gesetzt nicht nur vom Hersteller SensioLabs. Was für Quellen willst du eigentlich? Nochmal, mir sehen deine Aktionen mehr nach Gängelung der Autoren aus! Du brauchst hier auf nichts dringen! Sebastian.Dietrich hat vollkommen recht! ไม่เป็นไร (Valanagut) (Diskussion) 17:07, 29. Aug. 2020 (CEST)

@77.116.111.138: Genau deswegen brauchen wir Belege. Unbelegtes Wissen ist nur für die aktuelle Generation von Nutzen, die es bestätigen kann. Zukünftige Generationen werden schulterzuckend vor dem Artikel sitzen und nicht wissen, was echt und was bloß ausgedacht ist.

Und noch an Sebastian.Dietrich, weil er meine Quellen angezweifelt hat. Rezeption Codeguru: [3], Rezeption CPlusPlus.com: [4] Das bestätigt meiner Ansicht nach, dass meine angegebenen Quellen zuverlässig sind und somit alle 3 Punkte aus dem Baustein erfüllt sind. Bitte höre auf, mir irgendwelche finsteren Absichten vorzuwerfen.

@Valanagut: Natürlich, ein eigener Artikel belegt natürlich den Listeneintrag, ich habe nie einen Listeneintrag angezweifelt mit eigenen Artikel. Listeneinträge ohne Artikel müssen aber durch Belege nachgewiesen werden. Belege, die gut genug sind für die Wikipedia. Die Hersteller-Seite eines unbekannten Herstellers reicht nicht aus. Die Hersteller-Seite eines relevanten und bekannten Herstellers dagegen würde ausreichen. Um die Sache mit dem Anwalt ging es hier: Diskussion:Mediziner und Wissenschaftler für Gesundheit, Freiheit und Demokratie Ich halte unseren Fall hier für dasselbe in grün. Irgendwelche Wikipedianer geben sich als Experten aus und sind der Meinung, ohne zuverlässige Belege was behaupten zu können. Du solltest im übrigen deine Feindseligkeit etwas bremsen. So ist kein klarer Austausch von Argumenten möglich. --TheRandomIP (Diskussion) 17:13, 29. Aug. 2020 (CEST)

Service und EOD. --77.116.111.138 17:17, 29. Aug. 2020 (CEST)

Du willst keine Belege nachtragen und denkst, irgendwelche Altbestände dürften auf Ewig ohne zumindest ein Minimum an Belegen weiter existieren, haben wir verstanden. Sehe ich anders. Um am Ende gibt es auch noch die Belegpflicht. Wenn wir hier alle möglichen - zulässigen! - Quellen durchsucht haben und für manche der Einträge keine einzige solche gefunden haben, dann gibt es nicht mehr viel, was diese Einträge noch im Artikel rechtfertigt. Wie man so etwas ordentlich belegt, habe ich durch meine jüngsten Edits gezeigt. Daran könnte man sich orientieren. --TheRandomIP (Diskussion) 17:27, 29. Aug. 2020 (CEST)

Achso, Valanagut, jetzt sehe ich, du hast Einzelnachweise zu Listeneinträgen hinzugefügt, die schon einen Wikipedia-Artikel haben. Mir geht es explizit um die Einträge, die keinen Wikipedia-Artikel haben. Schaue dir meine ehemals gekürzte Version an: [5] Beide tauchen da noch auf, da ich sie als belegt anerkannt habe. Ich dachte, du hättest einfach bei noch unbelegten Einträgen den Hersteller-Link eingefügt. War wohl ein Missverständnis. Daher nochmal wie ich es sehe. Was man braucht ist eines der folgenden Dinge:

• Eigener Wikipedia-Artikel
• Link zur Produkt-Webseite eines relevanten und bekannten Herstellers (mit Nachweis z.B. eigener Wikipedia-Artikel des Herstellers)
• Rezeption des Produktes von einer dritten Stelle (Codeguru etc.)

Wenn eines der drei erfüllt ist, sehe ich den Eintrag hier als gerechtfertigt an. Andere mögen das anders sehen, aber das ist zumindest mal meine Vorstellung davon. --TheRandomIP (Diskussion) 17:37, 29. Aug. 2020 (CEST)

Die Internetrecherche beschränkt sich nicht auf die Bedienung von Tante Gugl, wo 404-Seiten recht zügig aus dem Cache verschwinden. Dafür gibt es das Webarchiv, und im übrigen gab es Software bereits lange vor der Zeit des Internets, insofern sich Deine Recherche auch auf einschlägige physische Bibliotheken und den Buchmarkt erstrecken müßte, wenn Du denn den Bestand der Wikipedia tatsächlich wissenschaftlich prüfen willst. Dein Vorgehen hier ist nichts weiter als laienhaftes wie oberflächliches Suchmaschinenbedienen mit großem Tamtam auf allen Metaseiten der Wikipedia. Und dafür hoffe ich, daß jetzt endlich jemand den Notaus drückt! --77.116.111.138 17:38, 29. Aug. 2020 (CEST)

Tja, dann ist es halt Pech, wenn keiner mehr den Beleg findet. Deswegen muss man Belege angeben, damit man die Inhalte später noch nachvollziehen kann. Ein jeder kann ja nun für Belege sorgen, im Artikel hängt ja nun erstmal der Baustein. In "einschlägige physische Bibliotheken" kannst du ja suchen. Denn dort ist es dann keinesfalls mehr "auf der Hand liegend" wo man das nachschlagen kann. WP:Q gibt vor, dass nur was "auf der Hand liegend" ist, wo es drin steht, ohne Belege auskommen kann. Und in allen "auf der Hand liegend" Quellen werde ich gründlich suchen. Damit musst du leben, wenn du hier ohne Belege irgendwelches Zeug reinklatscht, dass ein andere kommt und es anzweifelt. Hättest halt mal selber für Belege sorgen müssen! --TheRandomIP (Diskussion) 17:54, 29. Aug. 2020 (CEST)

Gut, Fachliteratur streichen wir ab sofort aus den heranzuziehenden Quellen zur Erstellung unserer Online-Enzyklopädie. Ich würde auch vorschlagen, wir reduzieren einfach unser Angebot auf die Google-Suchergebnisse, die können wir dann eigentlich gleich via API/iframe hier einbinden, und historisches Wissen wird als unnütz verworfen! Ich schlage auch gleich vor, daß Du Dich von Jimmy Wales zum Superadmin befördern läßt, um die entsprechenden Maßnahmen umgehend durchzusetzen! --77.116.111.138 18:05, 29. Aug. 2020 (CEST)

Ja, Sitepoint wäre nach meinem Dafürhalten eine geeignete Quelle. Danke @Benutzer:Valanagut fürs Hinzufügen. (Kontext) --TheRandomIP (Diskussion) 20:16, 29. Aug. 2020 (CEST)

Das Problem ist das es sich bei Dependency Injection Frameworks manchmal nur um Source Code handelt, der nur diese Aufgabe erfüllt. Natürlich ist das Quellen finden dadurch schwer. Aber, eine Liste sollte möglichst komplett sein. Suche ich als Leser z.B. nach einer reinen PHP Dependency Injection Lösung, will also nur die Funktionalität in einem eigenen Projekt, dann bringt es mir nichts wenn nur renovierte Grosse Frameworks wie Symfony aufgelistet werden. Nein ich will kein Symfony, nur weil ich eine DI Funktionalität brauche. Natürlich kann man argumentieren keine grossartigen Rezeptionen, weg damit. Beispiel «phemto» Das Ding macht nur DI. Ein eigener Artikel über Phemto wäre overkill. Und so sieht das auch die Fachliteratur. Lässt man sie aber weg, dann fehlen dem Leser wichtige Informationen, und Wikipedia liefert diese Informationen dann nicht. Wikipedia ist in diesem Fall unbrauchbar. Natürlich kann man argumentieren. Wikipedia ist kein Tutorial über DI. Das ist aber Blödsinn. Dieses ganze Enzyklopädie Geschwätz ist Schnee von Gestern. Vor 15 Jahren wollte man Wikipedia als Buch und CD herausbringen. Da machten Beschränkungen sehr wohl Sinn. Aber das ändert sich (Siehe Umbenennung WMF) de.wikipedia.org soll als Hub für das Sammeln von Freien Wissen dienen. Und das bedeutet möglichst komplett zu sein. Das gilt auch für Dinge wie «phemto». Ich als Leser erwarte die richtigen Informationen zu bekommen, auch wen es sich um eine Nische handelt. Nochmal: Leser sucht nach einer DI Lösung um diese in sein php Projekt einzubauen. Da bringt es nichts, wenn nur Symfony aufgeführt wird, weil das Ding nun mal populär ist, aber der Leser nur 1% der Funktionalität benötigt. Das wäre Overkill. Wenn euch Leser Service wichtig ist, dann vergesst diesen Blödsinn mit Quellen in diesem Fall! Ich sehe diese ganze Aktion weiterhin als Gängelung der ursprünglichen Autoren. Und als nicht Sinnvoll! Vielen Dank! ไม่เป็นไร (Valanagut) (Diskussion) 09:17, 30. Aug. 2020 (CEST)

Die Dependency Injection ist eine beliebte Alternative zum Service Locator-Muster. Viele moderne Anwendungsframeworks implementieren diese Technik und diese Frameworks stellen die technischen Teile der Technik bereit, sodass du dich auf die Implementierung deiner Geschäftslogik konzentrieren kannst. Beliebte Beispiele sind:

• Spring (Java)
• Google Guice (Java)
• Dagger (Java and Android)
• Castle Windsor (.NET)
• Unity(.NET)
• Wallaroo (C )
• Hypodermic (C )
• Robotlegs (Actionscript)
• LightWire (ColdFusion)
• Orochi (Perl]
• Phemto (PHP 5)
• Laravel (PHP 5)
• SpringPython (Python)
• Zenject (Unity 3D)ไม่เป็นไร (Valanagut) (Diskussion) 09:27, 30. Aug. 2020 (CEST)

Benjamin Eberlei: Bevor einer auf die Idee kommt zu fragen wer das ist! Benjamin Eberlei gilt als die Kapazität in PHP Frameworks. [[6]] ไม่เป็นไร (Valanagut) (Diskussion) 09:42, 30. Aug. 2020 (CEST)

Zualler erst geht es darum, dass die Informationen im Artikel auch richtig sind. Man muss sich darauf verlassen können, dass die Informationen, die man im Artikel vorfindet, auch stimmen. Sonst nutzt die das alles nichts. Wenn die Hälfte der Frameworks ausgedacht / nie Marktreife erlangt / nicht die notwendigen Eigenschaften haben um als das Produkt erkannt zu werden, das es vorgibt zu sein, dann bringt einem diese Liste nichts außer dass Leser sich über den schlechten Zustand der Wikipedia ärgern. Das strahlt dann auch auf andere Artikel: Wikipedia wird von den Lesern als reinen User-Forum wahrgenommen, in dem Leute einfach so Dinge behaupten können und es sein kann, dass es kompletter Quatsch ist was im Artikel steht. Diesen Anschein müssen wir vermeiden. Und das geht nur, wenn wir von allen verlangen, dass sie die Informationen belegen. Auch Außenstehende müssen das nachvollziehen können, und das geht nur mit Belegen. Dass Wikipedianer einfach behaupten, sie sind die Experten und wissen das auch ohne Belege, das geht nicht. Nicht hier, nicht in anderen Artikeln, nirgendwo. Das können wir aus Prinzip nicht durchgehen lassen.
Gerade bei "Liste von <Produkt>" sehe ich zudem das Problem, dass diese dann als Marketing-Veranstaltung gesehen werden. Gerade wenn es um kommerzielle Produkte geht. Oftmals ist es umstritten, ob das Produkt wirklich das ist, was es vorgibt zu sein. Das sieht man in Liste von Webkonferenz-Lösungen dass es da wohl umstritten ist, was denn überhaupt eine Webkonferenz-Lösung ist. (Sonst müsste man diese ganzen Kriterien nicht definieren) Ein kommerzieller Hersteller wird das immer bejahen und sagen, ja mein Produkt kann das alles, mein Produkt ist super toll. Aber in Wahrheit muss das nicht stimmen. Deshalb können wir hier nur Dinge aufnehmen, die von reputablen Quellen unter dem Artikelgegenstand erkennt werden. --TheRandomIP (Diskussion) 12:22, 30. Aug. 2020 (CEST)

Weiterhin fehlende Belege

So, Endspurt! Nachdem ich unzählige Recherchen unternommen habe und zahlreiche DI-Frameworks belegen konnte und dabei sogar neue Frameworks ergänzen konnte, nachfolgend die Liste, für die ich keine Belege finden konnte:

• Actionscript
  • Swiz - https://www.openhub.net/p/swiz-framework - 601 commits, 17 contributors, 2 PJ, hat kurz gelebt (2011-2012) und ist seitdem tot
  • Cairngorm3 - https://www.openhub.net/p/Cairngorm3 - ebenfalls seit lange (2011) keine Aktivität
  • StarlingMVC - https://www.openhub.net/p/starlingmvc - 120 commits, 7 contributors, ebenfalls seit lange (2013) keine Aktivität
• C
  • hypodermic - kein Eintrag bei OpenHub (nur einer für etwas anderes mit selbem Namen)
  • wallaroo - ist bei OpenHub nicht mit dem Repository verbunden, lt. Sourceforge Homepage die letzte Version 2018
  • Boost.DI - https://www.openhub.net/p/boost-di - lebt, >5.000 commits, 18 contributors, 38 PJ
  • Google Fruit (grenzwertig, ist zwar von Google aber wird kaum rezipiert und existiert nur auf gitHub) - https://www.openhub.net/p/fruit - lebt, >1.000 commits, 12 contributors, 5 PJ
  • Infector - kein Eintrag bei OpenHub
• Delphi
  • mORMot - https://www.openhub.net/p/mormot - lebt, >6.000 commits, 48 contributors
  • Spring4D - https://www.openhub.net/p/spring4d - lebt, >2000 commits, 18 contributors, 33 PJ
• Java
  • DDI - Dynamic Dependency Injection - gemeint ist vermutlich https://www.openhub.net/p/dynamic-cdi Dynamit Context Dependency Injection - lebt, 255 commits, 7 contributors 12 PJ
  • Salta - kein Eintrag bei OpenHub
  • simject - kein Eintrag bei OpenHub
• Kotlin
  • Koin - kein Eintrag bei OpenHub
• Objective-C
  • Objection - kein Eintrag bei OpenHub
• PHP 5
  • Phemto (it-talents als Quelle eher grenzwertig) - https://www.openhub.net/p/phemto - 23 commits, 2 contributors, tot
  • PicoContainer for PHP (bloß ein privater Internet-Blog als Beleg) - kein Eintrag bei OpenHub
  • Adventure PHP Framework (APF) - https://www.openhub.net/p/adventurephpfra - seit 5 Jahren tot
• PHP 7
  • tueena-lib/dependency-injection - kein Eintrag bei OpenHub
• Python
  • snake-guice - https://www.openhub.net/p/snake-guice - 131 commits, 2 contributors, tot
  • python-inject - kein Eintrag bei OpenHub
• .NET
  • IoC - kein Eintrag bei OpenHub
  • LinFu - vermutlich https://www.openhub.net/p/philiplaureanos_LinFu - 261 commits, 6 contributors, 25 PJ, tot - http://www.codeproject.com/KB/cs/LinFuPart1.aspx
  • LOOM.NET mit Dependency Injection Aspect - kein Eintrag bei OpenHub
  • NauckIT.MicroKernel - kein Eintrag bei OpenHub
  • OpenNETCF.IoC - https://www.openhub.net/p/ioc - code nicht mehr verfügbar, da auf CodePlex
• Unity 3D
  • strangeIOC - https://www.openhub.net/p/strangeioc - 5 commits, 1 contributor
  • Zenject - kein Eintrag bei OpenHub

Vielleicht könnt ihr eure Suche noch einmal intensivieren nach den oben genannten Frameworks, insbesondere auch in Literatur, die vielleicht nicht so einfach zu finden ist, damit wir auch wirklich reputable Belege für diese bekommen. Andernfalls lautet das Ergebnis unserer Recherche dann: Diese Frameworks werden in reputabler Sekundärliteratur nicht genannt, sind also nicht für die Aufnahme in einen Wikipedia-Artikel geeignet. --TheRandomIP (Diskussion) 20:40, 16. Sep. 2020 (CEST)

Hab oben die Infos lt. openhub ergänzt: OS-Frameworks, die keinen Eintrag bei openhup haben, hatten mit höchster Wahrscheinlichkeit zu keinem Zeitpunkt eine relevante Anzahl an Usern, die mit kaum code und sehr wenigen contributern ebenfalls. Von den oben genannten halte ich basierend auf den Infos:

• für vermutlich relevant: Boost.DI, Google Fruit (das ein OS-Framework nur auf Github lebt sagt meiner Erfahrung nach nichts zu seiner Relevanz aus), Spring4D, mORMot (aber ich erkenne beim schnellen drüberlesen nicht, dass es DI kann), LinFu (vermutlich historisch relevant)
• für ziemlich sicher irrelevant: Cairngorm3, StarlingMVC, hypodermic, Infector , Salta, simject, Koin, Objection, Phemto, PicoContainer for PHP, tueena-lib/dependency-injection, snake-guice, python-inject, IoC, LOOM.NET mit Dependency Injection Aspect, NauckIT.MicroKernel, strangeIOC, Zenject, Adventure PHP Framework (APF)

d.h. ich werde jetzt die ziemlich sicher irrelevanten löschen. Bei den vermutlich relevanten sollte sich was finden lassen... --Sebastian.Dietrich ✉ 18:23, 17. Sep. 2020 (CEST)

done - nur nicht bei Koin, das scheint aktuell zu sein --> hab eine OpenHup Seite dafür angelegt (https://www.openhub.net/p/koin), werden wir sehen, was bei der OpenHub Analyse rauskommt... --Sebastian.Dietrich ✉ 18:52, 17. Sep. 2020 (CEST)

also auch Koin scheint relevant zu sein - https://www.openhub.net/p/koin > 1.000 commits, 106 contributors, 4pj --Sebastian.Dietrich ✉ 23:51, 17. Sep. 2020 (CEST)

Super, danke dir. Jetzt sind es also nur noch ganz wenige Frameworks, auf die wir uns konzentrieren müssen. Für sie besteht nun ein begründeter "Anfangsverdacht" der Relevanz. Diese können wir auch mal länger im Artikel lassen und auf Nachbelegung durch Leser hoffen. Für koin hab ich gerade noch was bei Google Books gefunden. --TheRandomIP (Diskussion) 20:25, 18. Sep. 2020 (CEST)