Kuidas alustada composer.phar kasutamist

Veel mõnda aega tagasi ei olnud PHP jaoks ühtset moodust teekide paigaldamiseks. Olenevalt raamistikust olid lahendused erinevad. See muutus koos Composer’i ilmumisega, mis on tänapäevaks muutunud standardseks viisiks sõltuvuste lisamiseks rakendusse või isegi raamistike komponentide haldamiseks. Composerit on lihtne kasutada nii vabavaraliste kui ka organisatsiooni siseste pakkide paigaldamiseks ning projektide seadistamiseks.

NB! Käesolev blogiartikkel on suunatud pigem algajale PHP arendajale, kes on juba kokku puutunud mõne levinud raamistiku, näiteks Laraveli või Symfonyga, ning kes soovib katsetada midagi nullist ise ehitada.

Lühidalt öeldes on Composer pakihaldur, kuid tegelikult teeb see veel palju rohkemat. Composer on kõikides Zone platvormiga serverites juba paigaldatud ning seda saab kasutada virtuaalserveris ilma lisatööta. Composer lahendab mitmeid probleeme, mis arendajatele muidu lisatööd tekitaksid. Kaks kõige olulisemat neist on järgmised:

1. Sõltuvuste ja teekide haldus

Kui soovid kasutada mõnda kolmanda osapoole teeki, siis piisab Composeris vaid ühest käsust selle lisamiseks. Eelduseks on muidugi see, et vastav teek juba asub Composer’i registris. Register võib olla nii avalik kui ka organisatsiooni sisene, kinnise koodi tarbeks.

Composer teeb teekide paigaldamise lihtsaks, võimaldades seda teha vaid ühe käsuga. Paigaldamise käigus kontrollib Composer teekide omavahelist sobivust. See on eriti kasulik olukorras, kus ühe teegi versiooni sobivus erineb teise teegi omast ning mõlemad teegid sõltuvad kolmandast paketist. Composer leiab võimalikult uue sobiva ja kattuva versiooni. Kui see pole võimalik, siis annab Composer sellest teada.

2. Klasside automaatne laadimine

Need, kes tunnevad veidi rohkem ajalugu, on teadlikud ajast enne klassi autolaadimise standardeid. Tollal kirjutas iga rakendus oma koodi selleks, et otsida üles klassi sisaldavat faili, mida ei olnud veel PHP koodi sisse laetud. Mõnel juhul laeti koodi käivitamise alguses sisse kõik klassid, liites kõik failid kokku “require_once” käsuga, mis võis koodis kasutusele tulla.

Õnneks on aja jooksul loodud PSR-0 ja kaasaegsem PSR-4 standardid, mis defineerivad, kuidas klassi nimi peaks vastama failipuu hierarhiale. Tänapäeval ei pea sellele enam eriti süvenema, sest Composer aitab seadistada kõik klasside autolaaderid ning PHP koodi kirjutaja saab keskenduda vaid oma tööülesannetele.

Lihtne Composer’i näidis

Ükskõik kui lihtne rakendus või skript kasutusel on, alati on lihtne alustada Composer’i seadistamisega, kui on plaan kasutada väliseid teeke.

Selleks, et tutvustada Composer’i miinimumtasemel võimekusi ning näidata, kui lihtsaks see elu teeb, loome CLI (terminalis käivitatava) rakenduse, mis käib HTTP kaudu kontrollimas mõnda URL-i ning selle HTTP koodi. Kuigi seda saab teha ka lihtsalt Curl’iga, kasutame näidise tarvis eraldi pakki nimega Guzzle.

Loome kõigepealt kausta nimega pinger ning siseneme sinna:

mkdir pinger
cd pinger

PHP koodi kirjutame faili nimega pinger.php. Oletame, et meie enda kirjutatud klassid asuvad kaustas src ning on loodud vastavalt PSR-4 standardile.

Alustame projekti käivitades järgmise käsu:

composer init

Seejärel küsitakse mitmeid küsimusi. Enamik neist on valikulised, aga siiski tasub seadistada mõned olulisemad.

• Package name on loodud rakenduse vabalt valitud nimi kujul paki-tootja/paki-nimi.
• Description on lühikirjeldus rakenduse või teegi iseloomustamiseks.
• Author defineerib autori, mis on kasulik, kui loodud tarkvara plaanitakse avalikult kättesaadavaks teha.
• Minimum Stability määrab ära Composer’i kaudu lisatud teekide miinimum stabiilsuse nõude. Rakendust luues on sageli oluline tasakaal versioonide stabiilsuse ja uudsuse vahel. Selle saab seadistada väärtustega dev või stable, mis on iseennast kirjeldavad.
• Package Type kirjeldab loodava tarkvara tüüpi. Näiteks “package” sobib teegile, mida kasutatakse osana mõnes teises rakenduses, või project iseseisvale rakendusele, millele liidetakse teeke.
• License väli tuleb kindlasti täita, kui kood saab avalikult kättesaadavaks. Muul juhul ei mängi see erilist rolli.

Järgmisena küsitakse, kas soovitakse paigaldada juba mõnda sõltuvust, aga need osad jätame hetkel vahele lihtsalt “Enterit” vajutades.

Kui jõuame küsimuseni Add PSR-4 autoload mapping?, siis loome PSR-4 autoload seaded, mis tuletatakse kõige esimesest küsimusest. See tähendab, et PascalCase versioon meie paki nimest jagab tootja ja paki nime namespace’de vahel ära. Näidises seadistame selleks MyPackage.

Järgmisena on vaja vaid loodud composer.json kinnitada, vajutades Enter.

Composer lõi vaikeseadistusega järgmised failid ja kataloogid:

• src kataloog, kus on rakenduse namespace’is olev kood
• vendors kataloog, kuhu paigaldatakse sõlutuvused, ehk composeri kaudu paigaldatavad teegid. Selles kaustas paikneb ka autoload.php fail, mis tuleb PHP skriptis include’da
• composer.json fail, composer’i seadistused projektis.

Nüüd, kui composer.json on loodud, peame kasutusele võtma selle autoloader’i, mis hoolitseb nii rakenduse enda kui ka lisatud teekide klasside automaatse laadimise eest. Selleks loome rakendusele CLI-s kasutatava PHP faili nimega pinger.php.

<?php

use Composer\Autoload\ClassLoader;

// laeme sisse composer'i
require_once __DIR__ . '/vendor/autoload.php';

Code language: PHP (php)

Paigaldame nüüd HTTP klientrakenduse Guzzle 7. Selleks käivitame käsu:

composer require guzzlehttp/guzzle:^7.0Code language: JavaScript (javascript)

Meie juurkataloogi tekkis fail nimega composer.lock. See fail hoiab täpset versiooni paigaldatud sõltuvustest antud hetkel. Kui järgmisel korral käivitada composer install, siis paigaldatakse teegid täpselt samas versioonis, kindlustades sellega olukorra, et kasutusel on täpselt sama minor ja patch versioon, mis rakenduse loomise või uuendamise ajal.

Täiendame pinger.php faili nii, et see kasutaks Guzzle’i teeki mõne URL-i HTTP vastuse koodi kuvamiseks.

<?php

use GuzzleHttp\Client;

require_once __DIR__ . '/vendor/autoload.php';

$siteUrl = 'https://www.google.ee';

$client = new GuzzleHttp\Client(['base_uri' => $siteUrl]);
$response = $client->request('GET', '');

echo $response->getStatusCode();
Code language: HTML, XML (xml)

Antud skript annab väljundiks vastava URL-i HTTP koodi, mis 2XX puhul tähendab õnnestunud päringut.

Kui on soov luua veebirakendus, võiks docroot, kuhu Apache HTTP päringud suunatakse, asuda eraldi kaustas, näiteks public. Sinna tuleks paigutada nn front controller index.php, mis võtab vastu kõik päringud ja vastavalt sellele käivitab koodi src kaustas olevate klasside abil.

Loome faili public/index.php.

<?php

use MyPackage\Controller;

require_once __DIR__ . '/../vendor/autoload.php';

(new Controller())->showPage();Code language: HTML, XML (xml)

Loome controller’i tarvis klassi faili src/Controller.php. Kuivõrd me varem seadistasime PSR-4 autolaaduri vastavale namespace’ile, siis laetakse index.php-s vastav klass sisse eraldi faili määramata.

<?php

namespace MyPackage;

use GuzzleHttp\Client;

class Controller
{
    public function showPage()
    {
        $siteUrl = 'https://www.google.ee';

        $client = new Client(['base_uri' => $siteUrl]);
        $response = $client->request('GET', '');

        echo $response->getStatusCode();
    }
}Code language: HTML, XML (xml)

Kui nüüd suunata docroot public kausta peale, siis kuvatakse brauseris sarnaselt käsurea rakendusele HTTP kood.

NB! Reeglina ei tohi docroot’iks määrata kausta, mis sisaldab endas Composer’iga lisatud või rakenduse klasside faile. Seepärast lõime siin public kausta eraldi ning kogu kood asub kataloogipuus selle kohal, et üle HTTP ei oleks neile ligipääsu.

Kokkuvõtteks

Loodud lahendus pakub lihtsat viisi, kuidas alustada nullist PHP rakenduse loomist, kasutades selleks Composer’it. Kuigi jalgratast ei ole alati mõistlik uuesti leiutada, siis keele tundma õppimiseks või väga lihtsate rakenduste loomiseks võib mõistlik olla kirjutada rakendus teinekord ka ilma raamistikuta. Käesolev postitus ongi kirjutatud pigem suunisena ning selles kirjeldatud näidis tegelikult midagi keerukat ei tee 🙂

---

NB! Loe kindlasti lisaks ka kaheksakst Composer’i käsust, mida iga PHP arendaja teada võiks.