1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
|
<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: 19711 -->
<appendix id="project-structure">
<title>Empfohlene Projektstruktur für Zend Framework MVC Anwendungen</title>
<sect1 id="project-structure.overview">
<title>Übersicht</title>
<para>
Viele Entwickler suchen Hilfe für die beste Projektstruktur für ein Zend Framework
Projekt in einer relativ flexiblen Umgebung. Eine "flexible" Umgebung ist eine, in
welcher der Entwickler seine Dateisysteme und Konfigurationen des Webservers wie
benötigt manipulieren kann, um die ideale Projektstruktur zu erhalten, damit die
Anwendungen ausgeführt werden können und sicher sind. Die standardmäßige Projektstruktur
stellt sicher, dass der Entwickler diese Flexibilität zu seiner Verfügung hat.
</para>
<para>
Die folgende Verzeichnisstruktur ist für komplexe Projekte maximal
erweiterbar, wärend sie eine einfache Teilmenge von Verzeichnissen und Dateien
für Projekte mit einfacheren Anforderungen anbietet. Diese Struktur funktioniert auch
ohne Änderung sowohl für modulare und nicht-modulare Zend Framework Anwendungen. Die
<filename>.htaccess</filename>-Dateien benötigen <acronym>URL</acronym> Rewrite
Funktionalität im Web Server wie im
<link linkend="project-structure.rewrite">Leitfaden für die Rewrite Konfiguration</link>
beschrieben, der auch in diesem Anhang enthalten ist.
</para>
<para>
Es ist nicht angedacht, dass diese Projektstruktur alle möglichen Anforderungen für
Zend Framework Projekte unterstützt. Das standardmäßige Projektprofil, welches von
<classname>Zend_Tool</classname> verwendet wird, reflektiert diese Projektstruktur.
Aber Anwendungen mit Anforderungen, die nicht von dieser Struktur unterstützt werden,
sollten ein angepasstes Projektprofil verwenden.
</para>
</sect1>
<sect1 id="project-structure.project">
<title>Empfohlene Verzeichnisstruktur für Projekte</title>
<programlisting language="text"><![CDATA[
<project name>/
application/
configs/
application.ini
controllers/
helpers/
forms/
layouts/
filters/
helpers/
scripts/
models/
modules/
services/
views/
filters/
helpers/
scripts/
Bootstrap.php
data/
cache/
indexes/
locales/
logs/
sessions/
uploads/
docs/
library/
public/
css/
images/
js/
.htaccess
index.php
scripts/
jobs/
build/
temp/
tests/
]]></programlisting>
<para>
Nachfolgend ist der Verwendungszweck für jedes Verzeichnis aufgeführt.
</para>
<itemizedlist>
<listitem>
<para>
<emphasis><filename>application/</filename></emphasis>: Das Verzeichnis enthält
die eigentliche Anwendung. Das wird das <acronym>MVC</acronym> System einschliessen,
sowie Konfigurationen, verwendete Services, und die eigene Bootstrap Datei.
</para>
<itemizedlist>
<listitem>
<para>
<emphasis><filename>configs/</filename></emphasis>: Das anwendungsweite
Konfigurationsverzeichnis.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>controllers/</filename></emphasis>,
<emphasis><filename>models/</filename></emphasis>, und
<emphasis><filename>views/</filename></emphasis>: Diese Verzeichnisse
fungieren als Standardcontroller, Modell oder View Verzeichnisse.
Diese drei Verzeichnisse im Anwendungsverzeichnis zu haben bietet das
beste Layout für das Starten eines einfachen Projekts sowie als Start
eines modularen Projekts das globale
<filename>controllers/models/views</filename> hat.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>controllers/helpers/</filename></emphasis>: Diese
Verzeichnisse enthalten Action Helfer. Action Helfer haben entweder
einen Namespace von "<classname>Controller_Helper_</classname>" im
Standardmodul oder "<Module>_Controller_Helper" in anderen
Modulen.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>layouts/</filename></emphasis>: Dieses Layout
Verzeichnis ist für <acronym>MVC</acronym>-basierte Layouts. Da
<classname>Zend_Layout</classname> in der Lage ist
<acronym>MVC</acronym>- und nicht-<acronym>MVC</acronym>-basierte
Layouts zu verstehen, zeigt der Ort dieses Verzeichnisses das Layouts
keine 1-zu-1 beziehung zu Controllern haben und unabhängig von
Templates in <filename>views/</filename> sind.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>modules/</filename></emphasis>: Module erlauben
einem Entwickler ein Set von zusammengehörenden Controllern in eine
logisch organisierte Gruppe zu gruppieren. Die Struktur im Modules
Verzeichnis würde die Struktur des Application Verzeichnisses haben.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>services/</filename></emphasis>: Dieses Verzeichnis
ist für eigene anwendungsspezifische Web-Service Dateien, welche von der
eigenen Anwendung angeboten werden, oder für die Implementierung eines
<ulink
url="http://www.martinfowler.com/eaaCatalog/serviceLayer.html">Service
Layers</ulink> für eigene Modelle.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>Bootstrap.php</filename></emphasis>: Diese Datei ist
der Eistiegspunkt für die eigene Anwendung, und sollte
<classname>Zend_Application_Bootstrap_Bootstrapper</classname>
implementieren. Das Ziel dieser Datei ist es, die Anwendung zu starten und
Komponenten der Anwendung zur Verfügung zu stellen, indem diese
initialisiert werden.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
<emphasis><filename>data/</filename></emphasis>: Dieses Verzeichnis bietet einen
Ort an dem Anwendungsdaten gespeichert werden, die angreifbar und möglicherweise
temporär sind. Die Veränderung von Daten in diesem Verzeichnis kann dazu führen,
dass die Anwendung fehlschlägt. Die Informationen in diesem Verzeichnis können,
oder auch nicht, in ein Subversion Repository übertragen werden. Beispiele von
Dingen in diesem Verzeichnis sind Session Dateien, Cache Dateien, SQLite
Datenbanken, Logs und Indizes.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>docs/</filename></emphasis>: Dieses Verzeichnis enthält die
Dokumentation, entweder erzeugt oder direkt bearbeitet.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>library/</filename></emphasis>: Dieses Verzeichnis ist für
übliche Bibliotheken, von denen die Anwendung abhängt, und es sollte im
<property>include_path</property> von <acronym>PHP</acronym> sein. Entwickler
sollten den Bibliotheks-Code ihrer Anwendung in diesem Verzeichnis, unter einem
eindeutigen Namespace platzieren, und den Richtlinien folgen, die im Handbuch von
<acronym>PHP</acronym> unter <ulink
url="http://www.php.net/manual/de/userlandnaming.php">Userland Naming
Guide</ulink> beschrieben sind, sowie denen, die von Zend selbst beschrieben
sind. Dieses Verzeichnis kann auch das Zend Framework selbst enthalten; wenn
dem so ist, würde es unter <filename>library/Zend/</filename> platziert werden.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>public/</filename></emphasis>: Dieses Verzeichnis enthält
alle öffentlichen Dateien für die eigene Anwendung.
<filename>index.php</filename> konfiguriert und startet
<classname>Zend_Application</classname>, welche seinerseits die Datei
<filename>application/Bootstrap.php</filename> startet, was dazu führt, dass der
Front Controller ausgeführt wird. Das DocumentRoot des Web Server sollte
typischerweise auf dieses Verzeichnis gesetzt sein.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>scripts/</filename></emphasis>: Dieses Verzeichnis enthält
Maintenance und/oder Build Skripte. Solche Skripte können Commandline, Cron oder
Phing Build Skripte enthalten, die nicht wärend der Laufzeit ausgeführt werden,
aber Teil für das korrekte Funktionieren der Anwendung sind.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>temp/</filename></emphasis>: Das <filename>temp/</filename>
Verzeichnis wird für vergängliche Anwendungsdaten verwendet. Diese Information
würde typischerweise nicht im SVN Repository der Anwendung gespeichert werden.
Wenn Daten im <filename>temp/</filename> Verzeichnis gelöscht werden, sollten
Anwendungsen dazu in der Lage sein, weiterhin zu laufen, wärend das möglicherweise
die Geschwindigkeit reduziert bis die Daten wieder gespeichert oder neu
gecacht sind.
</para>
</listitem>
<listitem>
<para>
<emphasis><filename>tests/</filename></emphasis>: Dieses Verzeichnis enthält
Anwendungstests. Diese würden hand-geschrieben sein, PHPUnit Tests, Selenium-RC
basierte Tests oder basierend auf anderen Test Frameworks. Standardmäßig kann
Library Code getestet werden, indem die Verzeichnisstruktur des
<filename>library/</filename> Verzeichnisses vorgegaukelt wird. Zusätzliche
funktionale Tests für die eigene Anwendung können geschrieben werden, indem die
Verzeichnisstruktur von <filename>application/</filename> vorgegaukelt wird
(inklusive der Unterverzeichnisse der Anwendung).
</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="project-structure.filesystem">
<title>Modul-Struktur</title>
<para>
Die Verzeichnisstruktur für Module sollte jener des
<filename>application/</filename> Verzeichnisses in der vorgeschlagenen Projektstruktur
entsprechen:
</para>
<programlisting language="text"><![CDATA[
<modulename>/
configs/
application.ini
controllers/
helpers/
forms/
layouts/
filters/
helpers/
scripts/
models/
services/
views/
filters/
helpers/
scripts/
Bootstrap.php
]]></programlisting>
<para>
Der Zweck dieses Verzeichnisse bleibt exakt der gleiche wie der für die vorgeschlagene
Verzeichnisstruktur des Projekts.
</para>
</sect1>
<sect1 id="project-structure.rewrite">
<title>Leitfaden für die Rewrite Konfiguration</title>
<para>
<acronym>URL</acronym> Rewriting ist eine der üblichen Funktionen von
<acronym>HTTP</acronym> Servern. Trotzdem unterscheiden sich die Regeln und die
Konfiguration zwischen ihnen sehr stark. Anbei sind einige der üblichen Vorschläge
für eine Vielzahl der populären Webserver zu finden, die zur der Zeit in der das hier
geschrieben wurde, vorhanden sind.
</para>
<sect2 id="project-structure.rewrite.apache">
<title>Apache HTTP Server</title>
<para>
Alle folgenden Beispiel verwenden <property>mod_rewrite</property>, ein offizielles
Modul, das zusammen mit Apache kommt. Um es zu verwenden, muss
<property>mod_rewrite</property> entweder wärend der Zeit des Kompilierens enthalten
sein, oder als Dynamic Shared Objekt (<acronym>DSO</acronym>) aktiviert werden.
Konsultieren Sie bitte die
<ulink url="http://httpd.apache.org/docs/">Apache Dokumentation</ulink> für weitere
Informationen über Ihre Version.
</para>
<sect3 id="project-structure.rewrite.apache.vhost">
<title>Rewriting innerhalb eines VirtualHost</title>
<para>
Hier ist eine sehr grundsätzliche Definition eines virtuellen Hosts. Diese
Regeln leiten alle Anfragen auf <filename>index.php</filename> weiter, ausser
wenn eine passende Datei im <property>document_root</property> gefunden wurde.
</para>
<programlisting language="text"><![CDATA[
<VirtualHost my.domain.com:80>
ServerName my.domain.com
DocumentRoot /path/to/server/root/my.domain.com/public
RewriteEngine off
<Location />
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]
</Location>
</VirtualHost>
]]></programlisting>
<para>
Es ist der Schrägstrich ("/") zu beachten der <filename>index.php</filename>
vorangestellt ist; die Regeln für <filename>.htaccess</filename> unterscheiden
sich in diesem Punkt.
</para>
</sect3>
<sect3 id="project-structure.rewrite.apache.htaccess">
<title>Rewriting innerhalb einer .htaccess Datei</title>
<para>
Anbei ist eine einfache <filename>.htaccess</filename> Datei welche
<property>mod_rewrite</property> verwendet. Das ist ähnlich der Konfiguration
für virtuelle Hosts, ausser dass sie nur die Rewrite Regeln spezifiziert, und der
führende Schrägstrich bei <filename>index.php</filename> nicht angegeben wird.
</para>
<programlisting language="text"><![CDATA[
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
]]></programlisting>
<para>
Es gibt viele Wege um <property>mod_rewrite</property> zu konfigurieren; wenn
man weitere Informationen haben will, dann sollte man in Jayson Minards
<ulink url="http://devzone.zend.com/a/70">Blueprint for PHP Applications:
Bootstrapping</ulink> sehen.
</para>
</sect3>
</sect2>
<sect2 id="project-structure.rewrite.iis">
<title>Microsoft Internet Information Server</title>
<para>
Ab Version 7.0 wird <acronym>IIS</acronym> jetzt mit einer standardmäßigen Rewrite
Engine ausgeliefert. Man kann die folgende Konfiguration verwenden, um die
entsprechenden Rewrite Regeln zu erstellen.
</para>
<programlisting language="xml"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Imported Rule 1" stopProcessing="true">
<match url="^.*$" />
<conditions logicalGrouping="MatchAny">
<add input="{REQUEST_FILENAME}"
matchType="IsFile" pattern=""
ignoreCase="false" />
<add input="{REQUEST_FILENAME}"
matchType="IsDirectory"
pattern=""
ignoreCase="false" />
</conditions>
<action type="None" />
</rule>
<rule name="Imported Rule 2" stopProcessing="true">
<match url="^.*$" />
<action type="Rewrite" url="index.php" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
]]></programlisting>
</sect2>
</sect1>
</appendix>
|
