Formulářové doplňky: registrace nových typů polí

stekycz

Přemýšlím, proč je aktuální „best practice“ pro formulářové doplňky takové … no prostě divné. Proč mám pole/doplněk registrovat v bootstrap.php? Je v tom nějaká speciální výhoda?

Příklady kde jsem na to narazil:

http://nette.merxes.cz/date-picker/ (bod 7 u instalace)
https://componette.org/search/?… (instalace)

V zásadě se jedná o kopírování jednoho až čtyř řádků kódu, které obstarají dynamické přidání metody na formulářový container. Je to jednoduché a funguje to bez problémů. Co mi na tom vadí?

Editor/IDE mi nenapovídá všechny takto přidané typy formulářových polí/controls.
Při každém requestu se musí načíst všechny registrované třídy a zaregistrovat se ke containeru.

V podstatě nejde o funkční problémy, ale třeba zrovna absence napovídání v IDE mi přijde celkem nepříjemná.

Tušíte někdo, zda to lze řešit i jinak? Přidání dané metody staticky do vlastního základního formuláře by sice pomohlo, ale rozhodně ne spolehlivě. Na formulářových podkomponentách by ta metoda už nefungovala. Možná by šlo přepsat si z velké části container i Form, ale to by se vyplatilo jen tehdy, pokud bych si to hodil do svojí vlastní knihovny nebo šablony projektu.

Předem díky za nějaké tipy

Vojtěch Dobeš

Zaslechl jsem něco o tom, že PHPStorm uvolnil API pro psaní nějakých rozšíření, tak by se mohlo napsat rozšíření, které by chápalo extension methody z Nette\Object :). Ne, nedokážu si představit, jak jinak by se mělo docílit napovídání v IDE, tvůj návrh s BaseForm je podle mě validní a nejlepší řešení.

Podle mě jinak nejde o best-practice, někdo to řeší třeba pomocí CompilerExtension (která de facto zapouzdřuje to volání z bootstrap.php.

pawouk

Jednoduchá odpověd: Ta „best practise“ je blbě. Rozšiřování v bootstrapu je samozřejmě špatně hlavně z důvodu které jsi zmínil. Já osobně to řeším tak, že si vytvořím např BaseForm, resp. BaseContainer a na konec tohoto souboru doplním rozšíření. Takže rošíření se natáhne až když se načte soubor BaseForm.php a ne při každém staru aplikace. Tím je vyřešen první problém. Druhý snadno vyřešit nejde, neznám ide které by to umělo, takže je nutné to naspat zase do BaseForm do anotací, pak to napovídá vpohodě.

stekycz

@vojtech.dobes: Ano, PhpStorm něco takového nově podporuje, ale výsledku by musel předcházet poměrně náročný (pro mě) vývoj a zasáhlo by to jen uživatele Stormu. Což, jak píše, nás obrací spíše k ohnutí formulářů.

@pawouk: BaseForm sice funguje, ale jen do doby, než si začnu vytvářet subkomponenty formuláře. Proto musím danou metodu přidat rovnou na container. Je to sice relativně okrajový případ, ale pokud to chci řešit univerzálně, musím se tím zabývat.

Ještě mě tak napadá, zda by nešlo nějak upravit formuláře přímo v Nette, abych nemusel upravovat 2 třídy, ale aby mi na to stačila třída jedna. Oddělit třeba logiku pro zpracování (a validaci) a pro definici formulářů. Jedná se jen o aktuální hnutí mysli, takže mě případně nereálných úvah zadržte :-)

enumag

@stekycz: Abych ty metody pro form i containter měl na jednom místě, používám trait z PHP 5.4.

stekycz

@enumag Traity použít sice lze, ale v PHP 5.3 musím kód stejně duplikovat. Navíc si nejsem jist, zda traty jsou opravdu tím správným řešením tohoto „problému“.

Je sice pravda, že třída Form je v jistém slova smyslu speciální FormContainer, ale i ten mi přijde, že řeší více věcí současně (přidávání nových polí a validace jejich hodnot). Form pak přidává překlady a další logiku. Nemělo by to být řešeno spíše jako dekorace? Pak by přidávání vlastních polí mohlo být jen ve FormContainer plus bych přidal nějaký interface kvůli dekorátoru.

Čekám nějakou kritiku :-)