Hilfe für APF-Neuling

Hier finden sich Fragen und Ergänzung zur Dokumentation. // All questions and discussions about the documentation.
Antworten
Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 04.02.2009, 06:28:23

Moin moin!

Ich habe nun mal angefangen, mich in das APF einzulesen und bin bereits jetzt ein bisschen begeistert, was das APF wirklich leisten kann. Allerdings sind mir beim Lesen der Dokumentation die vielen Querverweise und verschiedenen Dokumentationen etwas sauer aufgeschlagen. Mein größtes Problem ist wohl, dass ich mich nie mit den verschiedenen "Schichten" (Datenschicht, Präsentationsschicht, Businessschicht, etc.) auseinandersetzen musste. Ebenso mangelt es mir an Erfahrung mit Dignen wie dem MVC und dem Sinn der verschiedenen Controller, die es hier gibt. Ich kann immernoch nicht vernünftig unterscheiden, was der Vorteil ist, einen PageController und einen DocumentController zu besitzen und wozu diese genutzt werden. Vielleicht geht das aus der Dokumentation ja hervor, jedoch bin ich etwas überrumpelt von den vielen Querverweisen ("Dies und das wird da und da näher beschrieben", etc.).

Es wäre schön, wenn jemand auf einfache Weise erklären könnte, was es mit dem Obigen auf sich hat.

Es werden wahrscheinlich noch mehr Fragen kommen, aber ein paar Dinge versuche ich erstmal zu erlesen, bevor ich hier komplett alles erfrage, was in der Doku für mich wenigstens halbwegs nachvollziehbar erklärt wurde :)

MfG

Lutz
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4605
Registriert: 04.11.2007, 16:13:53

Re: Hilfe für APF-Neuling

Beitrag von dr.e. » 04.02.2009, 16:19:53

Hallo Lutz,

wie auch schon per PN gesagt: wenn du Fehler in der Dokumentation findest, dann einfach im "Dokumentation"-Forum posten, ich bessere diese dann gleich aus.

Nun zu deinen Fragen:
Ich habe nun mal angefangen, mich in das APF einzulesen und bin bereits jetzt ein bisschen begeistert, was das APF wirklich leisten kann.
Schön. Das Design des Frameworks setzt auf einen starken Kern und einfache Erweiterbarkeit.
Allerdings sind mir beim Lesen der Dokumentation die vielen Querverweise und verschiedenen Dokumentationen etwas sauer aufgeschlagen.
Die Querverweise sind absichtlich eingebaut um die Verwebung der Komponenten und Funktionen zu verdeutlichen. Welche verschiedene Dokumentationen meinst du? Die verschiedenen Kapitel?
Mein größtes Problem ist wohl, dass ich mich nie mit den verschiedenen "Schichten" (Datenschicht, Präsentationsschicht, Businessschicht, etc.) auseinandersetzen musste. Ebenso mangelt es mir an Erfahrung mit Dingen wie dem MVC und dem Sinn der verschiedenen Controller, die es hier gibt. Ich kann immernoch nicht vernünftig unterscheiden, was der Vorteil ist, einen PageController und einen DocumentController zu besitzen und wozu diese genutzt werden.
OK, ich denke, hier sollte ich nochmal den Zweck der beiden Komponenten und deren Einsatzgebiet erläutern:
Die Idee des Page-Controllers ist, einen allgemeingültigen und wiederverwendbaren MVC-Helfer bereit zu stellen. Grund ist der, dass die Trennung in die Bereiche Model, View und Controller zwar sinnvoll ist, möchte man jedoch eine zweite Applikation oder ein zweites Modul nach MVC erstellen, so müssen die dafür notwendigen Mechanismen (Entgegennahme des Requests, Laden eines Views, ausführen eines Controllers, ...) in der Bootstrap-Datei nochmals nachempfunden werden. Hier kommt der Page-Controller zum Einsatz. Er kümmert sich um die Bereitstellung einer MVC-Umgebung und übernimmt die Verwaltung (Aufbau + Transformation) des APF-DOM-Baumes, der aus konkreten MVC-Einheiten aufgebaut ist. Du kannst dir also vorstellen, dass er im Speicher einen Objektbaum aus lauter kleinen MVC-Kapseln erzeugt, aus denen bei der Transformation HTML-Code erzeugt wird. Durch die Möglichkeit viele dieser Einheiten anlegen/erzeugen zu können, kannst du maximal effizient strukturieren.
Eine einzelne Einheit besteht aus einer Template-Datei, die verschiedene XML-Tags mit entsprechenden Funktionen beinhaltet, und - wahlweise - einem Document-Controller. Der Name heißt desswegen Document-Controller, da ein Knoten des Baumes auch als Document bezeichnet werden kann. Der Unterschied zwischen den beiden Controllern ist, dass der Page-Controller bereits so generisch ausgelegt ist, dass du ihn für jeden Anwendungsfall parat hast, der Document-Controller bildet die Logik ab, die du in deiner Applikation brauchst. Die Anzahl der Knoten des Baumes und die Funktion der Document-Controller definierst dabei du selbst. In den Templates dadurch, dass du z.B. weitere "Unter-Templates" einbindest, in den Controllern durch den PHP-Code den du schreibst.

Kurz zusammen gefasst: der Page-Controller stellt dir die MVC- und APF-Framework-Umgebung bereit, Document-Controller implementieren die Funktion einer konkreten Applikation bzw. eines konkreten Moduls.
Es werden wahrscheinlich noch mehr Fragen kommen, aber ein paar Dinge versuche ich erstmal zu erlesen, bevor ich hier komplett alles erfrage, was in der Doku für mich wenigstens halbwegs nachvollziehbar erklärt wurde :)
Das ist kein Problem. Schau dir am Besten mal die beiden Tutorials an, diese sollten dir den Einstieg erleichtern:
Viele Grüße,
Christian
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 05.02.2009, 07:21:02

Danke soweit schonmal! Ich habe gestern noch eine Webseite in Englisch zu dem Thema gelesen, die irgendwo querverlinkt war und die hat mir auf eine ähnlich einfache Weise den Unterschied zwischen Front- und Page-Controller aufgezeigt, das hat mir auch schonmal geholfen.

Mit "verschiedenen Dokumentationen" meine ich die 3 unterschiedlichen CHMs, die du zum Download anbietest. Irgendwie kapiere ich nicht, warum das nicht in eine Datei zusammengefasst wurde!?

EDIT:

Auf: http://adventure-php-framework.org/Seite/013-Grundlagen
- "Model-View-Controller-Pattern": "enthßlt" -> "enthält"
- "3-Schicht-Architektur": Verständnisfrage: Ist die Datenschicht wirklich nur zum Lesen von Daten da oder kann diese - z.B. bei einer Datenbank als Quelle - auch schreiben? Wenn dem so ist, dann ist der letzte Satz vielleicht etwas missverständlich!?
- "Der Ordner modules ist dazu gedacht, auf den core- und tools-Komponenten aufsetzende Module aufzunehmen, die entweder im Release enthalten sind (z.B. Gästebuch, Kontaktformular) oder von Ihnen implementierte Module zum Einsatz in Webseiten oder Web-Applikation." -> Fehlt da noch ein "sind" am Ende des Satzes? Klingt sonst irgendwie so wie "Dieser Satz kein Verb"...
- "Die Bootstrap-Datei läd das Template, [...]" -> "Die Bootstrap-Datei lädt das Template, [...]"
- "Abstrakter betrachtet ist dabei Knoten einer Webseite eine kleine MVC-Einheit, [...]" -> "Abstrakter betrachtet ist dabei ein Knoten einer Webseite eine kleine MVC-Einheit, [...]"

Das war es soweit auf der Seite, was mir aufgefallen ist. Weitere Seiten folgen - sofern mir noch mehr ins Auge springt :)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 05.02.2009, 08:01:56

So, nochmal was Anderes, was nichts mit Fehlerkorrektur zu tun hat: Ich komme beim Kapitel Konfiguration ziemlich ins Schleudern. Ich weiß zwar, warum das ENVIRONMENT wichtig ist und in den Dateinamen mit einfließt, allerdings komme ich mit "Context" nicht so ganz mit. Gerade unter Kapitel 2.2 der Seite fange ich erst richtig an zu schleudern: Meine eigene Logik sagt mir, dass wenn ich eine Konfiguration laden will, als Namespace - was ja der Pfad sein soll - "modules::mymodule" (warum auch immer "::" zum Trennen von Ordnern verwendet wird!? Wegen der Unabhängigkeit vom Betriebssystem? Dann muss der erste Kasten unter 2.2 korrigiert werden!) und als Konfigurationsname "mymoduleconfig" verwende, ich erwarten kann, dass die Datei in folgendem Ordner gesucht wird: "modules/mymodule/DEFAULT_mymoduleconfig.ini". Stattdessen sehe ich hier, dass die Pfadangabe beim Laden als erster und der Namespace des Moduls als zweiter Pfadteil genutzt wird. Ist das wirklich so oder nur Fehler in der Beschreibung? Mir erschließt sich gerade nicht so richtig der Sinn dahinter!?

Grundsätzlich wäre es aber wohl auch nicht verkehrt auf "Namespace", "Context" und Co. noch näher einzugehen, denn jemand, der davon noch nie gehört hat kommt spätestens bei den recht knapp gehaltenen Beispielen ins schleudern - mir geht es zumindest so ;)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 05.02.2009, 08:20:39

Sorry, das soll kein Spam sein, ich versuche nur die Inhalte nach Seiten getrennt aufzulisten. Wenn ich das lieber in EINEM Beitrag machen soll: Sagt es einfach, dann tue ich das in Zukunft.

http://adventure-php-framework.org/Seit ... figuration
- "[...] wird an ein einigen Stellen [...]" -> "[...] wird an einigen Stellen [...]"
- "[...] kann ohne Performance-Einbußen beliebig [...]" -> "[...] kann ohne Performance-Einbuße beliebig [...]"
- "[...] eine Konfigurationsdatei aus viel unterschiedlichen Teilen [...]" -> "[...] eine Konfigurationsdatei aus vier unterschiedlichen Teilen [...]"
Könnte zwar auch "vielen" sein, der Kontext gibt hier aber ein "vier" eher her ;)
- "[...] in der alle Konfiguration einer Core-Klasse [...]" -> "[...] in der alle Konfigurationen einer Core-Klasse [...]"
- Verständnisfrage: Wenn der Namespace meist gleich dem Namespace des Moduls ist, widerspricht das aber der Behauptung im letzten Satz, dass Konfigurationen im Ordner "config" seien!? Oder wie darf man das verstehen? Ist etwas holprig für Leute, die das FW nicht kennen...
- "[...] Details und Dokumentation der Parameter finden sich in der API-Dokumentation." -> Wenn querverweise gewollt sind, fehlt hier einer!
- Verständnisfrage: Unter 4. wird beim Aufruf von getSection() eine Rückgabe erzeugt, bei der der Name der Sektion noch enthalten ist. Macht das Sinn oder ist das ein C&P-Fehler? Ich würde ein eindimensionales Array erwarten, zumal getValue('Section2', 'Key1') ja auch nur den Wert ausließt und nicht: Array ( [Section2] => Array ( [Key1] => [Value1] ) )
- Bei der Trennung des Satzes klingt es einfach falsch, dass das Verb bereits im ersten Teil der Aufzählung genannt wird.
"Wurde die verwendete Konfigurations-Datei mit den Werten [-] gefüllt, so kann mit dem PHP-Code [-] das komplette Konfigurations-Array [-] ausgegeben werden, mit [-] das Array [-] und mit [-] der Wert [-] ." -> "Wurde die verwendete Konfigurations-Datei mit den Werten [-] gefüllt, so kann mit dem PHP-Code [-] das komplette Konfigurations-Array [-] , mit [-] das Sektions-Array [-] und mit [-] der Wert [-] ausgegeben werden."
- "notwenig" -> "notwendig"
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4605
Registriert: 04.11.2007, 16:13:53

Re: Hilfe für APF-Neuling

Beitrag von dr.e. » 05.02.2009, 19:53:23

Hallo Lutz,

danke für deine Korrekturen und Anmerkungen. Da ich gestern Abend leider nicht mehr online war, hier meine Antworten step-by-step:
Auf: http://adventure-php-framework.org/Seite/013-Grundlagen
- "Model-View-Controller-Pattern": "enthßlt" -> "enthält"
Erledigt, stelle ich nachher online.
- "3-Schicht-Architektur": Verständnisfrage: Ist die Datenschicht wirklich nur zum Lesen von Daten da oder kann diese - z.B. bei einer Datenbank als Quelle - auch schreiben? Wenn dem so ist, dann ist der letzte Satz vielleicht etwas missverständlich!?
An sich ist die Datenschicht zum Verwalten der Daten (=Lesen und Schreiben) gedacht. Ich habe den letzten Satz deshalb angepasst.
- "Der Ordner modules ist dazu gedacht, auf den core- und tools-Komponenten aufsetzende Module aufzunehmen, die entweder im Release enthalten sind (z.B. Gästebuch, Kontaktformular) oder von Ihnen implementierte Module zum Einsatz in Webseiten oder Web-Applikation." -> Fehlt da noch ein "sind" am Ende des Satzes? Klingt sonst irgendwie so wie "Dieser Satz kein Verb"...
Nein, das passt grammatikalisch. Damit es schöner klingt, habe ich es noch ein wenig hübscher ausgedrückt.
- "Die Bootstrap-Datei läd das Template, [...]" -> "Die Bootstrap-Datei lädt das Template, [...]"
Done.
- "Abstrakter betrachtet ist dabei Knoten einer Webseite eine kleine MVC-Einheit, [...]" -> "Abstrakter betrachtet ist dabei ein Knoten einer Webseite eine kleine MVC-Einheit, [...]"
Done.
Ich weiß zwar, warum das ENVIRONMENT wichtig ist und in den Dateinamen mit einfließt, allerdings komme ich mit "Context" nicht so ganz mit. Gerade unter Kapitel 2.2 der Seite fange ich erst richtig an zu schleudern: Meine eigene Logik sagt mir, dass wenn ich eine Konfiguration laden will, als Namespace - was ja der Pfad sein soll - "modules::mymodule" (warum auch immer "::" zum Trennen von Ordnern verwendet wird!? Wegen der Unabhängigkeit vom Betriebssystem? Dann muss der erste Kasten unter 2.2 korrigiert werden!)
Namespaces werden einfach per Konvention statt mit "/" mit "::" getrennt. Das hat nichts zu bedeuten, es ist einfach ein Trennzeichen per Konvention. Die Adressierung einer Konfigurationsdatei setzt sich aus fünf verschiedenen Bestandteilen zusammen:
  • Standard-Ordner für Konfigurationen: config. Dieser erste Pfad-Abschnitt wird per Konvention so definiert. Grund: Trennung von Code und Konfiguration.
  • Gewünschter Namespace. Dieser Abschnitt ist meist identisch zum Namespace unter dem das Modul/Tool/Applikation abgelegt ist. Es definiert sozusagen die Zugehörigkeit der darunterliegenden Konfigurationen zum betreffenen Modul/Tool/Applikation.
  • Der Context unter dem die Anwendung läuft. Das APF ist hinsichtlich der Konfiguration so ausgelegt, dass ein Modul/Tool in mehreren Applikationen eingebunden werden kann. Das bedeutet, dass eine Unterscheidung getroffen werden muss, in welchem Umfeld dieses gerade läuft um dafür spezialisierte Konfigurationen laden zu können. Dazu ist der Context verantwortlich. Er separiert im Namespace-Ordner nochmals die einzelnen Konfigurationen für die unterschiedlichen Einsatzorte des Moduls. So kannst du mit einer Code-Basis beliebige Applikationen betreiben, was du sonst nur durch Kopieren des Code-Stammes erreichst.
  • Die Umgebung (=Environment) ist Teil des Datei-Namens und bestimmt innerhalb eines Einsatzgebietes noch die Umgebung, in der das Modul/Tool eingesetzt ist. Damit kannst du ohne Änderung der Applikation ein Modul deployen, da du für unterschiedliche Umgebungen (Development/Test/Live) vorhälst.
  • Der Name der Datei bildet den Rumpf der Konfigurationsdatei. Die Endung ist "ini".
Mit diesen Konfigurationsparametern ist es nun möglich maximal wiederverwendbare Applikationen und Module zu schreiben, da alle Fälle des Einsatzes abgedeckt werden.
und als Konfigurationsname "mymoduleconfig" verwende, ich erwarten kann, dass die Datei in folgendem Ordner gesucht wird: "modules/mymodule/DEFAULT_mymoduleconfig.ini". Stattdessen sehe ich hier, dass die Pfadangabe beim Laden als erster und der Namespace des Moduls als zweiter Pfadteil genutzt wird. Ist das wirklich so oder nur Fehler in der Beschreibung? Mir erschließt sich gerade nicht so richtig der Sinn dahinter!?
Das ist kein Fehler, das ist exakt so beabsichtigt. Allgemein folgt die Bennenung von Konfigurationsdateien folgender Syntax:

Code: Alles auswählen

/config/<Namespace>/<Context>/<Environment>_<ConfigFileName>.ini
Grundsätzlich wäre es aber wohl auch nicht verkehrt auf "Namespace", "Context" und Co. noch näher einzugehen, denn jemand, der davon noch nie gehört hat kommt spätestens bei den recht knapp gehaltenen Beispielen ins schleudern - mir geht es zumindest so ;)
Der Begriff Namespace ist in der JAVA- und C#-Welt gebräuchlicher, ich nutze das beim APF um eine gemeinsame Adressierung von Komponenten und Konfigurationen zu ermöglichen. Der Context wird verwendet um das Umfeld einer Applikation zu beschreiben.
"[...] wird an ein einigen Stellen [...]" -> "[...] wird an einigen Stellen [...]"
Done.
- "[...] kann ohne Performance-Einbußen beliebig [...]" -> "[...] kann ohne Performance-Einbuße beliebig [...]"
Done.
- "[...] eine Konfigurationsdatei aus viel unterschiedlichen Teilen [...]" -> "[...] eine Konfigurationsdatei aus vier unterschiedlichen Teilen [...]"
Done.
- "[...] in der alle Konfiguration einer Core-Klasse [...]" -> "[...] in der alle Konfigurationen einer Core-Klasse [...]"
Done.
- Verständnisfrage: Wenn der Namespace meist gleich dem Namespace des Moduls ist, widerspricht das aber der Behauptung im letzten Satz, dass Konfigurationen im Ordner "config" seien!? Oder wie darf man das verstehen? Ist etwas holprig für Leute, die das FW nicht kennen...
Das ist etwas unglücklich formuliert. Wie oben beschrieben fügt der configurationManager aus Konventionsgründen noch ein config vor dem Namespace ein. Ich habe das in der Doku etwas umformuliert, so dass es klarer wird.
- "[...] Details und Dokumentation der Parameter finden sich in der API-Dokumentation." -> Wenn querverweise gewollt sind, fehlt hier einer!
Done.
- Verständnisfrage: Unter 4. wird beim Aufruf von getSection() eine Rückgabe erzeugt, bei der der Name der Sektion noch enthalten ist. Macht das Sinn oder ist das ein C&P-Fehler? Ich würde ein eindimensionales Array erwarten, zumal getValue('Section2', 'Key1') ja auch nur den Wert ausließt und nicht: Array ( [Section2] => Array ( [Key1] => [Value1] ) )
C&P-Fehler, du erhälst ein assoziatives Array mit den Konfigurationsdirektiven ohne Sektionsname. Ist ausgebessert.
- Bei der Trennung des Satzes klingt es einfach falsch, dass das Verb bereits im ersten Teil der Aufzählung genannt wird.
"Wurde die verwendete Konfigurations-Datei mit den Werten [-] gefüllt, so kann mit dem PHP-Code [-] das komplette Konfigurations-Array [-] ausgegeben werden, mit [-] das Array [-] und mit [-] der Wert [-] ." -> "Wurde die verwendete Konfigurations-Datei mit den Werten [-] gefüllt, so kann mit dem PHP-Code [-] das komplette Konfigurations-Array [-] , mit [-] das Sektions-Array [-] und mit [-] der Wert [-] ausgegeben werden."
Done.
- "notwenig" -> "notwendig"
Done.

Ich hoffe, ich konnte dir das Thema Konfiguration damit ein wenig näher bringen. :)

Viele Grüße,
Christian
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 05.02.2009, 20:57:54

Soweit erstmal vielen Dank für die Erklärung, das macht es mir doch schon etwas einfacher ;) Ich kam nur etwas durcheinander, wegen der Reihenfolge, in der die Informationen gegeben werden. Der Context ist ja schon vor dem Namespace bekannt, deshalb wirkte es auf mich etwas konfus. Nun habe ich es aber hoffentlich verstanden :)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 08.02.2009, 09:58:53

So, ich hatte mal wieder "langeweile" ;) Auch wenn einige Dinge vielleicht etwas klugscheißerisch oder kleinlich klingen mögen, möchte ich nur kurz was dazu sagen: Ich finde für ein professionelles Auftreten eines Web-Projekts ist eine saubere Formulierung ebenso notwendig, wie korrekte Rechtschreibung. Ich selber beherrsche sicher auch nicht alles, aber bitte seht mir nach, dass ich eben aus dem genannten Grund auch kleinste Fehler (die mir aufgefallen sind) mit anmerke :) -> Das bedeutet aber noch lange nicht, dass die Seite danach keine Fehler mehr enthält, ich bin schließlich auch kein Lektor :D

http://adventure-php-framework.org/Seit ... controller
- "Einführend Beispiele können [...]" -> "Einführende Beispiele können [...]"
- "[...] FrontController, die den Benutzer-Requests auswertet [...]" -> "[...] FrontController, die den Benutzer-Request auswertet [...]"
- "[...] die gemäß den später beschriebenen Timing Model ausgeführt werden." -> "[...] die gemäß dem später beschriebenen Timing Model ausgeführt werden."
oder -> "[...] die gemäß den später beschriebenen Timing Model(len|s) ausgeführt werden."
- "Zum einen muss eine Action- [...] , zum anderen muss [...]" -> "Zum Einen muss eine Action- [...] , zum Anderen muss [...]"
- "[...] von Aussen auf die [...]" -> "[...] von Außen auf die [...]"
Das "ß" ist entgegen der allgemeinen Auffassung nicht komplett aus dem deutschen Sprachraum entfernt worden! Bei scharf gesprochenem "s" wird es weiterhin verwendet, wie z.B. an dieser Stelle.
- "Name of der Datei [...]" -> Was soll ich dazu sagen ;)
- "[...] in URLs manupuliert werden [...]" -> "[...] in URLs manipuliert werden [...]"
- "Das Beispiel in Kapitel 1.4.2. hat den Nachteil [...]" -> Gemeint ist doch wohl Kapitel 2.4.2!? ebenso wie hier: "[...], wie in Kapitel 1.4.2"
- "Timing-Modell" -> "Timing-Model" (wird zumindest weiter oben so genannt; steht auch mehrfach falsch im Text!)
- "[...] ein eigenes vierstufiges [...]" -> "[...] ein eigenes, vierstufiges [...]"
- "[...] dem aktuellen Document zunächt [...]" -> "[...] dem aktuellen Document zunächst [...]"
- "[...] steuern und so die Verantwortung wird komplett an die Business-Schicht übergeben." -> entweder: "[...] steuern und so wird die Verantwortung komplett an die Business-Schicht übergeben." oder: "[...] steuern und die Verantwortung wird komplett an die Business-Schicht übergeben."
Ich würde jedoch zur zweiten Lösung tendieren, da "so" bereits im Satz weiter vorn vorhanden ist und es doppelt etwas doof klingt.

EDIT:

http://adventure-php-framework.org/Seite/016-Klassen
- "Author" -> "Autor"
- "Sie findet in der Index-Dateien Verwendung [...]" -> "Sie findet in der Index-Datei Verwendung [...]"
- "[...] ist es öglich [...]" -> "[...] ist es möglich [...]"
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4605
Registriert: 04.11.2007, 16:13:53

Re: Hilfe für APF-Neuling

Beitrag von dr.e. » 08.02.2009, 11:53:53

Hallo Lutz,

danke nochmals für deinen Input. Ich stimme dir zu, dass die Dokumentation hinsichtlich Semantik und Rechtschreibung korrekt sein muss, das ist nur kein leichtes Unterfangen. Deshalb bin ich für deinen Einsatz sehr dankbar!

Ich habe gerade alle geposteten Fehler beseitigt. IMHO ist jedoch
- "Zum einen muss eine Action- [...] , zum anderen muss [...]" -> "Zum Einen muss eine Action- [...] , zum Anderen muss [...]"
nach neuer Rechtschreibung gültig.

Noch eine wichtige Frage zum Schluss: wie kommst du - abgesehen von den Rechtschreibfehlern - mit dem Einlesen voran?

Viele Grüße,
Christian
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 08.02.2009, 13:22:16

Nunja, es ist schon recht schwierig, wenn man ohne großartige Kenntnisse im Umgang mit Frameworks an die Sache herangehen soll und die Querverweise machen es zumindest mir nicht gerade einfach die richtige Reihenfolge zu finden, in der ich die Kapitel durchlesen sollte, aber es geht schon. Im Groben habe ich die Bedeutung einiger Komponenten schon verstanden - denke ich. Auch wenn es immernoch etas kryptisch erscheint, wie manche Dinge gelöst werden können (bezieht sich auf FrontController, PageController, Actions, etc. das ist zum Teil sehr verwirrend). Aber ich denke, dass ich mit den Tutorials - sofern ich die Basics einigermaßen durch habe - schon noch dahinter kommen werde, wie das Framework arbeitet und welche Wege die Besten sein werden.

Zur Rechtschreibung: Ich kann das momentan leider nicht nachschlagen, da ich nicht genau weiß, wo sowas beschrieben steht, ich kenne es halt nur so, dass bei einem Artikel das Wort, auf das sich der Artikel bezieht, groß geschrieben wird. In meinen Augen macht das ja auch Sinn, aber wie ich bereits sagte bin ich kein Lektor und kann entsprechend nur nach bestem Wissen und Gewissen die Rechtschreibung korrigieren, es ist keine Garantie, dass es so dann auch richtig ist ;)

EDIT: Damit ich nicht immer so viele neue Beiträge produziere editiere ich den letzten Eintrag lieber, wenn noch nicht drauf geantwortet wurde:

http://adventure-php-framework.org/Seit ... h-Tutorial
- "[...] ein weiteres komplettes [...]" -> "[...] ein weiteres, komplettes [...]"
- "[...] nicht zu sehr in den Hintergrund rücken lässt." -> "[...] nicht zu sehr in den Hintergrund rückt."
- "[...] LÖschen)" -> "[...] Löschen)"
- "Modulerer Aufbau" -> "Modularer Aufbau"
- "[...] or create an new one." -> "[...] or create a new one." In der Grafik "Aktoren"
- "[...] der im Wesntlichen aus [...]" -> "[...] der im Wesentlichen aus [...]"
- "[...] in der dritten erweiterten dritten Normalform [...]" -> entweder: "[...] in der dritten, erweiterten Normalform [...]" oder: "[...] in der erweiterten dritten Normalform [...]" dazu bin ich nicht firm genug mit dem Thema Normalformen, um zu wissen, welche Bezeichnung die korrekte ist.
- Verständnisfrage: Warum wird ein Datenmodell genutzt, dass deutlich komplizierter ist, als es sein muss? Normalerweise kann es in Gästebüchern lediglich zu 1:n-Beziehungen kommen, wonach es reichen würde in der Entry-Tabelle ein Feld für die Gästebuch-ID und in der Comment-Tabelle ein Feld für die Entry-ID zu setzen, statt über zwei zusätzliche Tabellen zu gehen. Eine n:m-Beziehung, die hiermit möglich wäre ist eigentlich nicht gefordert und macht meiner Meinung nach das Thema etwas komplexer, als es sein müsste!?
- "[...] Gästebuch incl. alles aktuell geforderten Einträge und [...]" -> "[...] Gästebuch incl. aller aktuell geforderten Einträge und [...]"
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4605
Registriert: 04.11.2007, 16:13:53

Re: Hilfe für APF-Neuling

Beitrag von dr.e. » 08.02.2009, 23:00:32

Hallo Lutz,

die meiner Ansicht nach beste Reihenfolge ist durch die Navigation links vorgegeben. Zunächst sollten dir das Kapitel Grundlagen und das Hallo Welt!-Beispiel für den Einstieg reichen. Anschließend solltest du einfach selbst versuchen eine erste Seite zu bauen. Anschließend vielleicht noch etwas Stoff zu Templates und Controller lesen, dann bist du IMHO fit um deine erste Applikation zu bauen. Nur Dokumentation zu lesen führt zu längerer Einarbeitungszeit, den gewisse Dinge muss man einfach tun!

Interessant für dich ist sicher auch der Thread Minimales Modul mit dem APF erstellen. Dort steht einiges drin, was dir für den Start weiterhilft.

Die Fehler habe ich entsprechend korrigiert. Hier noch eine Anmerkung:
- "[...] in der dritten erweiterten dritten Normalform [...]" -> entweder: "[...] in der dritten, erweiterten Normalform [...]" oder: "[...] in der erweiterten dritten Normalform [...]" dazu bin ich nicht firm genug mit dem Thema Normalformen, um zu wissen, welche Bezeichnung die korrekte ist.
Das ist nach meinen Unterlagen korrekt.
- Verständnisfrage: Warum wird ein Datenmodell genutzt, dass deutlich komplizierter ist, als es sein muss? Normalerweise kann es in Gästebüchern lediglich zu 1:n-Beziehungen kommen, wonach es reichen würde in der Entry-Tabelle ein Feld für die Gästebuch-ID und in der Comment-Tabelle ein Feld für die Entry-ID zu setzen, statt über zwei zusätzliche Tabellen zu gehen. Eine n:m-Beziehung, die hiermit möglich wäre ist eigentlich nicht gefordert und macht meiner Meinung nach das Thema etwas komplexer, als es sein müsste!?
Das mag zunächst komplexer klingen als aktuell nötig, zusätzliche Tabellen zu nutzen um die Beziehungen zu speichern hat jedoch auch einige Vorteile. Diese liegen beim Gästebuch sicher nicht auf der Hand, bei komplexeren Datenmodellen jedoch schon. Wie du dein Gästebuch nun implementierst ist im Grunde auch zweitranging, so lange die Datenschicht dazu in der Lage ist, die von der Business-Schicht geforderte API bereitzustellen. Wenn du es also einfacher haben möchtest, kannst du auch mit FKs in der Tabelle der Einträge und Kommentare arbeiten. Letztlich ist das in diesem Fall Geschmacksache.
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 08.02.2009, 23:23:37

"dritte erweiterte dritte Normalform" soll richtig sein? Was ist denn das dann bitte :?: Klingt irgendwie falsch :!: :?: Ich weiß halt nur nicht, ob es eine "erweiterte, dritte" oder eine "dritte erweiterte Normalform" ist. Inhaltlich unterscheiden sich die Sätze ja voneinander und bekommen einen ganz anderen Kontext.

Ja, ich werde wohl doch einen Gang zurückschrauben müssen und mich einfach mal ins kalte Wasser fallen lassen und ein wenig rumexperimentieren. Ich habe auch schon feststellen müssen, dass man ziemlich schnell Konzentrationsprobleme bekommt, wenn man etliche Seiten Doku durchackern möchte.

Zur Datenschicht: Ich will nicht über Vor- und Nachteile von Verknüpfungen verschiedener Tabellen diskutieren. Ich wollte vielmehr wissen, warum in diesem Beispiel eine n:m-Beziehung genutzt wird, obwohl es nur eine 1:n-Beziehung geben kann - also ob das einen tieferen Sinn verfolgt. Dass es in mancherlei Hinsicht sinnvoller ist mit einer zusätzlichen Tabelle zu arbeiten steht vollkommen außer Frage, nur für ein Gästebuch? Kein Eintrag kann in mehreren Gästebüchern vorhanden sein und kein Kommentar kann zu mehreren Gästebucheinträgen gehören. Deswegen war ich etwas verdutzt, warum es genutzt wurde. Bedeutet letztendlich wahrscheinlich eine größere Datenmenge?! Nunja, wenn es keinen großartigen Grund dafür gibt, nehme ich das so hin und mache es dennoch selber anders :P :D
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Ein bisschen stehe ich immernoch auf dem Schlauch...

Beitrag von MrNiceGuy » 09.02.2009, 09:44:30

... und deswegen muss ich nun doch noch mal ein paar Fragen loswerden, da ich gerade auch mit der Doku nicht weiterkomme...

Sollten meine Ausführungen nicht richtig sein, habe ich den entsprechenden Punkt wohl doch noch nicht so richtig verstanden...

Also: Der FrontController wird dazu verwendet, um die Requests zu verarbeiten, allerdings verstehe ich nicht so ganz, wie das mit den Actions funktionieren soll bzw. was diese Actions im Eigentlichen sind!? Außerdem habe ich in einem Beispiel gemerkt, dass der FrontController manuell geladen werden muss, es also nicht ausreicht, den PageController zu laden. Wie verarbeitet der FrontController denn dann die Requests? Oder muss ich um diesen zu verwenden jede Action - was auch immer das nun sein soll - definieren? Wie komme ich an die Parameter des Requests bei URL-Rewriting ran (URL-Rewriting ist aktiviert und auch in der Registry vermerkt!)?
Dann die Sache mit dem PageController: Ansich habe ich ja irgendwie verstanden, dass dieser die Webseite darstellt bzw. den HTML-Code aus den Templates generiert. Es scheint auch mehrere Methoden zu geben, den Inhalt der Webseite dynamisch zu gestalten, indem man entweder im Script jeweils ein anderes Template angibt oder über das Template sagt, er möge irgendwas irgendwie irgendwo mit tun. Irgendwie finde ich diese Methode sehr umständlich und komme auch mit der Verwendung des PageControllers noch nicht so ganz klar. Ich steuere also die Webseite zu 90% über die Templates? Jede ANwendung muss ein eigenes Modul sein? Oder einfach nur ein Template mit eigenem Controller? Oder wie läuft das?
Beispiel: Ich will erstmal nur eine kleine Testseite haben, oben eine Kopfzeile, darunter ein "Menü" (ein paar Links nebeneinander in einer Zeile) und darunter dann den Inhalt. Wenn ich nun 3 Seiten habe: "Impressum", "Kontaktformular" und "Gästebuch", was müssen das dann für Seiten sein? Module? Templates? Was auch immer!?
Und die Ordnerhierarchie ist auch nicht so ganz ohne... Die Trennung zwischen Daten- ([My]SQL), Business- (PHP) und Präsentationsschicht (HTML) kann ich zwar nachvollziehen, aber ich verstehe die Verteilung der Scripte nicht so ganz. Warum werden die Controller in manchen Beispielen im Namespace sites::testsite::pres::templates::documentcontroller gehalten? Ist der Controller nicht eigentlich aus der Businessschicht, weil es PHP-Code enthält? Oder ist meine Sichtweise dafür zu engstirnig? Und grundsätzlich: Ist die Unterteilung in "pres" oder "biz" nicht etwas zu tief gegriffen? Es geht doch auch ohne!? Oder ist das eine Art Voraussetzung für "gute Programmierung"? Wenn das nämlich optional ist ...

Sorry, dass ich so viele Fragen stelle, aber das ist das erste Mal, dass ich mich tiefgreifend mit den Codes anderer Programmierer auseinandersetze (vorher habe ich alles alleine gemacht) und dementsprechend schwer fällt mir scheinbar auch die Umstellung mit meiner konservativen Einstellung (aufs programmiertechnische bezogen) etwas schwer.

Danke aber schonmal im Voraus!

Lutz
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4605
Registriert: 04.11.2007, 16:13:53

Re: Hilfe für APF-Neuling

Beitrag von dr.e. » 09.02.2009, 11:43:31

Hallo,
Der FrontController wird dazu verwendet, um die Requests zu verarbeiten, allerdings verstehe ich nicht so ganz, wie das mit den Actions funktionieren soll bzw. was diese Actions im Eigentlichen sind!?
Der Front-Controller ist sozusagen nochmal ein Wrapper um den Page-Controller. Das bedeutet im wesentlichen, dass sich an der reinen URL- bzw. Request-Verarbeitung nur ändert, dass der Front-Controller Action-Anweisungen in der URL erkennen und verarbeiten kann. Die URL- bzw. Request-Entgegennahme funktioniert im APF über Filter, die die Eingabe in PHP übliche Container ($_REQUEST-Array) übersetzen. Im Fall der Verwendung des Page-Controller ohne URL-Rewriting ist das quasi ein Filter ohne Aufgabe, denn PHP mappt die Werte der URL selbständig in das $_REQUEST-Array. Nutzt du den Page-Controller mit aktivierten URL-Rewriting, so übernimmt der zugehörige Filter die Aufgabe, die in der URL "versteckten" Werte zu extrahieren und diese in das $_REQUEST-Array zu schreiben. Das hat den Vorteil, dass die Applikation ohne großes Zutun in beiden Fällen funktioniert.
Der Filter, der bei Verwendung des Front-Controllers zum Einsatz kommt, filtert nun nicht nur einfache Parameter-Wert-Pärchen, sondern auch Action-Anweisungen, die dann vor Aufbau der Page-Controller-Seite, vor der Transformation dieser oder vor der Ausgabe ausgeführt werden. Diese können dann beispielsweise dazu verwendet werden, das Model einer Anwendung zu füllen, ehe die Präsentationslogik greift. Im Allgemeinen kann dieser Mechanismus dann dazu verwendet werden, zum Aufbau der Präsentationsschicht (z.B. welcher View geladen wird) die Informationen der Business-Schicht (=des Models) zu nutzen. Weitere Beispiele für Actions findest du unter http://adventure-php-framework.org/Seit ... r-Tutorial.
Außerdem habe ich in einem Beispiel gemerkt, dass der FrontController manuell geladen werden muss, es also nicht ausreicht, den PageController zu laden. Wie verarbeitet der FrontController denn dann die Requests?
Der Front-Controller ist genauso wie der Page-Controller eine allgemeingültige Komponente, die dir eine Umgebung für Front-Controller-basierte Applikationen bereitstellt. Du musst diese Komponente nicht nutzen, du kannst. Aus diesem Grund muss der FC mit einem import() eingebunden und entsprechend in der index.php instanziiert und verwendet werden. Die Verarbeitung der Requests findest du im oben verlinkten FC-Tutorial (Bild: Timing-Modell). Die Filterung der URL findet - wie oben beschrieben - vor der Verarbeitung statt und wird von den Filtern übernommen.
Oder muss ich um diesen zu verwenden jede Action - was auch immer das nun sein soll - definieren?
Jede Action ist in der URL (ich nehme den "normalen" Fall) wie folgt repräsentiert:

Code: Alles auswählen

<Namespace>-action:<ActionName>=<Param1>:<Value1>|<Param2>:<Value2>
Der Namespace adressiert - zusammen mit dem aktuellen Context der Anwendung - den Pfad zur Konfigurationsdatei, in der die Action definiert ist. Die Datei selbst beinhaltet mehrere Sektionen, die mit dem ActionName referenziert werden. Dort ist dann definiert, welche Klassen die Action implementieren und welche Initial-Parameter die Action trägt.
Wie komme ich an die Parameter des Requests bei URL-Rewriting ran (URL-Rewriting ist aktiviert und auch in der Registry vermerkt!)?
Um Parameter auszulesen, kannst du diese einfach wie bisher aus dem $_REQUEST-Array beziehen oder den RequestHandler nutzen. Letzterer vereinfacht den Zugriff und ermöglicht es, Standardwerte beim Zugriff zu definieren. So ist die Applikation niemals in einem undefinierten Zustand.
Innerhalb von Actions kannst du auf die Parameter derselben über das Input-Objekt zugreifen. Dieses steht in einer Action in der Variable $this->__Input zur Verfügung. Mit der Methode getAttribute() lassen sich die Attribute auslesen.
Dann die Sache mit dem PageController: Ansich habe ich ja irgendwie verstanden, dass dieser die Webseite darstellt bzw. den HTML-Code aus den Templates generiert. Es scheint auch mehrere Methoden zu geben, den Inhalt der Webseite dynamisch zu gestalten, indem man entweder im Script jeweils ein anderes Template angibt oder über das Template sagt, er möge irgendwas irgendwie irgendwo mit tun.
Der Page-Controller an sich ist transparent. Das bedeutet, dass er lediglich einen DOM-Baum aus bekannten Tags erzeugt und diesen gemäß dem Timing-Model (siehe http://adventure-php-framework.org/Seit ... ufdiagramm) behandelt. Dabei ist er darauf angewiesen, dass die aktiv beteiligten Komponenten (TagLibs und Document-Controller) gewisse Kriterien erfüllen (=Interface besitzen). Diese Funktionen werden dann dazu genutzt um den Baum aufzubauen (Analysephase) und den Baum zu transformieren (Generierungsphase). Die Funktion wird dabei ausschließlich von den TagLibs und Document-Controllern definiert. Diese besitzen wiederum mehrere Methoden, die vom Page-Controller in beiden Phasen ausgeführt werden. Bei TagLibs ist das der Konstruktor (besitzt eine untergeordnete Rolle, sprich wird zumeist nicht verwendet, weil gewissen Informationen noch nicht vorhanden sind), die Methode onParseTime(), die Funktion onAfterAppend() und die Methode transform(). Letztere wird in der zweiten Phase aufgerufen. Bei einem Document-Controller ist nur der Konstruktur (hier gilt das gleiche wie beim Konstruktor der Taglib) und die Funktion transformContent() in der zweiten Phase relevant, da der Document-Controller exakt zur Manipulation in der Synthese eingesetzt werden soll (Generierung von dynamischem Inhalt).
Das bedeutet letztlich - um auf deine Frage zurückzukommen - dass du mit dem Inhalt der Templates (Tags, ...) und der Funktion der Document-Controller den Inhalt der hinterher generierten HTML-Seite bestimmst. Wie du richtig erkannt hast, gibt es damit exakt zwei Möglichkeiten dynamischen Inhalt zu generieren: TagLibs und Document-Controller (beide besitzen eine Transformationsmethode). TagLibs werden im Allgemeinen dann verwendet, wenn du allgemeingültige und wiederverwendbare GUI-Elemente schreiben möchtest, Controller dann, wenn du "nur" eine spezielle Funktion für ein Modul oder eine Applikation schreibst. Letztlich entscheidest du, welchen Weg du gehen möchtest, da man im Endeffekt den gleichen HTML-Code generieren kann - die Mechanismen sind lediglich verschieden.
Irgendwie finde ich diese Methode sehr umständlich und komme auch mit der Verwendung des PageControllers noch nicht so ganz klar. Ich steuere also die Webseite zu 90% über die Templates? Jede ANwendung muss ein eigenes Modul sein? Oder einfach nur ein Template mit eigenem Controller? Oder wie läuft das?
Den Aufbau des Objektbaum steuerst du über den Inhalt der (MVC-)Template-Dateien, da diese die TagLib-Tags enthalten, die die eigentliche Funktion kapseln (siehe oben). Damit hast du die Möglichkeit Applikationen oder Webseiten beliebig zu segmentieren und kannst quasi frei definieren, was nun ein Modul ist und was nicht. Wenn es lediglich um eine Webseite geht, reichen dir ein paar Templates (Header, Content, Footer, Menü, ...) und die zugehörigen Controller, möchtest du ein Gästebuch in mehreren Webseiten verwenden, schickt es sich dieses zu kapseln, so dass es mit einem <core:importdesign />-Tag einbindbar ist und in jeder Applikation funktioniert. Was dann letztlich im Gästebuch-Template selbst steht ist dabei auch wieder dir überlassen. Üblicherweise wird dort sicher auch wieder in die unterschiedlichen Bereiche und Funktionen unterschieden, die ein Gästebuch besitzt. Hast du das "Webseite erstellen"-Tutorial durchgearbeitet? Dort steht beschrieben, wie eine Websseite aufgebaut werden kann.
Beispiel: Ich will erstmal nur eine kleine Testseite haben, oben eine Kopfzeile, darunter ein "Menü" (ein paar Links nebeneinander in einer Zeile) und darunter dann den Inhalt. Wenn ich nun 3 Seiten habe: "Impressum", "Kontaktformular" und "Gästebuch", was müssen das dann für Seiten sein? Module? Templates? Was auch immer!?
Es gibt mehrere Möglichkeiten das zu strukturieren. Ich gehe der Einfachheit halber nur auf eine der drei ein:
Den "Rahmen" der Webseite - sprich das HTML-Grundgerüst und das Menü - würde ich in eine Template-Datei verpacken. Diese adressierst du in der index.php als initiales Template. Ohne weiters Zutun siehst du nun im Browser eine Seite mit Menü, jedoch ohne Inhalt. Den Inhalt generierst du dir nun mit einem Document-Controller, der den Inhalt selbst aus einer beliebigen Quelle bezieht. Sollte das eine Text-Datei sein, so hat er die Aufgabe diese auszulesen und in einen Platzhalter-Tag (<html:placeholder />) im Haupt-Template einzusetzen. Welchen Inhalt du anzeigst, kannst du z.B. über einen URL-Parameter definieren, der im Controller verarbeitet wird. Ist die Datei nicht vorhanden, kannst du eine Standard-Seite oder einfach nichts anzeigen. Hier brauchst du noch keine Modularisierung, da du eine einfache, lokale Funktion umsetzt.
Warum werden die Controller in manchen Beispielen im Namespace sites::testsite::pres::templates::documentcontroller gehalten?
Wo steht das? Üblicherweise lege ich unter pres einen Ordner documentcontroller und templates an. Ein Controller-Ordner unter templates macht keinen Sinn.
Ist der Controller nicht eigentlich aus der Businessschicht, weil es PHP-Code enthält? Oder ist meine Sichtweise dafür zu engstirnig?
Nein. Nach dem 3-Schicht-Architektur-Pattern ist ein Controller eine Komponente, die Darstellung übernimmt und damit eindeutig der Präsentationsschicht zugeordnet ist.
Und grundsätzlich: Ist die Unterteilung in "pres" oder "biz" nicht etwas zu tief gegriffen? Es geht doch auch ohne!? Oder ist das eine Art Voraussetzung für "gute Programmierung"? Wenn das nämlich optional ist ...
Das ist eine Konvention für saubere OO-Programmierung, ist aber nicht vorgeschrieben. Du kannst auch einfach alles in Templates und Document-Controller verpacken und dort direkt auf die Datenbank zugreifen und das Result-Array zur Ausgabe deiner Daten nutzen. Es geht mir nur darum, dass von Anfang an saubere Applikationen geschrieben werden.
Sorry, dass ich so viele Fragen stelle, aber das ist das erste Mal, dass ich mich tiefgreifend mit den Codes anderer Programmierer auseinandersetze (vorher habe ich alles alleine gemacht) und dementsprechend schwer fällt mir scheinbar auch die Umstellung mit meiner konservativen Einstellung (aufs programmiertechnische bezogen) etwas schwer.
Kein Problem, ich erkläre das gerne.

Viele Grüße,
Christian
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Hilfe für APF-Neuling

Beitrag von MrNiceGuy » 09.02.2009, 13:10:02

Wow, vielen Dank für die schnelle und wahnsinnig ausführliche Erklärung! Ich konnte gerade erkennen, dass ich doch in vielen Dingen etwas falsch verstanden hatte, aber die Arbeitsweise des FW ist mir jetzt auch wieder etwas klarer geworden :)

Ich muss dennoch erstmal alles etwas sacken lassen, bevor ich genau weiß, wo ich immernoch Probleme habe, aber dann - da bin ich mir schon recht sicher - wirst du mir sicher wieder ausreichend Hilfe leisten können ;)

Zum Thema mit dem Namespace: http://adventure-php-framework.org/Seite/006-Controller unter 3.1 steht der pagecontroller im templates-Ordner. Ich war auch etwas verdutzt, da es irgendwie nicht so sinnig aussah, deswegen ja auch meine Frage.

Was die Trennung von biz und pres angeht, habe ich wohl noch ein bisschen ... wie soll ich sagen!? Bedenken, ob ich das sinnvoll finden kann oder nicht. Aber wenn du sagst, dass das nicht zwingend erforderlich ist, werde ich mir nochmal überlegen, wie ich das dann realisiere :)

Interessant ist auf jeden Fall deine Erklärung zum Ablauf, die hat mir ein wenig die Augen geöffnet, welche Möglichkeiten ich mit dem Framework habe und klingen verdammt interessant! Gerade das Kapseln in Module zur Weiterverwendung ist ja schon recht sinnvoll und ich hoffe, dass ich es irgendwann hinbekommen kann die Seite entsprechend zu benutzen. Wenn es richtig gemacht wird könnte man also z.B. ein CMS realisieren, das anhand der Domain über die auf das CMS zugegriffen wird die richtige Webseite anzeigt, obwohl ich letztendlich "nur" einen Pfad habe, in dem das APF arbeitet? Oder sollte man dann doch nicht so tief greifen, um Sicherheitslücken zu vermeiden? Ich weiß ja nicht, inwiefern du damit schon Erfahrungen gesammelt hast!?
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast