• Jeder User im Forum verpflichtet sich zur Akzeptanz und zur Einhaltung dieser Regeln:
    1. Umgangston
      Ein angemessener höflicher Umgangston, ohne Beleidigungen, Beschimpfungen und aggressive Postings ist für jedes Mitglied Pflicht.
    2. Beiträge
      Jedes Mitglied sollte sich bemühen nur sinnvolle Beiträge zum Thema zu posten. Dabei ist unbedingt vorher zu prüfen, ob das Thema vorher schon einmal diskutiert wurde und daher fortgesetzt werden kann
      • Suchfunktion benutzen!
      • offizielle Doku lesen!
    3. Haftung
      Jeder Beitragsersteller übernimmt die alleinige Verantwortung seiner Inhalte.
    4. Werbung
      Wir erlauben keine Beiträge, Signaturen, Private Nachrichten oder eMails an Benutzer, die Werbung enthalten. Ausgenommen
      sind Stellengesuche /-angebote, welche ausschließlich im Forum "Stellengesuche" veröffentlicht werden dürfen.
    5. Verstöße
      Regelwidrige Beiträge sollten dem Team gemeldet werden. Nach deren Überprüfung werden wir schnellstmöglich
      entsprechend handeln.
    6. Authorität
      Den Anweisungen der Team-Mitglieder (Administratoren und Moderatoren) sind in diesem Forum Folge zu leisten.
      Bei Fragen oder Beschwerden bitte an diese wenden.
    Wir möchten Euch darauf aufmerksam machen, dass es bei Verstößen gegen einen oder mehreren der oben genannten
    Punkte dem Team frei steht entsprechend zu handeln. Dies kann z.B. das Löschen eines Beitrags, das Ausschliessen bzw.
    Sperren von Mitgliedern oder aber lediglich eine Verwarnung sein.

    In diesem Zusammenhang sollte erwähnt werden, dass das Forum automatisch die IP-Adresse jedes Beitrag-Erstellers
    speichert. Bei schweren Vergehen, behalten wir es uns vor, die IP-Adresse zur Strafverfolgung weiterzugeben.
  • Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

DIContainer - Feedback erwünscht

G.Schuster

New member
Hallo,


Bevor gleich Mecker kommt: ich weiß, dass es zig "fertige" DI-Container gibt...es macht aber keinen Spaß immer nur fertige Sachen einzubauen ;)

Kurz umrissen, worum es geht:
Um meine Anwendungen etwas zu verschlanken, was notwendige Objekte etc. angeht und als Testlauf für (m)ein neues Model-Konzept hab ich mir ein paar Gedanken zu Dependencies wie z.B. einer DB-Verbindung für meine Models gemacht.
Das Ganze habe ich kurzer Hand an ein paar Abenden umgesetzt und bin bisher recht zufrieden damit.
Da ich aber nur zwei Augen (und wenig Schlaf) habe würde ich mich freuen, wenn ein paar von euch mal drüber schauen und ein wenig, hoffentlich positive, Kritik dazu äußern.
Ein nicht-funktionales Anwendungsbeispiel liegt bei, damit man sieht, wie das Teil genutzt werden kann.

Kommentare bitte hier im Forum - der Blog lahmt dank ausgelastetem Server und ich komme nicht dazu, alles umzuziehen :rolleyes:

Download gibt's hier: http://blog.actra.de/wp-content/uploads/2009/11/exTSend-DIContainer.zip


PS: Danke im Voraus!
 

ice-breaker

New member
also ich finde es viel zu kompliziert.
Di steht und fällt meiner Meinung nach mit der Entscheidung ob man auf Annotations setzt oder nicht.

Edit: schau dir mal den Stubbles oder Google Guice Ansatz an, viel weniger Konfiguration und damit deutlich einfacher und intuitiver zu bedienen.
 

KingCrunch

New member
Annotations sind laaaahm ;) Neija, zumindest im Vergleich zu nativen Strings. Und wenn man beachtet, dass "example.php" sowieso nur die Konfiguration enthält, hält sich die Komplexität bei der Verwendung in Grenzen.

@topic:
@example.php: Sieht wirklich erstmal sehr wirr aus :D Aber im Grunde ist alles da. Der letzte Parameter irritiert etwas. Das ist zwar ein Array, allerdings enthalten alle Aufrufe die selben Schlüssel. Da würd ich eher noch zwei getrennte Parameter draus machen, oder vielleicht ein Objekt (eventuell mit dem Parameter davor noch). Das hätte zudem den Vorteil, dass du dann mit den weiteren Argumenten flexibler umgehen kannst, zum Beispiel indem du auf das PlaceHolder-Objekt verzichtest und ... neija irgendwie anders ;)
@Code: Ganz schönes Verschachtelungs-Wirrwarr :D Speziell die Exceptions würd ich dann doch auf eine Zeile packen, die Exceptions-Codes interessieren dann doch nur alle Jubeljahre mal und dann kann man auch mal scrollen. Anderer Tipp wäre der Einsatz von temporären Variablen statt Array-Konstruktionen in den Funktions- bzw Methodenaufrufen. Bisheriger Rekord-Einzug ist 13 :D Ich hab 4 Spaces pro Einzug, das würde bei mir schon lange rechts weglaufen :rolleyes:
Das mit dem ClassLoader hab ich so genau noch nicht durchschaut, geht aber eventuell einfacher. Hätte den Begleiteffekt, dass 5.3-ers Closures auch bzw Objekte für $class auch funktionieren würden ;) (undocumented Feature)
PHP:
public static function setClassLoader($method, $class = NULL) {
  $callable = is_null($class) ? $method : array($class, $method);
  if (!is_callable($callable)) {
    // Exception
  }
}
Die Methode getComponent() is gaaanz schwere Kost... Das macht kein Spass zu Lesen.

Hat das eigentlich einen tieferen Sinn, dass die DI-Komponente Open-Source (New BSD) is, aber ausgerechnet die example.php nicht? :D

Sonst isses eigentlich ganz schnuffig ^^ Falls mir noch was einfällt, schreib ichs noch drunter ;)
 

G.Schuster

New member
Danke euch beiden erst Mal für das Feedback.

@icebreaker: Annotations sind ein Weg, ich gehe einen Anderen ;)
Zumal, wie Müsli schon anmerkte - laaaaahm.
Ich will das Ganze (sprich die Anwendungen, die später damit laufen) halbwegs auf Speed bringen (gute Dealer und so..) - und da kann ic hdann nicht mit Annotation-Parsing ankommen.

Das ist zwar ein Array, allerdings enthalten alle Aufrufe die selben Schlüssel. Da würd ich eher noch zwei getrennte Parameter draus machen, oder vielleicht ein Objekt (eventuell mit dem Parameter davor noch). Das hätte zudem den Vorteil, dass du dann mit den weiteren Argumenten flexibler umgehen kannst, zum Beispiel indem du auf das PlaceHolder-Objekt verzichtest und ... neija irgendwie anders ;)
Das Array hat den Sinn, dass man da noch mehr Keys angeben kann - die auch schon definiert sind, aber für die Beispiele nicht gebraucht wurden :-/

@Code: Ganz schönes Verschachtelungs-Wirrwarr :D
Angewohnheit...wobei ich's lieber in ein paar Dateien mehr Verschachtel als später irgendwelche Namens-Probleme zu bekommen.
Hab auch die "dumme" Angewohnheit übergebene Werte exzessiv zu prüfen...so laxe Sachen wie nur Prüfung auf isset() obwohl explizit ein String benötigt wird mag ich nicht.
Wobei ich's manchmal auch vergesse...pobody's nerfect, wa?

Speziell die Exceptions würd ich dann doch auf eine Zeile packen, die Exceptions-Codes interessieren dann doch nur alle Jubeljahre mal und dann kann man auch mal scrollen.
Nun, mich persönlich interessieren die Codes doch etwas öfter bzw. ich habe es mir so angewöhnt, da ich gelegentlich die Fehlerbehandlung anhand der Codes steuern möchte.

Anderer Tipp wäre der Einsatz von temporären Variablen statt Array-Konstruktionen in den Funktions- bzw Methodenaufrufen.
Wie meinen?

Bisheriger Rekord-Einzug ist 13 :D Ich hab 4 Spaces pro Einzug, das würde bei mir schon lange rechts weglaufen :rolleyes:
Ich nutze 6 Spaces pro Tab und muss nicht rechts scrollen...kauf dir mal nen größeren Monitor und/oder stell mal nich so ne Opa-Hornbrillen-Schriftgröße ein :p
Nein, Spaß bei Seite, genau der Gedanke kam mir heute auch...so zwei schöne 22Zöller mit einer angenehmen Schriftgröße bei 1680x1050 verleiten halt doch zu 190 Zeichen pro Zeile :(

Das mit dem ClassLoader hab ich so genau noch nicht durchschaut, geht aber eventuell einfacher. Hätte den Begleiteffekt, dass 5.3-ers Closures auch bzw Objekte für $class auch funktionieren würden ;) (undocumented Feature)
Der ClassLoader ist eigentlich nur Spielerei, falls man das Teil ohne ZF nutzen will...weiß ich selber nicht wofür ich den eingebaut hab...aber wenn er schon mal da ist.
Mit Closures hab ich bisher nix am Hut gehabt, dementsprechend müsste ich das irgendwann mal berücksichtigen, hat aber in dem Fall einfach keine Prio.

Die Methode getComponent() is gaaanz schwere Kost... Das macht kein Spass zu Lesen.
Das ist klar...
Ich musste ja irgendwo die ganze Logik reinpacken also ist's halt da gelandet.

Hat das eigentlich einen tieferen Sinn, dass die DI-Komponente Open-Source (New BSD) is, aber ausgerechnet die example.php nicht? :D
Nö, da bin ich beim Copy'n'Paste wohl auf die falsche SourceDatei gekommen.
Fixed & danke für den Hinweis.

Sonst isses eigentlich ganz schnuffig ^^
:)
 
Zuletzt bearbeitet:

KingCrunch

New member
Ich will das Ganze (sprich die Anwendungen, die später damit laufen) halbwegs auf Speed bringen (gute Dealer und so..) - und da kann ic hdann nicht mit Annotation-Parsing ankommen.
So als Ergänzung: Dependency-Injection ist (zumindest vom Konzept) nichts, was "eventuell" mal aufgerufen wird und das ganze Geparse kann da schon stören. Bin ja nun kein Performance-Fetischist, aber da macht es Sinn. Die ganzen Kurse zum Thema "Komplexität" müssen ja für irgendwas gut sein :D
Das Array hat den Sinn, dass man da noch mehr Keys angeben kann - die auch schon definiert sind, aber für die Beispiele nicht gebraucht wurden :-/
Könnte man durch passende Klassen realisieren. Oder (wenn die Zahl der "anderen Keys" überschaubar bleibt) durch weitere optionale Parameter, eventuell durch "freie Parameter". Ich habs einfach mal so genannt ;) Gemeint ist eine beliebige Zahl Parameter, die dann durch den Konstruktor (/durch die Methode) durch get_func_args() bestimmt werden. Is hier aber vermutlich eher ... Naja, vergisses ;)

Welche "Arten" von Parameter gibt es denn überhaupt noch zu erwarten?
Nun, mich persönlich interessieren die Codes doch etwas öfter bzw. ich habe es mir so angewöhnt, da ich gelegentlich die Fehlerbehandlung anhand der Codes steuern möchte.
Du hast doch brav die Codes in der Exception-Klasse als Konstanten definiert. Konstanten schreien geradezu als Nachschlagewerk ;) Durch die Bezeichner der Konstanten weißt du doch bereits, worum es geht. Dazu brauchst du doch eigentlich nicht mehr die Information, wo irgendein Code geworfen wird, ausser vielleicht nach nem Bug-Report, aber wie gesagt: Da kann man noch scrolln ;)

Wenn ich grad nochma so über den Code scrolle .... Du schmeißt eh ne ganze Menge Exceptions... Sind die alle notwendig? Zum Beispiel sowas:
PHP:
                        if($reflection->getMethod($preInvocationCall['method'])->isConstructor()) {
                              throw new exTSend_DIContainer_Exception(
                                    'The constructor can not be specified as pre-invocation call.',
                                    exTSend_DIContainer_Exception::EXCEPTION_CONSTRUCTOR_AS_PRE_INVOCATION_IS_INVALID
                              );
                        }
Kann man das nicht einfach stehen lassen als "Selten dämmlich, dass das überhaupt irgendwer versucht"? Is ja nett gemeint, aber wer sowas versucht, hats nicht anders verdient ;)
Wie meinen? [Bezug: Temporäre Variablen statt array-Konstruktion in Aufrufen, Anm. des Authors]
Also statt
PHP:
myFunction (array('bla','blub'));
eher sowas
PHP:
$param = array('bla', 'blub');
myFunction ($param);
Hier fällts nicht so auf, aber ich denke, dass das bei deiner Einrückungsstrategie schon etwas übersichtlicher wird.
Ich nutze 6 Spaces pro Tab und muss nicht rechts scrollen...kauf dir mal nen größeren Monitor und/oder stell mal nich so ne Opa-Hornbrillen-Schriftgröße ein
Nein, Spaß bei Seite, genau der Gedanke kam mir heute auch...so zwei schöne 22Zöller mit einer angenehmen Schriftgröße bei 1680x1050 verleiten halt doch zu 190 Zeichen pro Zeile
Mein Fehler, hab 3 Spaces vermutet, nicht 6. Wirkt teilweise trotzdem reichlich treppenartig.
Hab selbst 4 für code (PHP, JAVA, ...) und 2 für Markup (HTML, XML, ..), da letztere gerne sehr weit Einrücken.
Also so grundsätzlich verteufel ich das ja auch, aber ein switch(true) (als Ersatz für elseif-Geschwader) hilft manchmal echt Wunder :rolleyes:
Der ClassLoader ist eigentlich nur Spielerei, falls man das Teil ohne ZF nutzen will...weiß ich selber nicht wofür ich den eingebaut hab...aber wenn er schon mal da ist.
Mit Closures hab ich bisher nix am Hut gehabt, dementsprechend müsste ich das irgendwann mal berücksichtigen, hat aber in dem Fall einfach keine Prio.
Hab auch betont (dachte ich zumindest), dass das eher Begleiteffekt wäre, Hauptaugenmerk lag eher auf das "callable", was eben alle "callable" prüft, sprich: Alles, was per call_user_func() aufgerufen werden kann :)
Das ist klar...
Ich musste ja irgendwo die ganze Logik reinpacken also ist's halt da gelandet.
Splitten.
Vllt macht hier und da auch noch ne public-Methode Sinn, wo es quasi "For-Your-Information" irgendwie aufgerufen werden kööööönte, ansonsten eben ne kleine Armada protected, oder eben private, falls es wirklich rein intern ist.
 

KingCrunch

New member
Jaja, neuer Post, obwohl ich editieren könnte :p

Ich seh grad "die Verwendung" in example.php
PHP:
$userService = exTSend_DIContainer::getComponent('userManagementService');
ist das die einzige Möglichkeit?
Was ich hier etwas vermisse ist sowas wie wie "Namespacing". Das ist deshalb in Anführungsstrichen, weil ichs so eigentlich garnicht meine. Im Grunde existiert jedes Objekt in seinem Mikrokosmos, was eben auch für DI-Objekte gilt.
Anders gesagt: Wieso ist man hier auf statische (und damit auf für den Aufruf globale und die komplette Anwendung übergreifende) Zugriffe beschränkt?
Eventuell etwas konstruiert, aber lass zwei (ansonsten) unabhänige Komponente deine DI-Komponente nutzen und zufällig nutzen sie den selben Schlüssel für ein Element. Kann hässlich werden ^^

Ich würd hier Pseudo-Singletons (haben die einen eigenen Namen?) draus machen. Alternative wäre, wenn du es einfach offen lässt, wie der jeweilige Nutzer es verbreitet, wie zB eine Registry. ;)
PHP:
$di = exTSend_DIContainer::getInstance('myNamespace')->get('brabbeö'); // "getComponent" ist ganz schön lang
// Eigentlich weiß ich ja, was ich "get"te
 

G.Schuster

New member
Könnte man durch passende Klassen realisieren. Oder (wenn die Zahl der "anderen Keys" überschaubar bleibt) durch weitere optionale Parameter, eventuell durch "freie Parameter". Ich habs einfach mal so genannt ;) Gemeint ist eine beliebige Zahl Parameter, die dann durch den Konstruktor (/durch die Methode) durch get_func_args() bestimmt werden. Is hier aber vermutlich eher ... Naja, vergisses ;)
Die Anzahl ist Überschaubar, an sich sind's die Public-Methoden, damit man alles in einem Aufwasch übergeben kann.
Theoretisch könntest du auch einfach sowas machen:
PHP:
$component = new exTSend_DIContainer_Component($name, $class, $type);
$component->setInvocationType()
     ->setInvocationArguments()
     ->addInvocationArguments()
     /.../;
Ist also "for convenience".

Du hast doch brav die Codes in der Exception-Klasse als Konstanten definiert.
Die separaten Exception-Klassen sind für sowas gedacht:
PHP:
try {
     // ...
}
catch(Exception exTSend_DiContainer_Exception $e) {
     switch($e->getCode()) {
          case exTSend_DIContainer_Exception::EXCEPTION_FOOBAR:
               doThis();
               break;
          default:
               doThat();
     }
}
Wenn ich grad nochma so über den Code scrolle .... Du schmeißt eh ne ganze Menge Exceptions... Sind die alle notwendig?
[...]
Kann man das nicht einfach stehen lassen als "Selten dämmlich, dass das überhaupt irgendwer versucht"? Is ja nett gemeint, aber wer sowas versucht, hats nicht anders verdient ;)
Jein. Das ist mein...hm...nennen wir es mal "Korrektheitswahn".
Ich mag es nicht wenn Leute machen können was sie wollen nur um dann irgendwo später auf für sie unerklärbare Weise auf die Schnauze zu fliegen.
Da hau ich ihnen lieber gleich eine Excption um die Ohren, dann wissen sie was Sache ist.

Also statt
PHP:
myFunction (array('bla','blub'));
eher sowas
PHP:
$param = array('bla', 'blub');
myFunction ($param);
Sehe ich keinen Vorteil ausser dass ich unnötige Variablen definiere.

ist das die einzige Möglichkeit?
Derzeit ist es die einzige Möglichkeit.
Ich wüsste spontan auch nicht, was ich sonst noch an Möglichkeiten einbauen sollte, an eine Instanz zu kommen.
Gut, du kannst noch einen umweg gehen - Instanz von exTSend_DIContainer holen :):getInstance()) und darauf dann ->getComponent() - das ist so implementiert.
Was schwebt dir denn sonst so vor?

Die Idee mit den Namespaces finde ich gut, das werd ich denke ich noch umsetzen.
Aber eher als getComponent('component', 'namespace'), wobei namespace für "global" einfach NULL bleibt.
 

ice-breaker

New member
neija aber sobald mal mehr als 50 Komponenten (und ein komplexes System hat deutlich mehr) in der Konfiguration drinne sind, wird niemand mehr den Konfigurations-Wirrwarr überblicken.
 

G.Schuster

New member
Deswegen definiere ich für meine Projekte das schön in den jeweiligen Resourcen, da bleibt der Überblick gut erhalten.

Sparst Einrückungen, gewinnst Übersicht. ;)
Naja...keine wirklichen Argumente. Die Geschichte mit den Monitoren habe ich ja oben schon erwähnt :)

Ob ich jetzt einen Singleton mit ::getInstance() hole oder aus dem Objekt raus auf statische Variablen zugreifen...hm...macht finde ich keinen wirklichen Unterschied.
Ausser dass ich unnötige Objekte erzeuge, die Speicher kosten, da es separate Objekte und keine Referenzen auf einen Singleton sind.

[ot]
Irgendwie werde ich das Gefühl nicht los, dass ich der Einzige bin, der eine "nicht-laxe" Einstellung zum Thema Programmieren hat.
Wenn ich so Sachen lese wie Instanzen für etwas erzeugen, das als Singelton gehalten werden muss oder keine Exceptions werfen, der Entwickler wird's schon merken wenn's nicht passt...da wird's mir echt Anders.
Ich übertreib's an manchen Stellen mit der Genauigkeit vielleicht etwas und bin absolut kein perfekter Entwickler - aber sowas, finde ich, geht halt mal gar nicht - erst recht nicht, wenn man Business-Anwendungen schreibt, mit denen man/andere Geld verdienen bzw. darüber ausgeben.
Bevor sich jemand auf den Schlips getreten fühlt: ich möchte hier niemanden konkret kritisieren, das ist nur eine allgemeine Beobachtung, die nichtmal auf das ZFForum beschränkt ist.
[/ot]
 

KingCrunch

New member
Ob ich jetzt einen Singleton mit ::getInstance() hole oder aus dem Objekt raus auf statische Variablen zugreifen...hm...macht finde ich keinen wirklichen Unterschied.
Ich meinte ja auch, dass du es nicht als Singleton implementieren solltest. Stichwort: Singletonitis ;) Ich sehe hier zumindest keine Notwendigkeit für das Pattern. Wenn wer nur ein Container braucht, dann soll er sich eins erzeugen und in der Registry ablegen. Wenn wer mehr haben möchte, wieso sollte man ihn das dann krampfhaft verwehren?
Ausser dass ich unnötige Objekte erzeuge, die Speicher kosten, da es separate Objekte und keine Referenzen auf einen Singleton sind.
Ähm ... :D OOP programmieren, aber keine Objekte erzeugen wollen?
Ich fänds zumindest irgendwie "zweckmässiger", wenn ein Container auch ein Container ist und ich eventuell mehrere davon haben kann.
[ot]
Irgendwie werde ich das Gefühl nicht los, dass ich der Einzige bin, der eine "nicht-laxe" Einstellung zum Thema Programmieren hat.
Wenn ich so Sachen lese wie Instanzen für etwas erzeugen, das als Singelton gehalten werden muss oder keine Exceptions werfen, der Entwickler wird's schon merken wenn's nicht passt...da wird's mir echt Anders.
Ich übertreib's an manchen Stellen mit der Genauigkeit vielleicht etwas und bin absolut kein perfekter Entwickler - aber sowas, finde ich, geht halt mal gar nicht - erst recht nicht, wenn man Business-Anwendungen schreibt, mit denen man/andere Geld verdienen bzw. darüber ausgeben.
Bevor sich jemand auf den Schlips getreten fühlt: ich möchte hier niemanden konkret kritisieren, das ist nur eine allgemeine Beobachtung, die nichtmal auf das ZFForum beschränkt ist.
[/ot]
Im Grunde versteh ich wieder Entwickler nicht, die wirklich jeden an die Hand nehmen wollen ;)
Ein Nutzer weiß entweder, was er einer Methode übergibt (zB weil er es selbst definiert, oder irgendwann anders schon geprüft hat (Daten aus DB)), oder aber er muss es sowieso selbst prüfen. In beiden Fällen ist eine zusätzliche Prüfung innerhalb der Methode überflüssig. Anders herum müsste er nun die Methode immer in try-catch verpacken oder immer jeden einzelnen Wert vor Aufruf prüfen, um Exceptions zu vermeiden, zumindest wenn man konsequent ist.
Im Grunde wirkt das alles doppelt gemoppelt ;) Und grad, wenn an anderer Stelle zuliebe der Performance vermieden wird Objekte zu erzeugen, wirkt es etwas paradox, wenn sich dann innerhalb der Methoden auffällig mehr Code zur Parameter-Validierung, als zur Logik selbst befindet. Schließlich wird dieser Validierungs bei jeden einzelnen Methodenaufruf ausgeführt. Als passende Anekdote: setClassLoader() enthält fast 30 Zeilen Validierungscode und genau eine Zuweisung :rolleyes:

Ich weiß nicht, ob du schonmal mit Python zu tun hattest, aber dort begegnete es mir häufiger, dass Methodenaufrufe eben Fehler und keine Exceptions lieferten. Dort ist es verbreitet, dass man davon ausgeht, das Entwickler Dokumentationen lesen können :rolleyes:
Und das Konzept sagt mir zumindest mehr zu: Man kann doch erwarten, dass die eigene Komponente richtig verwendet, wenn man sich schon die Mühe macht sie zu dokumentieren. Es geht hier ja nicht um irgendwelche Benutzer, sondern um (hoffentlich ;)) richtige Entwickler.
 
Zuletzt bearbeitet:
Oben