De custom management omgeving krijgt structuur

De custom mangement omgeving die ik aan het bouwen ben begint dan toch structuur te krijgen. Het prototype ontwerp liet zich door creatieve en flexibele keuzes maken snel vangen in een structuur die toch al aardig in beton gegoten begint te raken. Sterker nog het geheel heb ik direct al geïntegreerd binnen het Wpx framework.

De eerste stap die ik heb gezet is om de routing niet meer door WordPress te laten regelen. In plaats daarvan maak ik nu gebruik van de “do_parse_request” filter waardoor ik de routing van mijn manager in eigen hand heb genomen. Feitelijk komt het er op neer dat de functie die aangeroepen wordt door de filter kijkt of de request uri met een bepaald keyword begint. Wanneer dat het geval is dan wordt de request verder door Wpx afgehandeld en doorgeleid naar de custom management omgeving. Dit stuk Wpx code heb ik hieronder neergezet.

    public function init_manager($bool,$wp,$extra_query_vars)
    {
        $uri = trim(esc_url_raw(add_query_arg([])), '/');
        /**
         * Remove query args if any 
         */
        if ($found = strpos($uri,'?')) {
            $uri = substr($uri,0,$found);
        }


        if (substr($uri,0,strlen($this->manager_uri)) == $this->manager_uri) {
                        
            $route = explode('/',substr($uri,strlen($this->manager_uri)+1));

            $name = $route[0];
            if (isset($this->manager_classes[$name])) {
                $class = $this->manager_classes[$name];
                $manager = new $class($this);
                $manager->init();
                $manager->execute_action($route);
                exit();
            }
        }
        return true;

    }

Door Wpx wordt de request vervolgens doorgeleid naar een object dat de verdere routing en uitvoering van de request bepaald. Hierbij heb ik een basis object gemaakt dat de routing regelt, bepaalde basis actions definieert zodat die niet op applicatie niveau hoeven te worden gemaakt en er zijn functies als koppeling fungeren naar de daadwerkelijke uitvoer van HTML code en het verwerken van de invoer daarvan.

De HTML code zelf heb ik óók opgenomen in een class die onderdeel van Wpx is. Ook dat is weer best “dirty”. Daarom heb ik daarvoor een aparte class gemaakt die wordt geïnstantieerd door de functies die vanuit het basis object verantwoordelijk zijn voor de uitvoer van HTML en de verwerking van de invoer daaruit.

Op deze manier is er één class die afwijkt van hoe de Wpx classes normaliter zijn opgebouwd. Aan de andere kant hoeft er op deze manier niet voor één of enkele templates een voorziening in Wpx te worden gebouwd om die op te slaan en op te halen. Uiteindelijk is het uiteraard wel de bedoeling om hier een andere oplossing voor te vinden. Op dit moment werkt deze oplossing uitstekend. Het is een beetje op zijn Nederlands polderen in de code.

De basis objecten worden op applicatie niveau verder uitgebouwd tot manager objecten met eigen actions die bepalen welke uitvoering (execution) gewenst is. Daarbij heb ik als structuur gekozen om op drie dingen te letten, de request method (get, post, put, delete of “any”), de post_type op basis van het post_id in de request én de action. Daarnaast heeft ook de manager een vaste uri én het manager object heeft zelf een naam.

Op die manier krijg je een volgende structuur van de URI:

GET %manager_uri% / %manager_object% / %post_id% / %action% / %var1% / … / %varN%

De uitvoering komt daardoor op het volgende neer:

  1. De “do_parse_request” filter functie wordt aangeroepen
  2. Er wordt gecontroleerd of dat %manager_uri% overeenkomt met het begin van de request uri.
  3. Er wordt gekeken of er een manager object is geregistreerd met de naam die overeenkomt met %manager_object%. Dat wordt dan geladen.
  4. Het manager object neemt de verdere uitvoering over en bepaald aan de hand van de request method, %post_id% en %action% wat de verdere uitvoering moet zijn.
  5. De callback functie die overeenkomt met de drie voornoemde variabelen wordt aangeroepen.
  6. De callback functie haalt de relevante instance op, voert eigen instructies uit en/of instantieert de class met de HTML uitvoer functies en roept de betreffende functie aan.
  7. De HTML wordt door de class uitgevoerd of er wordt juist invoer vanuit de HTML interface door het systeem opgeslagen.
  8. Indien de uitvoering nog niet ten einde zorgt het manager object ervoor dat de gebruiker naar de juist pagina wordt geredirect.