vlastní formulářové prvky jako extension

Ještě mě napadlo… Pokud chceš své form controls dát ostatním k dispozici a ulehčit jim integraci, můžeš připravit traitu:

trait Polki\FormControls
{
	public function addOwnInput(string $name, string $label): OwnInput
	{
		return $this[$name] = new OwnInput($label);
	}
}

a zájemce, který si bude chtít svůj formulář o tyto továrničky rozšířit jen udělá:

class AppForm extends Nette\Application\UI\Form
{
	use Polki\FormControls;
}

Ta extension může vypadat nějak takto (píšu dost z hlavy, takže to možná nebude úplně přesně, ale aspoň pro odpíchnutí to snad postačí):

use Nette\DI\CompilerExtension;
use Nette\PhpGenerator\ClassType;

class OwnInputExtension extends CompilerExtension
{

	/**
	 * Metoda afterCompile() se na rozšířeních volá poté,
	 * co se zkompiluje kontejner. Jako parametr dostává
	 * předpis onoho zkompilovaného kontejneru, takže ho
	 * může ještě na poslední chvíli upravit.
	 */
	public function afterCompile(ClassType $class): void
	{
		// typicky se upravuje metoda initialize(), která
		// se na kontejneru volá při jeho instancování
		$initialize = $class->methods['initialize'];

		// do těla metody přidáme řádek s kódem, který
		// zaregistruje extension method nad formulářem
		$initialize->addBody(
			'Nette\\Forms\\Container::extensionMethod(?, ?);',
			[
				'addOwnInput',
				'function ($container, $name, $caption = NULL) { return $container[$name] = new My\\Own\\Input($caption); }'
			]
		);
	}

}

Nicméně pokud chceš i to, aby tu metodu našeptávalo IDE nebo aby o ní věděl např. PHPStan, nevyhneš se potřebě v aplikaci vytvořit klidně prázdného potomka třídy Form a tu metodu tam aspoň oanotovat pomocí @method

@jiri.pudil
Tak toto vyhazuje exception

Cannot dump closure.

Na konci toho pole. Nejake napady?

@Milo
Nechci pridavat vlastni cele formulare a ani jen vlastni prvky, od kterych bych musel rucne vytvorit instanci. O to by se mel starat formular po tom, co mu reknu, co tam chci.

Vydanim vlastniho celeho formulare se musi vsude, kde byl pouzit klasicky nette form prepsat usingy a pote i formularove prvky tak, jak potrebujeme.

Ukolem je to co nejvice zjednodusit, takze extensionMethod() mi prijde jako nejlepsi volba, jelikoz se zmeni pouze dany input.

Toto reseni je treba, jelikoz mame hotovych spousty projektu, ktere jsou dost rozsahle a tyto inputy se budou nasazovat i zde, tak aby se prace co nejvice usnadnila.

Napovedy ide jsou zbytecne v tomto pripade, protoze nepujde o zadne slozite prvky. Jde jen o rozsireni formatovani vstupnich a vystupnich dat, aby to nemusel uzivatel psat rucne ale pouzivat jen setvalue a getvalue metody.

Timto bych uzavrel tema cistoty kodu na ukor potreb.

Otazka zustava stejna. Jak se zbavit Exception pri nastavovani extensionMethod?

Edit 1
Traita je mozna cista, ale nepripada v uvahu. Na jedne aplikaci mame radove stovky formularu a pro kazdy si vytvaret vlastni formular, ktery bude vyuzivat traitu je sebevrazda.

Editoval Polki (5. 12. 2018 12:02)

Jsem ve firme kratce. Videl jsem projekty. A vsude kde vytvari formulare to delaji tak, ze v presenteru vlozi toto:

public function createComponentMyForm() {
    $form = new Ui\Form();
    ...
}

Jak do tohoto jednoduse zakomponovat traitu?
Aby se to zmenilo na jednom miste a nemusel menit vse vsude?

Za to ale ja nemuzu, ze to tak maji delane :-D

Takze..

Nejake navrhy? Aby se nemusel predelavat cely system?

Edit 1
Oni totiz se ucili v nette z návodu ‚Piseme prvni aplikaci‘. Tam je to tak ukazane, tak si mysleli, ze to je DOGMA a uz to tak deleli vsude.

Editoval Polki (5. 12. 2018 15:49)

@OndřejKubíček
To je posledni moznost. Nechci se kdo vi jak dlouho prodirat něčím kódem, proto se ptam tady, kde to muze pomoct i lidem, kteri budou neco takoveho resit v budoucnu.

Ty chceš napsat DI extension bez toho, abys tomu rozuměl. Řešení je na pár řádků, ale nikdo to nenapsal, protože to je špatné řešení. A nikdo by ho v budoucnu neměl použít.

Jestli aplikace používá 100ky formulářů bez továrny, je to chyba v návrhu. Oprava je časově náročná. Může se udělat ale postupně. Třeba takhle.

• trait s vlastními inputy
• vlastní Form poděděný od UI\Form
• továrnu na vlastní Form
• tam, kde se bude formulář upravovat nebo vytvářet, použít továrnu
• typehinty se díky dedičnosti opravit nemusí

Milo napsal(a):

Ty chceš napsat DI extension bez toho, abys tomu rozuměl.

Kdybych tomu rozumel, tak se tady neptam. To je myslim logicky odvoditelne. Co naopak logicky odvoditelne neni je to, ze ty si prosazujes to co rikas bez ohledu na nejake pozadavky. To je jako by ti nekdo rekl ze chce abyse si mu upekl chleba v peci ale ty se ho snazil presvedcit, ze lepsi je rohlik z trouby i kdyz on potrebuje proste jen jednoduchy chleba.

Řešení je na pár řádků, ale nikdo to nenapsal, protože to je špatné řešení. A nikdo by ho v budoucnu neměl použít.

Co je a neni spatne reseni se da polemizovat. Kazdemu se zda lepsi neco jineho. Pro nase vyvojare je delani tovarny zbytecny kod navic.
Nehlede na to, ze vetsina extension rozsiruje prave jen formular, viz napriklad hojne pouzivany replicator. Takze to asi pouzite je, ale to by byla hadka o tom a ne vecna konverzace.

Jestli aplikace používá 100ky formulářů bez továrny, je to chyba v návrhu. Oprava je časově náročná. Může se udělat ale postupně. Třeba takhle.

• trait s vlastními inputy
• vlastní Form poděděný od UI\Form
• továrnu na vlastní Form
• tam, kde se bude formulář upravovat nebo vytvářet, použít továrnu
• typehinty se díky dedičnosti opravit nemusí

U vsech vyse uvedenych zpusobu je nutny rozsahly zasah do kodu a nebo nutna tvorba tovaren a nebo vlastnich formularu, coz jak jsem psal vyse a cemu ty nerozumis neni zadane chovani.

Kdyz se tak ohanis cistotou, tak by me taky zajimalo, co je cisteho na tom, kdyz vim, ze bude napriklad v presenteru formular, tak si na nej vytvaret tovarnu, ktery mi stejne vrati jen instanci tridy form a neudela nic jineho. Takze vznikne trida navic, coz je psani navic, processorovy cas navic, pamet navic atd by se dalo pokracovat…
A to nemluvim o tom, ze kdyz dam jednu tovarnu pro vsechny formy, tak ve formu s dvemi obyc inputy nacitat spousty dalsich knihoven ktere nepotrebuju nekde pres tovarnu je uplne stejne spatne reseni jako udelat extension primo klasickemu formu.

Takze myslim ze uz se nemame tady o cem bavit a budu primarne resit toto s @OndřejKubíček
Timto ti diky a urcite toto budu i nadale vyuzivat ve svych projektech, kde to jiz dlouhou dobu takto mam, ale tady se to tak proste bohuzel pouzit neda. Takze diky za vecny prispevek

@Polki Promiň, máš pravdu, že si kód můžeš psát, jak chceš a já neodpověděl na původní otázku. Nebudu na ní ale odpovidat, myslím si že to není správné.

Mysteria napsal(a):

Polki napsal(a):

Kdyz se tak ohanis cistotou, tak by me taky zajimalo, co je cisteho na tom, kdyz vim, ze bude napriklad v presenteru formular, tak si na nej vytvaret tovarnu, ktery mi stejne vrati jen instanci tridy form a neudela nic jineho. Takze vznikne trida navic, coz je psani navic, processorovy cas navic, pamet navic atd by se dalo pokracovat…

Před pár lety bych se pod to podepsal a dělal jsem to stejně. Ale věř mi, stačilo si jednou namlátit ústa a od té doby už opravdu nejsem línej, napsat ten jeden interface navíc.

Ono to navíc většinou bývá tak že ve snaze na začátku si něco ulehčit nebo ušetřit čas se něco udělá né úplně tak, jak by mělo a až za půl roku budeš chtít něco upravit, tak zjistíš, že kvůli tomu „ušetřenému“ času dáš dvojnásobek na tu potřebnou úpravu. Vlastní zkušenost. :)

@Mysteria nejde o usetreny cas. Ani o jednoduchost navrhu. Spis jde o pro a proti.
Vsadim se, ze taky nebudes cpat do use vsechny knihovny co existuji, kdyby si je nahodou nekdy potreboval, ale pridas ji tam az tehdy, kdyz je to treba.
Proc? Proc vlastne je treba kdnihovny linkovat rucne a neni vsechno uz defaultne prilinkovane?
Dokazete si predstavit jak by to trvalo? To je reseni, ktere proste neudelas, protoze hello world by se zobrazoval tyden.

Proc to tak teda delat u formularu? Jasne, pokud potrebuju specificky formular, ktery budu jen rozsirovat, tak je nejlepsi volba udelat nejakeho predka, ktery bude pro tyto formulare spolecny a pouzivat jej tam, kde je treba. Takze v tomto pripade nejlepsi pouzit tovarnicku, cimz eliminujes do znacne miry duplicitu kodu. Tak samo, kdyz u techto formularu je treba udelat obsluhu, ktera se stale opakuje, tak tuto obsluhu nebudes tvorit 1000× v presenteru, ale vhodis ji jednoduse do tovarnicky a tahas si formular odtud.

Ale pouzivat tovarnicku na formulare, ktere ani jeden nemaji zadnou stejnou cast vyjma radku new Form();??? Jaky je tam ucel tovarnicky? Neudela kod prehlednejsim, neodstrani duplicity (misto new Form musis stale nejak ziskavat instance formu byt z tovarnicky), zvysuje processorovy cas potrebny k vykonani dane akce, zvysuje naroky na pamet, jelikoz se na haldu ukladaji nove instance trid a v neposledni rade jde o zabrany cas tvorbou teto tovarnicky. Jedine plus je, ze kdyby nekdy vyvstaly duplicity, tak je lze spojit do tovarnicky. Ale kdyz mas navrh formularu a kazdy je jiny, tak to je spise kontraproduktivni.

Nyni pristoupim na toto reseni a udelam vlastni tovarnicku na vlastni form, ktery rozsiruje klasicky form o formularove prvky. A ted nasledujici UseCase:

• formular vyuzije kolega v aplikaci.
• kolega zjisti, ze potrebuje dalsi input, ktery nema problem si vyrobit.
• vyrobi si novy input a aby to mohli pouzivat ostatni, tak si k nemu vytvori take svou tovarnicku na svuj form a zaregistruje si jej jako extension.
• kolega pouziva vesele muj form a svuj form.
• treti kolega prijde a rekne ja potrebuji inputy z formulare od kolegy1 a zaroven v tom samem formulari potrebuji inputy od kolegy2
• jak na to???

V tento moment zpoza zavesu vyskoci traita a hodi po nem ockem.
Pojd si pro me ja jsem reseni.
A kolega 3 zajasa jupiiii.
Kolega1 i Kolega2 predelaji vlastni formulare na traity a Kolega3 si vesele vytvori svuj form, ktery pouzije obe dve traity.
Situace zda se vyresena.
Jenze, takovych trait si vytvori N. Kazda bude mit nejakou svoji slozitost a kdyz pak bude pomoci tohoto formulare kolega3 delat komponentu, ktera bude mit napriklad 1 klasicky addText, tak i takovy formular bude mit narocnost komplexniho formulare, protoze se nacita spousta metod a pravidel.
Nic proti traitam ale v takovem pripade Kolega3 koukne po reseni, kde misto pouzivani toho sameho formu, kde se vyuzivaji vsechny traity sahne po reseni, kdy pro kazdy formular vytvori vlastni tovarnicku, ktera mu vrati instanci formulare upraveneho tak, aby vyuzival traity pouze ty, ktere je opravdu nutnost nacitat.

Pokud se pletu v tom jak funguji traity prosim o opravu.

Timto resenim ale vznikne M tovaren, kde je kazda jina a opet jsme u problemu, ze tyto tovarny jsou vlastne kus navic, ktery prinasi jen a pouze zvyseny processorovy cas, vetsi naroky na pamet a v neposledni rade take casove naroky na psani techto tovaren.

Nyni prichazi na radu opomijene extension method, ktere vlastne funguje stejne jako traita, ale s tim rozdilem, ze k tomu nemusis psat navic zadnou tridu bokem, takze odpada processorovy cas navic a pametova rezie trid navic.
Tim jsme si nacitani jednoho formulare zrychlili sice asi a milisekundu, ale pri 1000 pripojenych uzivatelich naraz se usetri vterina casu. Coz uz je sakra dost.
Kouzlo navic spociva v tom, ze se jiz nemusi dal nic psat a tedy to nezrychluje pouze odpoved klientovi, ale take cas nutny pro vyvoj aplikace. Ano, je zde stejny problem jako pri traite a pri N vlastnich formularovych prvcich, ale toto se do jiste miry resi tim, ze vlastne tato metoda neexistuje do doby, nez je pouzita. (Pokud se nepletu) je to jako kdyz se pouziva dedicnost a priradite potomka do promenne rodice. V pameti je ulozen cely potomek, ale processorova prace s tim je rychlejsi, jelikoz processor nevi, ze tyto metody a promenne potomka existuji, dokud mu to nereknes.

Ac to hodne lido ocividne nema rado, tak extensionMethod nebylo pridano pro nic za nic. Stejne jako php magicke gettery a settery. Kouzelne dynamicky pridavat a ubirat libovolne property? To je sen. Ulehci to psani kodu a instance te same tridy mohou mit jine property, coz je nekdy treba a nijak to nezpomaluje cas vykonavani, jelikoz nemusi tyto tridy dedit od spolecneho predka, ktery ma vsechny mozne property, ktere si vubec muze clovek nadeklarovat, ale ma jen ty sve, cimz s ostatnimi nepracuje. Vytvari se az kdyz jsou treba.

Taky se timto da poukazat na Nette motto: less code = more security. Vytvaret zbytecne tridy muze byt bezpecnostni dira.

Programatori nemaji radi to, co bylo vymysleno pro dobrou vec a urychli to vse, ale jsou natolik hloupi, ze to neumeji pouzit a tedy tam delaji spousty chyb. Viz GOTO.

@Milo
Nepsal jsem, ze si muzu kod psat jak chci. Jen jsem se snazil poukazat na to, ze kdyz nekdo pise kod podle navodu na ofiko Nette strankach a neni tam vysvetleno proc je to zrovna takto, tak pak vyvstavaji problemy, ktere se daji jednoduse resit. Ovsem proc to delat jednoduse, kdyz to jde tak krasne slozite ze?
To, ze tady na foru nedokazou ostatni odpovedet primo na otazku na kterou se tazajici pta, jsem si celkem zvykl, kdyz koukam na dotazy jinych. Ale ze to tak bude delat i nekdo, kdo ma znacku Nette Core, tak to jsem si nemyslel. Cekal jsem, ze takovy clovek uz bude trochu nad veci, dobre poradi, jak by to melo byt spravne (coz jsi udelal), ale take zodpovi dotaz, na ktery se tazajici ptal i kdyz s vystrahou NEDOPORUCENO.
Ocividne to tak nefunguje a jako vzdy si budu muset poradit sam. Nejakymi hacky, ktere se ani me nelibi. Uz se nedivim, ze na jinych nez nette forech je vetsinou konecna odpoved: ‚nepouziven nette‘ a to ja se za nej biju zuby nehty, prptoze mi za tech 12 let, co delam web aplikace usetril hodne prace.

Spis me mrzi tento pristup ale s tim nic neudelam kazdy jsme nejaky. Naopak si myslim, ze kdyz nemas v umyslu odpovvedet na otazku, tak by si se nemel konverzace ucastnit. Nic proti tve osobe. Ale takove komentare jsou stejne zbytecne jako tridy, ktere vytvori instanci neceho a jen tu vrati.

A vzhledem k tomu mottu, co jsem zminoval bych cekal, ze nette nejakou rychlou ficuru na to jak pridat formularove prvky do formulare tak, aby se o vytvareni jejich instanci staral sam formular bude mit a ne, ze kvuli naprogramovani bananu budu muset vytvorit gorillu a k ni cely prales.

Edit 1
Zkoušel jsem najít pár článků o traitách, abych si na ně udělal obrázek i od jiných lidí, než jen od zastánců Nette. Našel jsem tento článek a přijde mi celkem zajímavý. Můžete se tu podělit o názor.

Editoval Polki (5. 12. 2018 22:32)

Taky mi prijde dost zajimave, ze se tu vsichni ohanite tim jak nette umite zvladate jak se ma co delat a jak je co ciste a kdo vi co, ale odpovedet mi na tento dotaz, nebo jednomu chudakovi na jeho dotaz , tak to je problem.

Nemluve o tomto chudakovi, ktery potreboval poradit s celkem banalni veci a vsichni se na nej 17 dni pekne vykaslali.

Polki napsal(a):
Stejne jako php magicke gettery a settery. Kouzelne dynamicky pridavat a ubirat libovolne property? To je sen. Ulehci to psani kodu a instance te same tridy mohou mit jine property, coz je nekdy treba a nijak to nezpomaluje cas vykonavani, jelikoz nemusi tyto tridy dedit od spolecneho predka, ktery ma vsechny mozne property, ktere si vubec muze clovek nadeklarovat, ale ma jen ty sve, cimz s ostatnimi nepracuje. Vytvari se az kdyz jsou treba.

Jestli tohle myslíš vážně, tak bych opravdu chtěl vidět ty komplexní systémy bez statické analýzy a testů, které fungují vždy správně a rychle, protože řekl bych že za těhle podmínek se ta šance blíží limitně nule. :) Respektive pár takových jsem viděl a místo úpravy se vždy přepisovala celá aplikace. Možná byla o pár ms pomalejší, ale minimálně byla vždy v takovém stavu, že na tom mohl kdokoliv další znalý daného frameworku pracovat, tzn. v Nette byly použity principy z Nette, v Symfony ze Symfony (tzn. v Symfony projektu použiju Twig i když Latte je pro mne mnohem lepší, ale to je mi k ničemu, když se ti 99% lidí na správu aplikace vykašle, protože jsi použil něco, co se prostě v Symfony nepoužívá).

Nehledě na to, že když ti jde o milisekundy procesorového času, tak nevidím důvod proč použít na něco tak kritického PHP, když můžu použít třeba GO, který bude 100× rychlejší samo o sobě i bez toho, abych řešil jeden „blbej“ interface.

@Polki Tím posledním příspěvkem jsem chtěl naznačit, že už nebudu odpovídat. Diskuze se tu rozplizla na X nesouvisejících témat.

@BigCharlie Traita:

trait TCustomFormControls {

	public function addContainer(...) {
		... // returns new CustomContainer();
	}

	public function addMyControl(...) {
		...
	}

}

class CustomForm extends Form {

	use TCustomFormControls;

}

class CustomContainer extends Container {

	use TCustomFormControls;

}

Editoval Martk (29. 12. 2018 8:15)

@Polki Používám je velmi zřídka a jen tam, kde je to vhodné a splňuje to účel, tady imho ano.

Když si stáhneš celý repozitář přes composer, tak composer načítá třídy, až když je kód v běhové smyčce potřebuje. Těch 5 nepoužitých neincludne

Na poslední dotaz nemůžu odpovědět, protože nerozumím o co má jít.

Martk napsal(a):

@Polki Používám je velmi zřídka a jen tam, kde je to vhodné a splňuje to účel, tady imho ano.

Když si stáhneš celý repozitář přes composer, tak composer načítá třídy, až když je kód v běhové smyčce potřebuje. Těch 5 nepoužitých neincludne

Na poslední dotaz nemůžu odpovědět, protože nerozumím o co má jít.

@Martk Takže pokud si vytvořím 20 trait, tyto hodím na git a stáhnu pomocí composeru a následně použiji jen 2 takto:

class MyForm extends Form {
    use MyTraits\trait1;
    use MyTraits\trait8;

    public function __construct(Translator $translator = null, IContainer $parent = null, $name = null) {
        parent::__construct($parent, $name);
        $this->setTranslator($translator);
    }
}

tak se ze staženého balíčku s traitama reálně využijí pouze tyto dvě (trait1 a trait8) a to až v momentě volání new MyForm(); ?

Pokud ano, tak je to supr.

K poslední otázce:

Máme například Google API na našeptávání adresy. Toto API umí do jednoho text inputu vložit naformátovanou adresu a ještě zapne našeptávač.
Toto API ale také umí udělat to, že ti jednotlivé části adresy vrátí jako JSON:

{address_parts: [
					postal_code: xxxxx,
					route: xxxxx,
					city: xxxxx
				]
}

Toto je pseudokód. Každopádně nějak takto response od google vypadá. Když si tato rozkouskovaná data chceš poslat na server, tak nejjednodužší je udělat další hidden input a tento plnit oním JSONem. Na straně serveru pak value hidden inputu dekodovat.

Otázka je, co když chci tuto funkcionalitu zabalit do ->addAddress($name, $label);

tedy udělat traitu, která přidává metodu ->addAddress() a při vykreslení pomocí makra ‚input‘ vykreslí místo jednoho pole to pole, které je vidět s našeptávačem a druhé hidden pole, které se bude plnit tím JSONem.

získání dat pomocí $values->$name vrátí asociativní pole, které obsahuje rozkouskovanou adresu podle JSONu a taky navíc celou adresu z inputu s našeptávačem.

Snad jsem to napsal dostatečně.

@Polki Ano, přesně takto to funguje. PHP zjistí, že třída „neexistuje“, zavolá autoload funkce, ta načte pomocí svého algoritmu požadovanou třídu (php soubor) a pak zjistí, že třída existuje a pokračuje dále, jinak končí s errorem.

Na to bych použil přepsání metod getControl(), loadHttpData(), getValue() ve třídě AdressControl. Tady máš příklad. Dal jsem tam navíc checkbox a v loadHttpData zpracovávám hodnotu checkboxu. getValue() upravíš podle sebe

Myslím, že se v tomto případu se načtou všechny traity. Ale takovéto optimalizace jsou k ničemu, zaměřil bych se na něco jiného a cachoval. Správná cache ti ušetří ms. Je velice dobré, že máš takovéto přemýšlení, ale nepřeháněl bych to.