Gästebuch Tutorial

Hier dreht sich alles um die auf der Webseite veröffentlichten Tutorials. // This forum is all about the APF tutorials.
Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 30.09.2009, 22:44:07

Hi Doc,

Ich weiß, ich nerve. Daher halt ich mich kurz.
Falsch! Role <-> User ist keine Komposition (=hat), sondern eine Assoziation! Das ist wichtig, da die beiden Objekte ohne Beziehung nebeneinander existieren dürfen.
Ist eine helle Raute keine Aggregation?

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 30.09.2009, 23:07:02

Hi,
Ich weiß, ich nerve.
Nein, wie kommst du darauf? :)
Ist eine helle Raute keine Aggregation?
Das ist bei den unterschiedlichen Programmen leider nicht so wirklich gleich. Einmal ist eine Assoziation nur ein Pfeil (->), mal ist es eine Raute ohne Füllung. Fakt ist jedoch, dass eine ausgefüllte Raute eine Komposition symbolisiert, alles andere ist bei mit per Definition eine Assoziation. :)
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 07.10.2009, 17:55:41

Hi Doc,

Ich werde einfach nicht so recht warm, mit der OOP :(


Wie erstellt man mit dem APF einen XML View (bsp: RSS) wenn die HTML-Endung vorgeschrieben ist?

APF ausserhalb einer HTTP Umgebung nutzen - möglich? Beispielsweise CLI für einen Cronjob. Nutzt man dort nicht auch einen Frontcontroller?

Was mich auch irritiert ist, dass du für jede Sprache eine eigene Bootstrapp Datei benutzt. Welche Vorteile bietet das?

Den Unterschied zwischen <fcon:importdesign> und <core:importdesign>, darauf wird im Tutorial nicht eingegangen? :?

Die Gruppen des UMTG sind mir ebenfalls nicht recht klar. Mit Permissions und Permissionsets bilde ich Sichtbarkeitsrechte ab. Mit Rollen Rechte auf Funktionen. Richtig?

Wie ich einen Gast einer Applikation mit dem UMTG abbilde ist mir außerdem nicht ganz klar geworden.

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 07.10.2009, 22:30:33

Hallo Thalo,
Ich werde einfach nicht so recht warm, mit der OOP :(
Kein Problem, du kommst schon noch drauf. ;) Ich helfe auch gerne dabei!
Wie erstellt man mit dem APF einen XML View (bsp: RSS) wenn die HTML-Endung vorgeschrieben ist?
Da gibt es mehrere Ansätze. Ein Ansatz ist : du erstellst eine konkrete Datei (z.B. http://domain.tld/feed.rss) uns lässt Dateien mit der Endung "rss" durch den PHP-Parser laufen. In dieser Datei kannst du nun das APF dazu nutzen, das XML zu erstellen und auszuliefern. Hier kannst du alle Möglichkeiten und Komponenten deiner Bisherigen Software nutzen. Zweiter Ansatz: du erstellst eine Rewrite-Rule, die dir eine "virtuelle" RSS-Datei (z.B. http://domain.tld/feeds/radio.rss) auf eine konkrete Front-Controller-Action mappt (z.B. http://domain.tld/~/rss_namespace-actio ... type/radio) und du dort dann das RSS zusammenbaust.
Für den Benutzer oder den Feed-Aggregator sieht beides so aus, als würdest du eine "echte" Datei requesten. An sich also keine echte APF-Aufgabenstellung, sondern ganz einfach mit mod_rewrite zu lösen. Die URL im zwieten Ansatz kann natürlich auch eine "normale" Url der Form http://domain.tld?rss_namespace-action: ... type:radio.
APF ausserhalb einer HTTP Umgebung nutzen - möglich? Beispielsweise CLI für einen Cronjob. Nutzt man dort nicht auch einen Frontcontroller?
Kein Problem. Das funktioniert exakt genauso wie du eine "normale" PHP-Datei schreiben würdest, mit dem Unterschied, dass du keinen RequestHandler für CLI hast. Sollte Bedarf bestehen, kann ich da gerne noch etwas beisteuern. Soetwas wie einen CLIParamHandler der eine Methode getParam() besitzt.
Was mich auch irritiert ist, dass du für jede Sprache eine eigene Bootstrapp Datei benutzt. Welche Vorteile bietet das?
Musst du nicht. Das ist im apf-demopack-* so gelöst, die APF-Seite selbst wird z.B. nur über eine einzige Bootstrap-Datei ausgeliefert. Zwei Dateien zu nutzen bietet gegenüber einer eigentlich keien Vorteil, weil das APF Sprach-Handling bereits eingebaut hat (Sprache ist in jedem Objekt in der Klassen-Variable $this->__Language verfügbar).
Den Unterschied zwischen <fcon:importdesign> und <core:importdesign>, darauf wird im Tutorial nicht eingegangen? :?
Das ist in der Tag dürftig, ich bin auch gerade am Überarbeiten der Doku und es werden einige frische Inhalte hinzukommen (Gästebuch-Design + Implementierung in aller Ausführlichkeit).
Die Idee des <core:importdesign />-Tag ist lediglich die, aus einem Template-File einen neuen APF-DOM-Knoten im Baum zu erzeugen. Dies passiert statich an Hand der Attribute namespace und template und kann lediglich über Request-Parameter gesteuert werden. Der Namespace ist dabei statisch. Da die Steuerung hier beim Aufbau der Seite passiert, ist die Logik im Bereich des Page-Controller angesiedelt, sie wird also beim Erzeugen und Transformieren der Seite ausgeführt.
Anders der <fcon:importdesign />-Tag. Hier werden die Informationen, welches Template aus welchem Namespace geladen werden soll dynamisch aus einer Model-Klasse gelesen. Diese kann in einer Front-Controller-Action zuvor gesetzt oder manipuliert werden. Damit eröffnest du dir die Möglichkeit z.B. in einer Front-Controller-Action zu entscheiden, ob eine Login-Maske oder eine interne Seite angezeigt werden soll. Du kannst also die Logik wirklich als Business-Logik (Front-Controller-Actions zählen dazu!) formulieren und bist nicht daraif angewiesen dir deine Informationen aus dem "statischen" Request zu holen. Baust du deine GUI mit <fcon:importdesign />-Tags auf, hast du eine sehr schöne Möglichkeit per Business-Logik zu entscheiden, welcher View mit welchem Inhalt befüllt wird. Dies ist mit dem <core:importdesign />-Tag nicht oder nur auf Umwegen möglich. Hierzu wird es aber in Kürze (ich hoffe sobald das 1.11-RC1 da ist) noch einen Artikel geben.
Die Gruppen des UMTG sind mir ebenfalls nicht recht klar. Mit Permissions und Permissionsets bilde ich Sichtbarkeitsrechte ab. Mit Rollen Rechte auf Funktionen. Richtig?
Gruppen sind ein Container, mit dem man Benutzer gruppieren kann. Über Beziehungen von Benutzern oder Gruppen auf die Ziel-Objekte (z.B. eine CMS-Seite, einen News-Eintrag, ...) werden Sichtbarkeits-Berechtigungen abgebildet. Ist keine Beziehung (das muss eine Assoziation sein) von einem Benutzer zu einem Ziel-Objekt vorhanden, "sieht" er dieses auch nicht.
Permissions und PermissionSets sind rein zur Strukturierung der Funktions-Berechtigungen. Sofern ein Benutzer direkt oder indirekt über seine Gruppe eine Beziehung zu einem Ziel-Objekt hat, heißt das noch lange nicht, dass er es auch löschen darf. Erst wenn er über seine Rolle ein entsprechendes PermissionSet mit der Löschen-Permission zugeordnet hat, darf er das Objekt auch löschen. Kurz zusammengefasst:
  • Über Beziehungen von Benutzern und/oder Gruppen auf Ziel-Objekte wird die Sichbarkeit geregelt.
  • Über Rollen (und explizit über Permissions und PermissionSets) werden Funktions-Berechtigungen vergeben.
Wie ich einen Gast einer Applikation mit dem UMTG abbilde ist mir außerdem nicht ganz klar geworden.
Um einen Gast sauber zu implementieren, legst du einen Benutzer an und machst für ihn die für dich relevanten Objekte über Beziehungen sichtbar. Gleichzeitig erhält der Gast eine entsprechende Rolle, die keine vitalen Funktionen beinhaltet, vermutlich einfach eine Lese-Funktions-Berechtigung auf die Objekte.

Soweit verständlich?
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 08.10.2009, 00:05:52

Hi Doc,
Kein Problem, du kommst schon noch drauf. ;) Ich helfe auch gerne dabei!
Da hast du dir aber was vorgenommen... :ugeek:
Musst du nicht. Das ist im apf-demopack-* so gelöst, die APF-Seite selbst wird z.B. nur über eine einzige Bootstrap-Datei ausgeliefert. Zwei Dateien zu nutzen bietet gegenüber einer eigentlich keien Vorteil, weil das APF Sprach-Handling bereits eingebaut hat (Sprache ist in jedem Objekt in der Klassen-Variable $this->__Language verfügbar).
Ich habe mir die Dateien von "Behind the site" angesehen. Dort wurde es genau so gelöst. Hat sich das später geändert?
[...]
Du kannst also die Logik wirklich als Business-Logik (Front-Controller-Actions zählen dazu!)
[...]
Das Front-Controller Pattern ist doch ein Pattern der Präsentationsschicht?! :?:
Gruppen sind ein Container, mit dem man Benutzer gruppieren kann. Über Beziehungen von Benutzern oder Gruppen auf die Ziel-Objekte (z.B. eine CMS-Seite, einen News-Eintrag, ...) werden Sichtbarkeits-Berechtigungen abgebildet. Ist keine Beziehung (das muss eine Assoziation sein) von einem Benutzer zu einem Ziel-Objekt vorhanden, "sieht" er dieses auch nicht.
Permissions und PermissionSets sind rein zur Strukturierung der Funktions-Berechtigungen. Sofern ein Benutzer direkt oder indirekt über seine Gruppe eine Beziehung zu einem Ziel-Objekt hat, heißt das noch lange nicht, dass er es auch löschen darf. Erst wenn er über seine Rolle ein entsprechendes PermissionSet mit der Löschen-Permission zugeordnet hat, darf er das Objekt auch löschen. Kurz zusammengefasst:

* Über Beziehungen von Benutzern und/oder Gruppen auf Ziel-Objekte wird die Sichbarkeit geregelt.
* Über Rollen (und explizit über Permissions und PermissionSets) werden Funktions-Berechtigungen vergeben.
Das verstehe ich noch nicht ganz. Ich dachte Sichtbarkeitsrechte werden mit "Rechte" abgebildet?
Um einen Gast sauber zu implementieren, legst du einen Benutzer an und machst für ihn die für dich relevanten Objekte über Beziehungen sichtbar. Gleichzeitig erhält der Gast eine entsprechende Rolle, die keine vitalen Funktionen beinhaltet, vermutlich einfach eine Lese-Funktions-Berechtigung auf die Objekte.
Also wie in PHPBB? Auf die Idee bin ich kurzzeitig auch gekommen. Hab es aber dann wieder verworfen.

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 08.10.2009, 09:10:46

Hallo Thalo,
Ich habe mir die Dateien von "Behind the site" angesehen. Dort wurde es genau so gelöst. Hat sich das später geändert?
Nein. In diesem Artikel wird exakt eine index.php genutzt, die beide Sprachen abbilden kann. Das einzige, was mir auffällt ist, dass sprachabhängige Parameter für die Adressierung der Seite verwendet werden. Das aber lediglich um die Sprache in der Front-Controller-Action zu unterscheiden.
Das Front-Controller Pattern ist doch ein Pattern der Präsentationsschicht?! :?:
Nur teilweise, er führt jedoch hauptsächlich Business-Logik - wie das füllen des Models - aus und zählt meiner Auffassung nach zu größeren Teilen zur Business-Schicht. Dass dieser nachgelagerte Präsentations-Komponenten involviert bedeutet ja nicht, dass er zur Präsentations-Schicht gehört. Zumindest im APF ist das klar zwischen Page- und Front-Controller getrennt. Das Entgegennehmen der Requests und Ausführen der Filetr ist sein Teil, den er der Präsentations-Schicht spendiert. Für dein Verständnis: er gehört zu - mehr oder weniger - beiden Schichten.
Das verstehe ich noch nicht ganz. Ich dachte Sichtbarkeitsrechte werden mit "Rechte" abgebildet?
Permission = Funktions-Berechtigung! :)
Also wie in PHPBB? Auf die Idee bin ich kurzzeitig auch gekommen. Hab es aber dann wieder verworfen.
Ich habe PHPBB nicht re-enginered, aber wenn du das sagst... Alternative dazu ist eine Art Blacklisting-Verfahren. Das beschreibt, dass alle Inhalte - oder alle in einem Ordner - sichtbar für einen Gast sind und andere nicht. Sofern du deine Inhalte gruppierts (z.B. mit Ordnern, Foren oder anderen Containern), sind das nur wenige Beziehungen, die du verwalten musst.
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast