WordPress xmlrpc call Beispiel XML

Nachdem ich jetzt relativ lange nach einen Beispiel XML Code für das Erstellen eines Blogeintrages auf einer WordPress Instanz gesucht habe hier ein Bsp XML. Leider nur metaWeblog.newPost und nicht wp.newPost, die Hilfeseiten auf der WordPress.org Seite lassen leider sehr zu wünschen übrig. Es ist nicht ersichtlich wie das XML aussehen soll meiner Meinung nach,


<?xml version="1.0"?>
<methodCall>
<methodName>metaWeblog.newPost</methodName>
<params>
<param><value><int>1</int></value></param>
<param><value><string>admin</string></value></param>
<param><value><string>password</string></value></param>
<param><value><struct>
  <member><name>title</name><value><string>Beitragstitle</string></value></member>
  <member><name>categories</name><value><array><data>
  <value><string>Kategorie 1</string></value>
  <value><string>Kategorie 2</string></value>
</data></array></value></member>
  <member><name>mt_keywords</name><value><string>tag1, tag2, tag3</string></value></member>
  <member><name>content</name><value><string>Hier könnte Inhalt stehen</string></value></member>
</struct></value></param>
<param><value><boolean>1</boolean></value></param>
</params></methodCall>
 

Hier das Script für das Erzeugen des XML, mit der Klasse die im WordPress Ordner liegt.

<!--?php require_once("../wp-includes/class-IXR.php"); 
$rpc = new IXR_Client('http://localhost/wordpress/xmlrpc.php'); 
$post = array(); // das Post construct: // Metadaten 
$post['title']     = 'Beitragstitle'; 
$post['categories']   = array('Kategorie 1', 'Kategorie 2'); 
$post['mt_keywords']   = 'tag1, tag2, tag3'; // Posttext 
$post['content']   = 'Hier könnte Inhalt stehen'; 

print_r($rpc--->getXml('metaWeblog.newPost', // Methode
1, // Blog ID, in der Regel 1
'username', // Benutzer
'password', // Passwort
$post, // Post construct
true // Veröffentlichen?
));

echo "\n \n send to server \n";
$status = $rpc-&gt;query('metaWeblog.newPost', // Methode
1, // Blog ID, in der Regel 1
'username', // Benutzer
'password', // Passwort
$post, // Post construct
true // Veröffentlichen?
);

// Ergebnis überprüfen und ggf. eine Fehlermeldung ausgeben
if(!$status) {
echo 'Error ('.$rpc-&gt;getErrorCode().'): '.$rpc-&gt;getErrorMessage();
echo " \n";
exit;
}

// Sonst: ID des neuen Posts ausgeben
echo 'New Post ID: '.$rpc-&gt;getResponse();
echo " \n";

http://felixtriller.de/2009/12/22/wordpress-mit-php-und-xml-rpc-bloggen/. Code wurde hier entnommen und die Klasse wurde um 1e Methode erweitert.



    function getXml($args){
        $args = func_get_args();
        $method = array_shift($args);
        $request = new IXR_Request($method, $args);
        return $request->getXml();
    }

Language Switch

Heute stelle ich eine Lösung für einen Language switch im Zend2 Framework mit Ajax und Cookies.

Zu allererst muss die module.config.php Datei angepasst werden. In der Sekeletton Application von Zend2 ist der Translator bereits Konfiguriert und im Service Manager eingebunden. Ich habe lediglich die Übersetzungsdatei auf ein php – Array umgestellt:

(type => phparray und pattern => %s.php)


    'service_manager' => array(
        'factories' => array(
            'translator' => 'Zend\I18n\Translator\TranslatorServiceFactory',
        ),
    ),
    'translator' => array(
        'locale' => 'de_DE',
        'translation_file_patterns' => array(
            array(
                'type'     => 'phparray',
                'base_dir' => __DIR__ . '/../language',
                'pattern'  => '%s.php',
            ),
        ),
    ),

Außerdem habe ich für die Cookies die Module Klasse modifiziert:


class Module
{
    public function onBootstrap(MvcEvent $e)
    {
        $e->getApplication()->getServiceManager()->get('translator');

        $translator = $e->getApplication()->getServiceManager()->get('translator');
        if(isset($e->getRequest()->getCookie()->language) && $e->getRequest()->getCookie()->language != '' && $e->getRequest()->getCookie()->language != null){
            $language = $e->getRequest()->getCookie()->language;
            $translator->setLocale($language)->setFallbackLocale('en_EN');
        }
     }
}

Hierbei wird der Translator geladen. Weiters wird in der onBoostrap – Methode der Request abgefangen und ausgelesen. Ich hole mir mithilfe von getCookie() die Cookies aus den Request. Warum hier konkret language geholt wird werden wir anschließend im Controller sehen. Wenn die Sprache gesetzt worden ist wird sie dem Translator übergeben bzw. die Locale gesetzt. Also jene Variable die die Sprache bestimmt. Als Fallback wird hier z.B. Englisch angenommen.

Weiters benötigen wir für die Lösung einen Controller der uns den Cookie setzt. ich habe ihn hier in einen ApiController von mir geladen der Json für den Ajax Call als Antwort zurückliefert.


class LanguageApiController extends AbstractActionController
{

   public function indexAction(){
      $language = htmlspecialchars($this->getRequest()->getQuery('language', 'de_DE'));
      $cookie = new SetCookie('language', $language);
      $this->getResponse()->setStatusCode(Response::STATUS_CODE_201);
      $this->getResponse()->getHeaders()->addHeader($cookie);
      return new JsonModel(array('cookiecreated'=>'ok', 'language'=>$language));
   }
}

Hier wird, wie wir später noch sehen werden, einfach die Sprache mit einen GET Parameter gesetzt. Es wird ein Cookie erstellt der ‚language‘ auf den ausgelesen Wert speichert. Anschließend wird er der Response übergeben und dem Header des Requests hinzugefügt. Zum Schluss benötigen wir noch das notwendige JavaScript um die Sprache umzustellen.


$(document).ready(function(){

    $(document).on('click','a[data-action|=languagechanger]',function(event){
        event.preventDefault();

        $.ajax({
            url: baseUrl + '/languagesetter',
            data: 'language='+$(this).attr('data-value')
        }).always(function(){
           location.reload();
        });
    })

});

Mit dieser einfachen Methode wird nun der Controller aufgerufen und der Cookie gesetzt. Anschließend wird die Seite neu geladen und wir haben die Sprache im Cookie gespeichert. Wir können nun einfach in der View die translate Methode des Viewhelpers aufrufen.


## übersetzungsfile
return array(
    'Search'=>'Suche', 
....);

## in der view
echo $this->translate('Search')

Überschreiben des JsonModels – Automatische Konvertierung von Entities in Json gerechte Arrays

Heute habe ich die Klasse Zend\View\Model\JsonModel etwas erweitert um meine Entities automatisch in für das JsonModel benötigte Array umzuwandeln. Dies geschieht mit ein Paar einfachen Zeilen im neuen JsonModel


<?php
namespace Vico\ViewModel;

use Zend\View\Model\JsonModel as ZendJsonModel;
use Vico\Entity\BaseEntity;
/**
 * User: Christian Zellot
 * Date: 11.06.13
 * Time: 17:58
 */

class JsonModel extends  ZendJsonModel{

    /**
     * Erweitert den Konstruktor um die Fähigkeit Entity Klassen automatisch in Arrays umzuwandeln
     * @param  null|array|Traversable $variables
     * @param  array|Traversable $options
     */
    public function __construct($variables = null, $options = null)
    {
        $variables_copy = array();
        if($variables != null && is_array($variables)){
            foreach($variables as $variable){
                $variables_copy[] = BaseEntity::isSubclass($variable) ? $variable->toArray() : $variable;
            }
        }
        parent::__construct($variables_copy, $options);
    }

}

Außerdem habe ich das Base Entity um eine statische Methode erweitert, um diese Subklassen von sich erkennen zu lassen, dies geschieht einfach mit der Methode isSubclass($object)


<?php
namespace Vico\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* User: Zelle
* Date: 24.12.12
* Time: 12:22
*
* Base entity class from which all entities should inherit
*
*/
abstract class BaseEntity {

    /**
     * creates an array based on all fields of the entity
     * @return array
     */
    abstract public function toArray();

    /**
     * sets all fields with data out of the array, there is no checking off violations necessary
     * @param array $data
     * @return void
     */
    abstract public function fillWithArray(array $data);

    /**
     * checks if the given variable is an subclass of BaseEntity
     * @param $object
     * @return bool
     */
    public static function isSubclass($object){
        return is_subclass_of($object, __CLASS__);
    }
}

Dies bietet mir jetzt die Möglichkeit dem JsonModel ein Array mit Entities zu übergeben und diese werden automatisch in das passende Format gebracht. Lästige Umwandlungen in Arrays kann man sich also dadurch leicht ersparen.

View Helper, Routennamen und Action in der View

Oft benötigt man in den View – Files die aktuelle Route, den Controllernamen und den Actionnamen. In Zend2 ist es ganz einfach zu lösen. Zuerst brauch man einen View Helper, der einen in den View – Files zur Verfügung steht.


use Zend\View\Helper\AbstractHelper;

class RouteHelper extends AbstractHelper
{
    
    protected $routeMatch;

    public function __construct($routeMatch){
        $this->routeMatch = $routeMatch;
    }

    public function __invoke(){
        return $this;
    }
    
    public function getControllerName(){
        if($this->routeMatch != null){
           return $this->routeMatch->getParam('controller', 'index');  
        }
        return '';
    }
    
    public function getMatchedRoute(){
        if($this->routeMatch != null){
           return $this->routeMatch->getMatchedRouteName(); 
        }
        return '';
    }
    
    public function activeIfMatch($route, $action = null){
        if($this->getMatchedRoute() == $route){
            if($action == null || $this->routeMatch->getParam('action', 'index') == $action){
                return 'active';
            }
        }
        return '';
    }
}


In der Module Klasse


...
public function onBootstrap(MvcEvent $e)
    {
        $e->getApplication()->getServiceManager()->get('translator');
        $eventManager        = $e->getApplication()->getEventManager();
        //view helper for route name
        $e->getApplication()->getServiceManager()->get('viewhelpermanager')->setFactory('routeHelper', function($sm) use ($e) {
            $viewHelper = new \AAUShare\Helper\RouteHelper($e->getRouteMatch());
            return $viewHelper;
        });
        $moduleRouteListener = new ModuleRouteListener();
        $moduleRouteListener->attach($eventManager);
        
    }
...

Wichtig ist hier vor allem die Methode activeIfMatch welche eine Route und eine Action erwartet. Wenn diese erfüllt sind so wird active zurückgegeben. Dies habe ich vor allem mit den Gedanken gebaut nur mehr diese Methode in der View ausgeben zu müssen (z.B. um den Menüpunkt als active zu Markieren). In der View dann:


... <li class="<?php echo $this->routeHelper()->activeIfMatch('home'); ?>"><a  ... 

Doctrine2 Subquerys und der IDENTITY Helfer

Vor allem bei Suchquerys kommt man oft nicht an Subquerys vorbei. Konkretes beispielsweiße ist hier die Suche nach Einträgen mit gewissen Tags im AAUShare System. Es gibt hier das Post Entity mit den Mappings zu den Tags, bzw PostTags(Mapping zwischen Tags und Posts). Um hier z.B. alle Posts zu erhalten die mit einen Tag besitzen ist noch recht unkompliziert, möchte man jedoch nur Posts mit z.B. den Tags Informatik und ESOP so wird die Query schon komplizierter. Ich habe dazu folgende Methode implementiert:


public function findByTagTitles(array $tags, $additive){
        $tagtsrings = '';
        $logicalop = 'OR';
        if($additive == true){
            $logicalop = 'AND';
        }
        //create query statement ors and ands
        for($i=0; $i<sizeof($tags); $i++){
            $tagtsrings .= ' p.id IN (SELECT IDENTITY(pt'.$i.'.post) FROM AAUShare\Entity\PostTag pt'.$i.' JOIN pt'.$i.'.tag t'.$i.' WITH t'.$i.'.title LIKE :tag'.$i.')';
            if(($i+1) < sizeof($tags)){ //last and or or
                $tagtsrings .=' '.$logicalop;
            }
        }
        if(sizeof($tags)==0){
            $tagtsrings.='1';
        }
        //
        $querystring = 'SELECT p FROM AAUShare\Entity\Post p WHERE'.$tagtsrings;
        $query = $this->getEntityManager()->createQuery($querystring);
        //bind
        for($i=0; $i<sizeof($tags); $i++){
            $query->setParameter('tag'.$i, $tags[$i]);
        }
        //do query
        return $query->getResult();
    }

Hier wird ein Array mit Tags übergeben, nach welchen gesucht wird, der zweite Parameter bestimmt ob die Tags mit „AND“ oder mit „OR“ verknüpft werden. Interessant sind hierbei vor allem die for-Schleifen. In der ersten werden die Tags in Subquerys gepackt und geprüft ob der Post in der Menge der zurückgelieferten postids vorhanden ist. Wichtig ist hierbuach der IDENTITY Befehl für Doctrine2, damit wird auf den Foreign Key der OneToMany Relation in PostTag zugegriffen. Außerdem werden die Subquerys durchnummeriert und auch damit die Parameter

In der zweiten for-Schleife werden die durchnummerierten Query Parameter noch mit den Werten aus den Tags verknüpft.

Neu anlegen von vorhanden Entities by ManyToOne Relationen, obwohl Entity bereits existiert

Heute bin ich auf ein im ersten Moment doch sehr seltsames Verhalten von Doctrine2 gestoßen. Benutzt man verschiedene Entity Manager innerhalb einer Applikation, so beispielsweise bei einer ManyToOne Relation versucht das hinzugefügte Entity neu anzulegen

  /**
     * @ORM\ManyToOne(targetEntity="User", inversedBy="user")
     * @ORM\JoinColumn(name="userid", referencedColumnName="id")
     */
    protected $createdFrom;

Ursache sind wie bereits erwähnt die beiden verschiedenen EntityManager Instanzen. Abhilfe schafft hier logischerweiße das verwenden von der gleichen Instanz, oder aber das Entity aus dem EntityManger neu zu laden mit dem der Speichervorgang durchgeführt werden soll. Wichtig ist jedoch hier zu beachten, das man keine inkonsistenzen schafft wenn man beide EntityManager verwendet!

Anbei noch der Link zu den Stackoverflow Beitrag, der mir hier weitergeholfen hat.

PHP Markdown in Zend2

Oft hat man das Problem das bei von User eingetragenen Daten bzw. Textfeldern zwar Formatierungen erwünscht sind, jedoch auf der Serverseite für viel mehr Aufwand sorgen. Abhilfe schafft hier Markdown, eine eigene Notation für Formatierungen die dann in html umgewandelt wird. Es gibt hier bereits einige fertige Implementierungen für alle möglichen Sprachen, z.B. auch für PHP. (https://github.com/michelf/php-markdown). Hier habe idh die Klassen kopiert und in ein eigenes Modul gepackt. Die Ordnerstruktur sieht wie folgt aus:

Michelf
| Module.php
|__src
__|__Michelf
____|__Markdown.php

Jetzt muss nur noch im application.config.php File das Modul eingebunden werden ..


'modules' => array(
         ...,
        'DoctrineORMModule',
        'Michelf',

    ),

Nun kann der Text leicht in HTML umgewandelt werden


echo \Michelf\Markdown::defaultTransform($text);

AAUShare – Teile Lösungen und Skripten

Ein Studienkollege hat mich auf eine gute Idee für ein neues Wochenendprojekt gebracht. Es handelt sich um eine Online Plattform in welcher Studenten ihre Skripten teilen können. Man sollte sich dort einfach einloggen können und Skripten und Lösungen hochladen können bzw. nach diesen Suchen können.

Ein solches System müsste mit wenig Tabellen auskommen können. Die Datenbank besteht hauptsächlich aus der Tabelle Post – Ein Eintrag mit einen Titel, Text, Files und Tags sowie einen Rating – welcher in mehrere Tabellen aufgespalten worden ist. Es sollen pro Eintrag mehrere Files hochgeladen werden können, sowie ein Rating möglich sein. Um missbrauch zu vermeiden sollte man als User nur einmal pro Beitrag abstimmen können. Um dies zu gewährleisten muss ein Loginbereich geschaffen werden. Dies sollte mit Sozialen Netzwerken schaffbar sein, da heutzutage fast jeder einen Account in einen der Netzwerke besitzt.
Außerdem sollte man den Post auch Tag’s hinzufügen können um leichter gefunden werden zu können, hierbei habe ich an etwas ähnliches wie bei StackOverflow gedacht, da dies dort meiner Meinung nach einfach und schnell funktioniert.
Eine weitere wichtige Funktionalität ist das Kommentieren von Beiträgen, bzw. die Möglichkeit eine Antwort zu erstellen, wobei es wichtig ist zwischen den beiden zu unterscheiden. Eine Antwort kann wieder ein Beitrag mit Files sein, ein Kommentar sollte jedoch lediglich aus Text bestehen und auch in der Anzeige entsprechend gekennzeichnet werden.

Aufgrund der obigen Funktionalitäten habe ich mir folgendes ER-Diagramm überlegt:

ER

Ich habe hier auch mal das Rating aus dem Post herausgezogen, aus der Überlegung heraus, das für das RatingUpdate nicht auf die Post Tabelle zugegriffen werden muss, ich bin mir aber noch nicht sicher ob das sinnvoll ist.

Als Technologien habe ich ZF2, Doctrine2, Bootstrap (+Font Awesome), JQuery (+Plugins) gewählt, da ich mit diesen das meiset abdecken sollte.

Die Grundstruktur ist gleich wie bei meinen letzten Posts zu Zend / Doctrine. Ein Stolperstein bei den Entities waren die Mappings von Post zu File und Post zu PostTag. Es musste z.B. beim Mapping Post – PostTag auf der PostTag Seite folgendes hinzugefügt werden.


/**
* @ORM\ManyToOne(targetEntity="Post", inversedBy="post")
* @ORM\JoinColumn(name="postid", referencedColumnName="id")
*/
protected $post;

Ein einfaches Mapping auf die postid hat nicht funktioniert, warum genau habe ich nicht herausfinden können.

User Auth

Da die OAuth Lösungen auf die schnell nicht funktionierten habe ich mich Entschieden das Auth Beispiel von https://github.com/samsonasik/SanAuth/ zu modifizieren und an meine Bedürfnisse anzupassen. In dieser Auth wird noch nicht auf Doctrine Entities zurückgegriffen, daher habe ich mithilfe von https://github.com/doctrine/DoctrineModule/blob/master/docs/authentication.md dieses angepasst. Die Anpassungen werde ich in einen anderen Beitrag nochmal genauer erklären.

Nächsten Schritte

Aktuell funktioniert das hochladen von Dateien und das Erstellen von Posts, sowie das einloggen dran. Als nächstes kommen die Kommentare und die Antwortfunktion dran. Außerdem müssen sich noch User registrieren können, dies werde ich über ein Aktivierungsmail lösen. Der nächste Blogeintrag kommt also bald.

Abstract Restful Controller

Heute habe ich die Controller für die „Restfulen Applikationen“ erweitert. Zend bietet hier bereits einen abstrakten Controller, diesen habe ich, angepasst an die neue Strukturen (Services, etc.) erweitertl Hierzu habe ich die Standard Methoden wie get, getList, save bereits ausimplementiert. Da für jedes Entity auch ein Validator vorhanden sein sollte, kann dies leicht verwiklicht werden. Es muss lediglich eine Instanz der jeweiligen Validatoren zurückgeben werden, sowie die möglich geboten werden, die entsprechenden Services zu laden. Hier kommt uns zu gute das über den ServiceLocater ja bereits mit Strings gearbeitet wird um ein entsprechenden Service zu laden, dadurch müssen wir dann nur mehr diesen bereitstellen.

. Der AbstractRestfulController überprüft vor dem konkreten „Action“ aufruf (preDispatch()), welche HTTP Methode verwendet wurde und reagiert dementsprechend darauf. Wird z.B. die post Methode verwendet, so wird die Methode zum erstellen eines Entities aufgerufen. Bei „get“ gibt es ja dann noch den Sonderfall, wenn keine id beim Aufruf in der Url verwendet wurde, so wird alles zurückgegeben. Dies würde auch bei einen PUT ohne id geschehen, diese Methode wirft aber, wenn sie nicht in der erbenden Klasse überschrieben wird eine Exception in der nur gemeldet wird das diese Methode hier nicht verfügbar ist (von diesen gibt es noch einige siehe Zend\Mvc\Controller\AbstractRestfulController).
Darauf aufbauend müssen wir jetzt nur die entsprechenden Methoden ausimplementieren wie z.B. hier:


/**
 * base controller class for the rest api controllers
 * gives you an basic instantiation of the service for the entity the conroller is for
 */
abstract class AbstractRestfulDoctrineController extends AbstractRestfulController {

    /**
     * Returns the name of the class of the entity
     * @return string
     */
    abstract protected function getMainServiceName();

    /**
     * @return DoctrineReadyService
     * @throws \Exception
     */
    protected function getMainService(){
        if($this->getMainServiceName() === null){
            throw new \Exception("Entity Name must be set is (".$this->getMainServiceName().") instead");
        }
        return $this->getServiceLocator()->get($this->getMainServiceName());
    }

    /**
     * @return JSONValidator
     */
    abstract protected function getMainValidator();

    /**
     * @param $data
     * @return BaseEntity
     */
    abstract protected function getMainEntityWithData($data);
    /**
     * Return list of resources
     *
     * @return mixed
     */
    public function getList()
    {
        return new JsonModel($this->getMainService()->findAllAsArray());
    }

    /**
     * Return single resource
     *
     * @param  mixed $id
     * @return mixed
     */
    public function get($id)
    {
        $id = $this->getEvent()->getRouteMatch()->getParam("id");
        $entity = $this->getMainService()->findByIdAsArray($id);
        if($entity === null){
            return $this->getResponse()->setStatusCode(Response::STATUS_CODE_404);
        }else{
            return new JsonModel($this->getMainService()->findByIdAsArray($id));
        }
    }

    /**
     * Create a new resource
     *
     * @param  mixed $data
     * @return mixed
     */
    public function create($data)
    {
        $response = $this->getResponse();
        $validator = $this->getMainValidator();
        if($validator->isValid($data)){
            $response->setStatusCode(Response::STATUS_CODE_201); //created
            return new JsonModel($this->getMainService()->save($this->getMainEntityWithData($data))->toArray());
        }else{
            $response->setStatusCode(Response::STATUS_CODE_400); // not acceptable
            return new JsonModel(array("status"=>"error", "messages"=>$validator->getMessages()));
        }
    }

    /**
     * Update an existing resource
     *
     * @param  mixed $id
     * @param  mixed $data
     * @return mixed
     */
    public function update($id, $data)
    {
        $validator = $this->getMainValidator();
        $response = $this->getResponse();
        if($validator->isValid($data)){
            return new JsonModel($this->getMainService()->save($this->getMainEntityWithData($data))->toArray());
        }else{
            $response->setStatusCode(Response::STATUS_CODE_400); // not acceptable
            return new JsonModel(array("status"=>"error", $validator->getMessages()));
        }
    }

    /**
     * Delete an existing resource
     *
     * @param  mixed $id
     * @return mixed
     */
    public function delete($id)
    {
        $response = $this->getResponse();
        $entity = $this->getMainService()->findById($id);
        if($entity != null){
            $this->getMainService()->delete($entity);
            $response->setStatusCode(Response::STATUS_CODE_202); //accepted
            return new JsonModel(array("status"=>"ok", "message"=>"entity deleted"));
        } else{
            $response->setStatusCode(Response::STATUS_CODE_404);
            return new JsonModel(array("status"=>"error", "messages"=>"entity not found"));
        }
    }
}

Hierbei ist zu sagen, dass das HTTP StatusCode management noch nicht optimal ausgebaut ist, bzw. man mit diesen sicherlich noch mehr arbeiten könnte.
Ein konkreter Controller könnten dann z.B. so aussehen:

class PatStammApiController extends AbstractRestfulDoctrineController {

    /**
     * Returns the name of the class of the entity
     * @return string
     */
    protected function getMainServiceName()
    {
        return 'Medinfo\Service\PatStammService';
    }

    /**
     * @return JSONValidator
     */
    protected function getMainValidator()
    {
        return new PatStammValidator();
    }

    /**
     * @param $data
     * @return BaseEntity
     */
    protected function getMainEntityWithData($data)
    {
        $entity = new PatStamm();
        $entity->fillWithArray($data);
        return $entity;
    }

Nun da wir einen funktionierenden Controller haben müssen wir auch noch die Routen anpassen, da diese ja hier doch leicht anders aussehen. Eine Route könnte dann z.B. so aussehen:


...
              'behandlungapi' => array(
                    'type' => 'segment',
                    'options' => array(
                        'route' => '/api/behandlung/[:id]',
                        'constraints' => array(
                            'id' => '[0-9]+',
                        ),
                        'defaults' => array(
                            'controller' => 'Medinfo\Controller\BehandlungApi',
                        ),
                    ),
                ),
...

Wie man sieht wird hier nur mehr die Id übergeben, die dann im AbstractRestfulController abgegriffen wird. Für komplexere Datenstrukturen (z.B. nur Behandlungen von einen Patienten) z.B. child routes gerabeitet werden um so eventuell speziellere Aufrufe zu ermöglichen.

siehe auch

Posts navigation

1 2
Scroll to top