Vorschau: Plugin API in v2.0

[Chrissi]

Hallo zusammen,

ich wollte schonmal eine kleine Vorschau auf die Struktur der v2.0 geben. Diese kann sich aber immer noch wieder aendern!

Alle Aufrufe werden zukuenftig an einen ScreenController gehen, der die Aufrufe auf die jeweiligen "Screens" weiterleitet (genannt Routing).
Kurzes Beispiel:

- game.php?screen=mail&mode=new
-- der ScreenController wird nun die Klasse mailScreen aufrufen, und dort die Methode newMode() ausfuehren.
-- mailScreen::newMode()

- game.php?screen=mail&mode=new&action=send
-- mailScreen:endAction()
-- und danach, mailScreen::newMode()
--- sollte aber moeglichst vermieden werden - ein header('Location: ') sollte den User zurueck zur game.php?screen=mail&mode=new leiten, sofern kein Fehler entsteht.

Wenn kein Argument mode= in der URL spezifiert ist, wird der Aufruf auf die main() Funktion des Screens weitergeleitet.
- game.php?screen=mail
-- mailScreen::main()

Da diese URL (?screen=mail) die Inbox der Nachrichten anzeigen wuerde, die aber auch als Mode aufgerufen werden kann, muss die main()-Methode wie folgt aussehen:

PHP Code:

public function main() {
$this->inMode();
return 'in';
} 


Dies stell sicher, dass die Inbox sowohl als game.php?screen=mail als auch als game.php?screen=mail&mode=in verfuegbar ist.

Alle Action-Methoden sollen bei Fehlern einen string zurueckgeben, der zu einer Variable in der Sprachdatei passt.
en.ini

Code:

[error]
my_error_code = "You suck at entering a number!"

some screen class

PHP Code:

function someAction() {
   if(!is_numeric($_GET['number'])) {
     return 'my_error_code';
   }
} 


Also, hier ist ein Beispiel, falls jemand z.B. ein Plugin fuer eine "Freunde" funktion einbauen will:

PHP Code:

<?php
class FriendsScreen extends AbstractScreen 
{

   /**
    * Muss einen String mit dem standardmaessigen Mode zurueckgeben.
    * 
    * @return string
    */
   public function main() {
      $this->showFriendsMode();
      return 'showFriends';
   }
   
   /**
    * displays all friends.
    */
   public function showFriendsMode() {
       // some code with database requests..
       $this->tpl->assign('friends', $friends);
   }
   
   /**
    * adds a friend.
    * 
    * @return string error message, if any
    */
   public function addAction() {
       if( empty($_POST['friendName']) ) {
       return 'friend_name_empty';
       }
       
       // insert friend to DB
   }
   
   /**
    * removes a friend by ID.
    * 
    * @return string error message, if any
    */
   public function removeAction() {
       if( empty($_POST['friendID']) || !is_numeric($_POST['friendID']) ) {
       return 'friend_id_empty';
       }
       
       // remove friend from DB
   }

}
?>

Aber, da ist doch gar kein $smarty->display('...tpl')!
Genau. Und zwar gibt es dafuer den ScreenController, der automatisch folgendes Template aufruft: game_Friends.tpl (in diesem Fall), oder generell: game_$screen.tpl

Fuer Modes wird eine Variable namens $includeTemplateName an die TPLs uebergeben. Da z.B. bei den Nachrichten das Menue immer gleich aussehen soll, ist dieses in der game_mail.tpl enthalten.
Die game_mail.tpl enthaelt dann folgendes:

Code:

{include file=$includeTemplateName}

Die $includeTemplateName enthaelt folgendes: game_$screen_$mode.tpl - also, falls man dann die game.php?screen=mail&mode=in aufruft, wird vom ScreenController die game_mail.tpl aufgerufen, welche durch den obigen Code die game_mail_in.tpl includiert.
Ist genauso wie in der 1.4, nur dass in der 1.4 folgendes da stand:

Code:

{include file="game_mail_`$mode`.tpl"}

Bloss ist es diesmal als gesamte Variable uebergeben.

Ich realisiere, dass ich nicht allzu gut im erklaeren bin... Deshalb stellt viele Fragen! So kompliziert ist das System nicht, ich lasse es nur so aussehen... :/

[Chrissi]

Aber, aber, aber! Schreien einige. Ich moechte gerne die mailScreen-Klasse erweitern, aber es ist doch alles verschluesselt! Wie mache ich das denn?

Dafuer gibt es auch Abhilfe.

Es wird einen Plugin-Ordner geben, unter twlan-dir/lib/plugins/.

Nehmen wir einfach mal einen Beispiel-Code, um die mailScreen zu erweitern.

lib/plugins/MailPlugin.plugin.php

PHP Code:

/**
 * Hello World!
 *
 * @author Christopher <christopher@twlan.org>
 */
class MailPlugin extends AbstractObject implements PluginInterface {
    
    public function registerPlugins() {
// $this->plugins->registerScreenMethod($screenClassName, $methodName, $callback);
    $this->plugins->registerScreenMethod('mailScreen', 'fooMode', array(&$this, 'mailFooMode'));
    }
    
    public function mailFooMode() {
    $this->tpl->assign('foo', 'haha');
    }
    
} 


Dazu legen wir ein Template an!
templates/game_mail_foo.tpl

Code:

<h2>N Abend</h2>

{$foo}

D.h. die game.php?screen=mail&mode=foo wuerde auf die MailExtension::mailFooMode() umgeleitet.

Das wuerde dann so aussehen:
Klick!

Hiermit kann man auch bereits bestehende Methoden, wie zum Beispiel die mailScreen::main() ersetzen.

[SlimShady95]

Darf man hier drauf antworten? Naja egal.

Gefällt mir sehr gut, wird auch nicht allzu schwer sein alte Tools upzudaten
Toll, dass ihr ne API gemacht habt, vor allem dann auch noch MVC

MfG Manuel

[Chrissi]

Ja, hier soll man sogar drauf antworten!

Naja, es ist kein echtes MVC. Man koennte es als eine kleine Abwandlung dessen bezeichnen - der ScreenController heisst nur ScreenController, weil er die Screen's verwaltet. Man koennte die Screens als einen Mix aus Model, View und Controller bezeichnen, und der ScreenController muesste eigentlich ScreenDispatcher oder ScreenRouter heissen, wenn das hier ein MVC waere.

[SlimShady95]

Ok gut.
Ja im Grunde ist es MVC ähnlich, und das ist auch gut. Davor war ja keine Schnittstelle für Plugins vorhanden. Freue mich schon sehr darauf
Wird das dann auch für Admintools sein oder nur für InGame-Tools?

MfG Manuel

[Chrissi]

Es wird fuer Admintools wahrscheinlich genauso funktionieren, aber wir haben das Adminmenue bisher noch nicht angeruehrt, in-game hatte Prioritaet.

Zudem ist uebrigens noch ein Hook-System geplant, so wie es bei MyBB implementiert ist. Der Code ist schon in der Plugins-Klasse vorhanden, es gibt aber noch keinen einzigen Hook im eigentlichen Script. Die werden erst hinterher eingebaut.

[SlimShady95]

Wäre sinnvoll, das auch für den Adminbereich zu machen.

PS: Wisst ihr schon ungefähr wann ihr released? Der Monat würd mir reichen.
Und was steht noch alles an? (Kannst mir, wenn du willst auch ne PN schreiben, gehört ja hier eigentlich nicht hin.)

MfG Manuel

[Chrissi]

Ich hab noch keine Ahnung, wann ein Release ansteht. Ich will da auch nichts versprechen, weil in einer Woche mein naechstes Semester anfaengt an einer neuen Uni. Also: Keine Ahnung.

Was noch alles ansteht? Inwiefern? Was noch in v2 reinkommt? Das weiss ich auch noch nicht... mir lassen es auf uns zukomme.

[momk]

Naja, hört sich ja gut an

PS:
Die Redewendung:
"Mir lassen es auf uns zukomme." kenn ich nicht, werd ich nun öfter benutzen

MfG
Momk

[Yannici]

Find ich klasse.
Mithilfe der Pluginabhilfe, kann man ja eigentlich so gut wie jede Toolidee verwirklichen.
Gefällt mir also wirklich sehr gut.

so far
Yannici

[Milu2K]

So wie ich es verstanden habe werden dann die klasses umstrukturiert, nicht war? Falls es so sein sollte, könnte man die technischen dokumentationen übersichtlicher machen oder ne funktion die argumente etc. einer klasse bzw. einer funktion ausgibt? Das wäre für mich sehr wichtig damit ich meinen bot dann umscripten kann für die version 2.0.

MfG

[pL4n3]

So wie ich es verstanden habe werden dann die klasses umstrukturiert, nicht war? Falls es so sein sollte, könnte man die technischen dokumentationen übersichtlicher machen oder ne funktion die argumente etc. einer klasse bzw. einer funktion ausgibt? Das wäre für mich sehr wichtig damit ich meinen bot dann umscripten kann für die version 2.0.

MfG

Wir nutzen phpDocumentor

[Milu2K]

Achso ok. Kenn ich nich aber ok xD

[Chrissi]

Es wird im Endeffekt eine Webseite erstellt, die alle Infos und Dokumentationen zu unseren Klassen und Funktionen enthaelt.