[Best Practice] Jmenné konvence pro onSuccess metody
- Patrik Votoček
- Člen | 2221
Dnes jsme s Pandou na Nette Jabberu řešili best practice pojmenovávání metod formulářů (kvůli QuickStartu). A dobrali jsme se toho že se výsledku asi nedobereme.
Davidova {componentName}Submitted($form) (v examplech)
class MyPresenter extends Presenter
{
protected function createComponentMyForm()
{
$form = new Form;
// ...
$form->onSuccess[] = callback($this, 'myFormSubmitted');
}
public function myFormSubmitted($form)
{
// ...
}
}Pominu-li, že by místo sufixu „Submitted“ melo být podle nových konvencí spíše „Success“, tak se mě moc nelíbí že se jenou používá prefix (action, render, handle, createComponent) a podruhé sufix (Submitted).
Vrtákova process{ComponentName}($form)
class MyPresenter extends Presenter
{
protected function createComponentMyForm()
{
$form = new Form;
// ...
$form->onSuccess[] = callback($this, 'processMyForm');
}
public function processMyForm($form)
{
// ...
}
}
// vs.
class MyForm extends Form
{
public function __construct() // ve skutečnosti díky mému "BaseForm" používám metodu setup
{
// ...
$this->onSuccess[] = callback($this, 'process');
}
public function process()
{
// ...
}
}Co se týká pojmenování onClick etc tak tam to neřeším protože si vždy vystačím s closurou.
Jakou konvenci používáte vy? A co si o tomto problému myslíte?
- JakubJarabica
- Gold Partner | 184
{componentName}Submit
alebo
{componentName}Add + {componentName}Edit
Podľa toho, či mám formulár na 2 akcie alebo na jednu :)
- newPOPE
- Člen | 648
Zalezi od situacie…
Nakolko pouzivam a pozeram na formulare ako na
component for user interaction tak sa mi tam nepaci, ze form si sam
spracovava data. Pozeram na nich tak, ze mi data od usera dodaju, zvaliduju a to
aj staci :)
Cize spracovanie dat nechavam na druhych.
Editoval newPOPE (17. 12. 2011 11:28)
- Patrik Votoček
- Člen | 2221
@HosipLan: vím že formuláře používáš jako samostatné komponenty. Ale co by jsi teda používal v presenteru?
success{ComponentName}{componentName}Success
nebo ještě něco jiného?
success{ComponentName} mě totiž zní divně a
{componentName}Success je zase prefix vs. sufix.
- Filip Procházka
- Moderator | 4668
V presenterech to píšu vyloženě nahodile (střídám suffix a prefix),
nejčastěji však <komponenta>Submitted nebo
<komponenta><tlacitko>Clicked, nebo zahrnu do eventu
ještě shrnutí toho, co dělá (ty názvy jsou pak docela dlouhé :), ale
chtělo by to konvenci no :)
Nejspíše success<komponenta> (možná
successed? :D) a
success<komponenta><tlacitko>Clicked. Chtělo by to
pár si jich napsat a podívat, se které vypadá lépe.
Zrovna ale řeším CMS a blbě se mi „přepíná téma přemýšlení“, takže tohle není zrovna objektivní :)
Editoval HosipLan (17. 12. 2011 12:09)
- Pavel Kouřil
- Člen | 128
Já osobně používám suffix Submitted … ale taky se mi střídání prefixu a suffixu moc nelíbí :/
Nicméně v QS bych se držel konvence z dokumentace. :)
- ptacek.pavel
- Člen | 27
Každý formulář něco dělá a je k něčemu určen. Tzn. moje „konvence“ je, že se onSuccess metoda jmenuje podle toho, co ten daný formář dělá.
Např. importForm → executeImport . Jinak
submitted suffix, ale proccess nebo execute mi přijde ideální.
- Jan Tvrdík
- Nette guru | 2595
Do QS mi přijde vhodnější varianta process{ComponentName}.
Docela zajímavá je i výrazně obecnější varianta
{name}_on{event}, takže v případě formulářů je to např.
myForm_onSuccess, myForm_onSubmit,
myForm_onInvalidSubmit…
- Patrik Votoček
- Člen | 2221
me jsou ty podtrzitka proti srsti. a nejak me do nette proste nesedi.
btw opet je to prefix vs. sufix.
- awsickness
- Člen | 98
osobne mam radsi submitted.
priklad
registerSubmitted
registerCanceled
oproti
processRegister
kde bych asi delal podminku if cancel …
- awsickness
- Člen | 98
osobne mam rad toto
[registerForm==nazevKomponenty][Action]
je to hodne psani pro nekoho ale na prvni pohled poznam
nazev = register
co = Form
akce = action
a doufam ze kdyz nekdo po me bude cist kod tak hned pochopi co se tam deje a
s cim.
- Filip Procházka
- Moderator | 4668
Já si UI\Form upravil takto, vypadá to jako signály, což nemusí být ideální,
ale kdyby to byl problém, tak @Majkl578 navrhoval, dát
tam masku static $eventMask = "handle%s", aby šla nastavit
konvence :)
Zpracování formulářů v presenterech už v CMS nepoužívám :)
- Michal Vyšinský
- Člen | 608
To je podle mě nešťastné řešení. Pak bych mohl klidně signál zavolat v url. Já si vždy metodu nazvu podle toho, co dělá. Takže pro přihlašovací form mám callback LogMeIn atd.
- Filip Procházka
- Moderator | 4668
@**CherryBoss**: Z formuláře ty „signály“ nezavoláš, dokud
nepřepíšeš metodu isSignalReceived a v presenteru to taky
nezavoláš, protože tam budeš mít v argument
handle<name>(Form $form), takže to umře
Máš nápad na lepší slovo, aby to nevypadalo „blbě“? Zkus si je napsat a přečti si je párkrát.
- Michal Vyšinský
- Člen | 608
Já myslel, že handle{Signál} lze zavolat přes url (?do=signal). Myslel jsem tedy, že obiwanovo řešení není bezpečné. Jinak mě napadá už akorát {FormName}sent :) Ale většinou použiju to co mě napadne.
- one-two
- Člen | 80
Osobně dělám samostatné třídy jako Vrták (nechci to mít nabušeno
všechno v presenteru, není v tom pak pořádek), ale píšu Davidovo suffix.
Tak mě napadá, jestli nebude ideální psát vklidu
public function onSuccess na onSuccess atd., jelikož je to
samostatná třída tak by to nemělo vadit…
EDIT: to byla moje idea, čekal jsem právě na to, až to někdo posvětí
nebo zatratí :) tudíž
špatný nápad, nedělat
Editoval one-two (27. 12. 2011 12:18)
- Filip Procházka
- Moderator | 4668
Prosil bych všechny, co si přečtou příspěvek od @**one-two**, aby nezkoušeli opakovat tento nápad. Garantuji vám, že přijde den, kdy se budete hodiny a hodiny potit u toho, proč vám nefungují události formuláře. Události jsou totiž velice magické, nejenom ve formulářích.