Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si
… více »
Minule jsem se pokusil ve stručnosti popsat fungování kontrolerů v Zendu, zejména pak front controller, o action controllerech (potomcích Zend_Controller_Action
) jsem se zmínil ještě stručněji. Dnes bych rád, opět jen povrchně, popsal, jak se od kontroleru dostat až k html stránce, která se posílá uživateli do prohlížeče (nebo přesněji řečeno prezentační vrstvě, tedy view v onom MVC, což nemusí být jen html stránka).
Prezentační vrstva je v Zendu reprezentované především třídou Zend_View
.
Až dosud jsem k vytvoření view používal action controller, který na konci každé akce vygeneroval příslušné view automaticky. Každý action contoller má totiž přiřazenou pomocnou třídu (hepler class) ViewRenderer
, která, pokud není stanoveno jinak, se postará o vygenerování view, které očekává skript action.phtml
v adresáři application/views/scripts/contoller/
. Pokud chceme zavolat jiný skript, můžeme metodu render()
zavolat explicitně se jménem skriptu, který se má rendrovat. Pokud chceme zabránit defautlnímu volání ViewRenderer
(např. akce nevytváří přímo žádný výstup pro view nebo výstup ukládáme přímo do objektu respose
), můžeme to explicitně zakázat v příslušné akci voláním $this->_helper->viewRenderer->setNoRender(true);
.
Vytvoření view probíhá ve třech krocích: vytvoření instance Zend_View
, přiřazení proměnných vytvořené instanci a vykreslení (renderovaní). Vše obvykle probíhá v kontroleru nebo nějakém jeho pluginu. Instanci Zend_View
můžeme buď vytvořit jako instanci každé jiné třídy ($view = new Zend_View();
), v action controllerch pak můžeme využít metodu k tomu určenou, initView()
. Pokud inicializace neproběhla před voláním metody render()
, provede ji tato metoda.
Obě tyto metody přiřadí atributu kontroleru view
instanci třídy Zend_View
, můžeme ale použít i nějakou jinou třídu, která implementuje Zend_View_Interface
. Metoda render()
,jak již bylo řečeno, se stará o vytvoření výstupu. Můžeme ji volat s následujícími parametry: render(string $action = null, string $name = null, bool $noController = false)
. Parametr action
určuje jméno skriptu, který se má vykreslit a který musí být v adresáři views/scripts/controller_name
. Pokud by se skript nacházel v jiném adresáři, je potřeba nastavit parametr $noController
na hodnotu true
(nastavení cesty ke view skriptům se provádí pomocí $view->setScriptPath();
, případně $view->addScriptPath();
). Výstup je uložen do objektu Zend_Controller_Response
. Jednotlivé části výstupu mohou být pojmenované, k čemuž slouží parametr name
metody render()
(pojmenované bloky můžeme ukládat i přímo do objektu response
pomocí metod prepend($name, $content)
a append($name, $content)
). Pokud vytváříme instanci Zend_View
mimo action controller, musíme jí nastaví cestu v view skriptům($view->setBasePath()
). Tato situace například nastává, když vytváříme view v pluginu. Jednoduchý příklad použití: hlavička a patička stránky jsou obvykle pro všechny stránky stejné, tak abychom je nemuseli pokaždé nastavovat, můžeme si vytvořit plugin front controlleru, který se zavolá při každém požadavku a bude hlavičku a patičku nastavovat:
class ZendTest_View_HeadfootPlugin extends Zend_Controller_Plugin_Abstract { public function preDispatch(Zend_Controller_Request_Abstract $request) { $view = new Zend_View(); $config = Zend_Registry::getInstance()->get('config'); $view->setBasePath($config->myview->viewpath); $this->getResponse()->prepend('header', $view->render('header.phtml')); } public function postDispatch(Zend_Controller_Request_Abstract $request) { $view = new Zend_View(); $config = Zend_Registry::getInstance()->get('config'); $view->setBasePath($config->myview->viewpath); $this->getResponse()->append('footer', $view->render('footer.phtml')); } }
Velmi užitečnou metodou třídy Zend_View
je metoda $view->escape($variable)
, která nahradí příslušné znaky escape sekvencí (co se má escapovat můžeme měnit pomocí metody setEscape()
). Kapitolka v manuálu, která stojí za nahlédnutí, ale je zbytečné ji sem opisovat, je View Helpers (Partial Helper, Head helpery, Translate Helper a další).
K rozvržení jednotlivých prvků v prezentační vrstvě slouží Zend_Layout
. Slouží v podstatě jako šablona, podle které se skládají jednotlivé části (view popisovaná v předchozím odstavci) do výsledného dokumentu. Pěkný příklad použití Zend_Layout
uvedl Karel Benák v diskuzi pod prvním zápiskem o Zendu. Je zbytečné jej sem opisovat, takže se jej pokusím jen trochu okomentovat a doplnit, co mi tam na první pohled, jako člověku Zendu neznalého, nebylo zcela jasné. Řádek $layout = Zend_Layout::startMvc();
vytvoří instanci Zend_Layout
a zaregistruje ji ve front contorlleru, který po ukončení dispatch smyčky vygeneruje konečnou podobu prezentační vrstvy aplikace. $layout->setConfig($config);
načte konfiguraci layoutu. Typicky nastavujeme hlavně cestu k layoutu. Zkráceně můžeme použít $layout = Zend_Layout::startMvc($config->testlayout);
(zde je navíc v XML konfiguračním souboru přidán obalujicí element testlayout
). Parametrem metody setConfig
je objekt Zend_Config
. Obvykle jeho instanci vytvoříme v souboru bootstrap.php, kde jej rovnež uložíme v registru (kontejner sloužící uchovávání objektů a hodnot, které mají být dostupné v celé aplikaci):
$config = new Zend_Config_Xml('../../zendTest/config.xml', 'production'); $registry = Zend_Registry::getInstance(); $registry->set('config', $config);Zbytek příkladu mi příjde vcelku jasný a asi nepotřebuje další komentář.
Tiskni
Sdílej:
$this->layout()->code
mělo být $this->layout()->content
.
Až se např. dostaneš k Zend_Form, zjistíš, že si celý formulář můžeš nadefinovat právě v konfiguračním souboru a není třeba jej složitě programovatMe osobne presne tohle vadi. Nemam rad generovani markupu v PHP a pak jen nekde
<?= $this->form ?>
a to proto, ze se to pak vsechno rozjizdi a v ramci view nemam kontrolu nad stylovanim a vlastnim pojetim markupu -- nemluve o praci v tymu programator-koder.
= $this->render('header.phtml') ?>
a = $this->render('footer.phtml') ?>