bituniverse.com

[Gast]

Edit: habe mich nicht eingelogt. Slava.
Danke für die Ausführung!
Also ich habe mir das aus Sicht von PHP-Classen auch so vorgestellt.
Problem ist dabei dass ich zbs bei forum-thread für jeden Post eine Abfrage starten muss, um zbs Editieren von eigenen Beiträgen zu erlauben. Also würde für mich eine ACL auf Zeileebener eine reqursive sql abfrage bedeuten, wenn ich zbs bei jedem fetch-array die Methode darfAendern() aufrufen würde.
Also muss ich die Bedingung darfAendern() schon in meine sql-abfrage packen um performande Ergebnis zu bekommen.
Top-Down Technik ist supper, aber wenn man sie in übersichtichen Modulen mit genauerem technischem Verständnis verwendet,
oder bei ganz globalen Sachen wo die spezifische technische Anförderungen keine Rolle spielen.
Sonnst kann man sich schnell mit Top-Down Technik auch richtig in Enge treiben.
Das habe ich schon wärend meinem erstem PHP Projekt von 5.5 Jahren erlebt, da ich eine schöne Karoserie gebaut habe und müsste feststellen, dass darein nur 5 PS Motor passt.
Mit 5 PS Motor meine ich Mysql vor 5 Jahren, der keine Union und Subquerys verstanden hat was am Ende Umprogrammieren von Top-Down funktionen und Klassen geführt hat.
Sonnst ist die Top-Down technik ein richtiger Weg, der aber sehr gut an die technische Möglichkeiten angepasst sein müsste.
Also im Fall mit den Posting in einem Thread werde ich vermutlich so machen, dass der Ergebnis zeilenweise ein object liefert, der die Methode darfAendern hat.
Etwa so

Code:

$ergebnis=$model->getPostsByThreadId($threadid, $user->getId()); $this->view->list=$ergebnis;

dann kann ich in view-script etwa so machen.

Code:

<?php foreach($this->list as $posts) {   ....    if($posts->darfAendern()) {?>    <a href="post/id/<?php echo $post->id ?>"> ändern</a>    <?php }

Wie meinst du, ob so ein Vorgehensweise OK ist?

[dr.e.]

Hallo Slava,

schön, dass dir die Ausführungen gefallen haben. Nun aber zu den konkreten Themen:

Zitat:

Problem ist dabei dass ich zbs bei forum-thread für jeden Post eine Abfrage starten muss, um zbs Editieren von eigenen Beiträgen zu erlauben. Also würde für mich eine ACL auf Zeileebener eine reqursive sql abfrage bedeuten, wenn ich zbs bei jedem fetch-array die Methode darfAendern() aufrufen würde.

Nicht ganz. Wenn du das intelligent anstellst, muss reichen, dass du die Information hast, welche Rolle der Benutzer hat (= darf er Beiträge editieren, oder nicht) und welche ID. Damit kannst du ein Listing ausgeben mit Edit-Button für alle Einträge, falls er Moderator ist und das darf, oder nur bei seinem eigenen Beitrag.

Zitat:

Also muss ich die Bedingung darfAendern() schon in meine sql-abfrage packen um performande Ergebnis zu bekommen.

Sauber implementiert würdest du eine Methode in deiner Business-Komponenten erstellen, die ungefähr so aussieht:

Php:

<?php   class ForumManager extends coreObject {      function __getCurrentUser(){       return $_SESSION['CurrentUser'];    }      function isPermittedToChange(&$User,&$Entry){         $UserID = $User->get('UserID');       $EntryUserID = $Entry->get('User')->get('UserID');         if($UserID == $EntryUserID){          return true;       }       else{          return false;         }      }   }   ?>

Sehen wir das Ganze ein wenig lockerer, kann man auch zulassen, dass diese Prüfung in der Präsentationsschicht stehen darf, da ja entschieden wird, ob eine grafische Komponente angezeigt wird oder nicht. In diesem Fall könnte man sich beim Erzeugen der Ausgabe eines Posts die Informationen dort ziehen und entsprechend vergleichen. Voraussetzung ist jedoch, dass zu einem Eintrag auch ein Benutzer geladen wird. Hier sollte man sich jedoch überlegen, wie die Datenschicht implementiert ist, da bei einem Post nicht alle Informationen eines Benutzers relevant sind. Man könnte dazu beispielsweise ein intelligentes Domain-Objekt mit Lazy Loading implementieren, das gewisse Attribute immer läd, die übrogen nur dann, wenn die get()-Funktion aufgerufen wird. Das ist aber ein weiterer Punkt, der an anderer Stelle diskutiert werden muss.

Zitat:

Sonnst ist die Top-Down technik ein richtiger Weg, der aber sehr gut an die technische Möglichkeiten angepasst sein müsste.

Man muss sich natürlich am Anfang Gedanken über das Aussehen machen und nicht hinterher. Die Nachteile dieser Methode kann man aber in Verbindung mit dem "Vertical Rapid Prototyping" ausmerzen, denn damit bleibt man dem Prinzip TOP-DOWN treu, erstellt aber pro Verwendungszweck einen eigenen "Durchstich" und passt die internen Struktzuren gemäß der Erweiterung der API an und ist damit agiler und flexibler. Das ist aber Geschmackssache...

Zitat:

Code: $ergebnis=$model->getPostsByThreadId($threadid, $user->getId());

Das ist genau das, was ich versucht habe in einigen Posts zu differenzieren. Ein Model ist in FrontController-Applikationen eigentlich - in Pattern-Sprache gesprochen - kein Datenobjekt, sondern der Zustand einer Applikation, sprich deren interne Informationen wie

- anzuzeigende Views
- aktueller Benutzer
- ...

Dein $model muss an dieser Stelle durch deine Business-Komponente ersetzt werden. Wichtig ist dabei, dass die Business-Komponente nicht das Model deiner Anwendung ist, sondern diese vom Model parametrisiert wird. Besseres Beispiel für deinen Code:

Php:

<?php   class thread_controller extends baseController {    function transformContent(){       $fM = &$this->__getServiceObject('sites::forum::biz','forumManager');       $Model = &$this->__getServiceObject('sites::forum::biz','forumModel');       $ThreadID = $Model->get('ThreadID');       $Posts = $fM->getPostsByThreadID($ThreadID);         // ... some more code ...          }   }   ?>

Zitat:

Wie meinst du, ob so ein Vorgehensweise OK ist?

Das Thema Views ist ok, du arbeitest so wie das in CakePHP üblich ist und gibst die Liste von Domain-Objekten einfach an den View weiter.

_________________

Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at www.adventure-php-framework.org!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Slava]

Danke Dr.e.
Von Prinzip will ich auch die von dir vorgeschlagene Richtung gehen.
Wir versuchen gerade mit Jens ein anderem verschiedene Varianten von MVC-Konzept vorzustellen und hoffe, dass wir bald eine Entscheidung treffen. In jedem Fall wollen wir das nicht zu kompliziert gestalten, damit ein schneller einstig möglich ist.

[dr.e.]

Hallo Slava,

Zitat:

Wir versuchen gerade mit Jens ein anderem verschiedene Varianten von MVC-Konzept vorzustellen und hoffe, dass wir bald eine Entscheidung treffen.

Um aus Projektleiter-Sicht zu argumentieren (wie man sich das in der IT gefallen lassen muss): Diese Zeit hättet ihr besser in die Einarbeitung in ein fertiges Framework investieren sollen, denn nun ist die Zeit zwar verstrichen, jedoch steht keine Implementierungsbasis, kein vollständiges Konzept und auch kein eingearbeitetes Team zur Verfügung!

Zitat:

In jedem Fall wollen wir das nicht zu kompliziert gestalten, damit ein schneller einstig möglich ist.

Ich könnte nicht behaupten, dass das oben diskutierte Konzept einfach ist. Bei komplexen Systemen hat man immer das Problem, dass die Komplexität mit den Anforderungen überproportional steigt. Wenn du es einfach gestalten willst, lass die Objektorientierung weg, dokumentiere deine Datenbank-Tabellen und lass jeden Entwickler wild skripten.

Da es aber ein open source Projekt auf ehrenamtlicher Basis ist, sehen wir darüber mal hinweg.

_________________

Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at www.adventure-php-framework.org!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Slava]