2
0

Zend_Tool_Framework-WritingProviders.xml 5.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 15617 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="zend.tool.framework.writing-providers">
  5. <title>Erstellen von Providern für die Verwendung mit Zend_Tool_Framework</title>
  6. <para>
  7. Generell ist ein Provider für sich selbst nichts mehr als die Shell für einen Entwickler
  8. um einige Fähigkeiten zu bündeln die man mit dem Kommandozeilen (oder einem anderen)
  9. Client ausliefern will. Das ist analog zu dem was ein "Controller" in einer MVC Anwendung
  10. ist.
  11. </para>
  12. <sect2 id="zend.tool.framework.writing-providers.basic">
  13. <title>Grundsätzliche Anweisungen für die Erstellung von Providern</title>
  14. <para>
  15. Wenn, als Beispiel, ein Entwickler die Fähigkeit hinzufügen will, die Version einer
  16. Datendatei anzuzeigen, mit der seine 3rd Party Komponente arbeitet, gibt es nur eine
  17. Klasse die der Entwickler implementieren muss. Angenommen die Komponente heisst
  18. <code>My_Component</code>, dann würde er eine Klasse erstellen die
  19. <code>My_Component_HelloProvider</code> heisst und in einer Datei ist die
  20. <code>HelloProvider.php</code> heisst und irgendwo im <code>include_path</code> ist.
  21. Diese Klasse würde <classname>Zend_Tool_Framework_Provider_Interface</classname>
  22. implementieren, und der Body dieser Datei würde nur wie folgt auszusehen haben:
  23. </para>
  24. <programlisting language="php"><![CDATA[
  25. class My_Component_HelloProvider
  26. implements Zend_Tool_Framework_Provider_Interface
  27. {
  28. public function say()
  29. {
  30. echo 'Hallo von meinem Provider!';
  31. }
  32. }
  33. ]]></programlisting>
  34. <para>
  35. Durch den obigen Code, und der Annahme das der Entwickler den Zugriff auf diese
  36. funktionalität über den Consolen Client will, würde der Aufruf wie folgt aussehen:
  37. </para>
  38. <programlisting language="sh"><![CDATA[
  39. % zf say hello
  40. Hello from my provider!
  41. ]]></programlisting>
  42. </sect2>
  43. <sect2 id="zend.tool.framework.writing-providers.advanced">
  44. <title>Fortgeschrittene Informationen für die Entwicklung</title>
  45. <para>
  46. Das obige "Hello World" Beispiel ist perfekt für einfache Kommandos, aber was ist mit
  47. etwas fortgeschrittenerem? Wenn das Scripting und Tooling wächst, kann die
  48. Notwendigkeit entstehen Variablen zu akzeptieren. So wie Signaturen von Funktionen
  49. Parameter haben, kann eine Tooling Anfrage auch Parameter akzeptieren.
  50. </para>
  51. <para>
  52. So wie jede Tooling Anfrage in einer Methode in einer Klasse isoliert werden kann,
  53. können die Parameter einer Tooling Anfrage auch in einem sehr bekannten Platz isoliert
  54. werden. Parameter von Action Methoden eines Providers können die selben Parameter
  55. enthalten die man im Client verwenden will, wenn man den Namen im obigen Beispiel
  56. akzeptieren will, und man würde das in OO Code warscheinlich wie folgt tun:
  57. </para>
  58. <programlisting language="php"><![CDATA[
  59. class My_Component_HelloProvider
  60. implements Zend_Tool_Framework_Provider_Interface
  61. {
  62. public function say($name = 'Ralph')
  63. {
  64. echo 'Hallo' . $name . ', von meinem Provider!';
  65. }
  66. }
  67. ]]></programlisting>
  68. <para>
  69. Das obige Beispiel kann pber di Kommandozeile wie folgt aufgerufen werden:
  70. <code>zf say hello Joe</code>. "Joe" wird dem Provider als Parameter des
  71. Methodenaufrufs zur Verfügung gestellt. Es ist auch zu beachten das der Parameter
  72. optional ist, was bedeutet das er auch auf der Kommandozeile optional ist, so das
  73. <code>zf say hello</code> weiterhin funktioniert, und der Standardname "Ralph" ist.
  74. </para>
  75. <para>
  76. Ein anderes interessantes Feature das man implementieren kann ist
  77. <emphasis>Voranstellbarkeit</emphasis>. Voranstellbarkeit ist die Fähigkeit des
  78. Providers "Voranzustellen" wie wenn er die angefragte Aktion und Provider
  79. Kombination ausführt, und dem Benutzer so viel Information wie möglich darüber gibt
  80. was er tun <emphasis>würde</emphasis> ohne es wirklich zu tun. Das kann eine wichtige
  81. Option sein wenn viele Datenbank oder Dateisystem Änderungen durchzuführen sind, die
  82. der Benutzer andernfalls nicht tun würde.
  83. </para>
  84. <para>
  85. Voranstellbarkeit ist einfach zu implementieren. Es gibt zwei Teile dieses Features:
  86. 1) Markieren des Providers, das er die Fähigkeit des "voranstellens" hat und 2) prüfen
  87. der Anfrage um Sicherzustellen das die aktuelle Anfrage wirklich das "voranstellen"
  88. angefragt hat. Dieses Feature wird im nächsten Code Beispiel demonstriert.
  89. </para>
  90. <programlisting language="php"><![CDATA[
  91. class My_Component_HelloProvider
  92. extends Zend_Tool_Framework_Provider_Abstract
  93. implements Zend_Tool_Framework_Provider_Pretendable
  94. {
  95. public function say($name = 'Ralph')
  96. {
  97. if ($this->_registry->getRequest()->isPretend()) {
  98. echo 'Ich würde zu ' . $name . ' hallo sagen.';
  99. } else {
  100. echo 'Hallo' . $name . ', von meinem Provider!';
  101. }
  102. }
  103. }
  104. ]]></programlisting>
  105. </sect2>
  106. </sect1>