Zjednodušení životního cyklu?

No keby sa na action, prepare, render používala jedna metóda by nebolo zlé. Niektoré veci niekedy neviem kam mám vopchať :D . Polial nemám nejaký control tak všetko aj tak pchám do render.
Fakt je to asi trochu matúce.

David Grudl napsal(a):

Jedním z dosud nerealizovaných nápadů je továrnička na komponenty v presenteru (nebo komponentě). Komponenta se tvoří, až když je potřeba a odpadají výjimky kvůli inicializaci komponenty užívající signály až v části render (typicky AppForm). V podstatě je to řešitelné uživatelsky i nyní přepsáním metody __get(), případně getComponent(), tedy nebýt final. Tento koncept by mohl eliminovat metody „prepare“.

to vyzerá veľmi zaujímavo…

ja som sa v používaní action*` & prepare* metód riadil pravidlom – čo treba spracovať pred presmerovaním → present*, čo stačí po ňom → prepare*, ale zväčša ostali aj tak metódy prepare* prázdne, alebo poloprázdne :)

Se „signálovou“ metodou se dá manipulovat poměrně dobře, ale stále nejsem spokojený s jejím názvem ve tvaru handleXyz() ;)

kedysi bolo viacero nápadov, mne akurát napadá processXYZ(), čo samozrejme koliduje minimálne s processSignal(), ale napr. processClick() mi príde vcelku príjemný názov. Ponúkajúci sa signalXYZ() sa mi síce nezdá vhodný, ale možno niekto iný príde s argumentom prečo by mohol byť…

p.s. použil někdo někdy shutdown()?

zatiaľ nie, ale čo ak náhodou? ;)

Osobně mi současný stav taky vyhovuje. Jinak co „getClick“? Get je anglicky i obstarat, obdržet, takže by to více-méně odpovídalo, ne?

pmg napsal(a):

Toto sem už moc nepatří, ale poslechněte si to. Co se zmíněné metody týče, byl bych spíš pro to, aby Nette\Object při volání $class->getClick() vracel $class->click, a hlavně potom aby při volání $class->setClick($value) nastavil $class->click = $value a pak vrátil samotnou třídu, aby to šlo řetězit.

To není špatný nápad. Znamenalo by to ale udělat z fluent setter standard, tj. všechny settery by musely vracet $this.

Dal by se pak používat setter na hodnoty, které ho zatím nepotřebují (a jsou public). Když by pak setter potřeba byl, nemusel by se předělávat kód.

Logika je spíš taková, že pokud používáš $class->click, kde click je public proměnná, tak nemusíš předělávat kód, když se z toho stane getter. Public proměnné jsou vlastně jen zjednodušením pro triviální setter/getter, který jen vrací a nastavuje proměnnou.

David Grudl napsal(a):

To není špatný nápad. Znamenalo by to ale udělat z fluent setter standard, tj. všechny settery by musely vracet $this.

Spis by bylo vhodne vratit to, co vrati patricny setter, je pak uz na kazdem, zda-li si vraci $this, popr. nasetovanou hodnotu, coz take muze byt potreba.

Co se tyce nazvu metod na zpracovani signalu, handleXYZ mi prijde zatim opravdu nejlepsi pojmenovani ze vsech variant, ktere byly navrzeny (naopak navrhovane nazvy jsou mnohonasobne horsi). Navic, „handle“ ten vyznam opravdu vystihuje, nemenil bych.

David Grudl napsal(a):
Logika je spíš taková, že pokud používáš $class->click, kde click je public proměnná, tak nemusíš předělávat kód, když se z toho stane getter. Public proměnné jsou vlastně jen zjednodušením pro triviální setter/getter, který jen vrací a nastavuje proměnnou.

Jasně, občas bývám náměsíčnej. Funguje to tak už i teď, tak asi nemá cenu to komplikovat. Leda že by výhoda atomatického fluent interface převážila nejednotnost syntaxe.

A. napsal(a):
Spis by bylo vhodne vratit to, co vrati patricny setter, je pak uz na kazdem, zda-li si vraci $this, popr. nasetovanou hodnotu, coz take muze byt potreba.

Nette\Object se dostane ke slovu až tehdy, když je zavolán neexistující setter (setValue). Potom se může podívat, jestli ve třídě není nějaká proměnná ($value) s přístupem public a případně ji nastavit na předanou hodnotu. Když do třídy ten setter doplníš, už si můžeš vrátit, co chceš.

Edit: Ještě jedna věc. Automatický setter by mohl kontrolovat typ uvedený v anotaci @param.

Editoval pmg (19. 11. 2008 17:24)

A videli ste už settery vracať hodnoty v iných programovacích jazykoch? Nevravím zas, žeby to bolo zlé =)

Chcel som povedať iných objektových programovacích jazykoch, keďže ten setter je objektová fičurda a php sa snaží byť objektové, sem tam :D :D

Persistentni komponenty jsem zatim nepouzil, ale pokud to chapu dobre tak ted je to takto:

class MujPresenter extends Presenter {
	/** @persistent */
	public $komponenta;

	public function prepareDefault() {
                $this->komponenta = new FifteenControl($this, 'game');
		// atd...
        }
}

Osobne bych se drzel anotaci vzdy u prvku, ktereho se to tyka! Obecne u persistence by mozna stalo za to rozsirit aby se z anotace bral typ. Pokud chci aby vychozi hodnota byla NULL a polovene hodnoty pouze INT tak to neudelam:( Predstava by byla: /** @persistent int */ Tim by take slo udelat napriklad i /** @persistent FifteenControl */ a problem by se mel odstranit ne?

A nebo jsem to nepochopil:)

Editoval phx (20. 11. 2008 10:43)

Takze nejde o persistenti atribut presenteru, ale o nazev komponenty. Nejak mi unika proc by komponenta mela byt persistentni, kdyz neni v persistentni promenne? Asi jsem to nepochopil, nebo nevidim onen problem.

David Grudl napsal(a):

Zároveň by možná nebylo od věci přidat do Nette obecnější mechanismus na parsování anotací v komentářích.

Už jsem ti ukazoval dar přítele johna? http://code.google.com/p/addendum/

Dokončil jsem poměrně dost náročné přepracování klíčových funkcí Presenteru, což by mělo v důsledku vést ke zjednodušení (respektive k rozšíření o nové možnosti a vyřešení nedostatků) životního cyklu.

Úpravy by neměly způsobit žádné problémy, jsou zpětně kompatibilní, kromě zmíněného značení persistentních komponent. To prosím předělejte dle návrhu. Komponenty označené starým způsobem vyvolají výjimku InvalidStateException: Persistent parameter must be scalar or array, ‚DefaultPresenter::$xyz‘ is object.

Než se úprava dostane do distribuce, je potřeba ji důkladně otestovat. Stáhněte si proto prosím tuto extra distribuci a vyzkoušejte, jestli vše funguje v pořádku.

Zároveň jsem trošku upravil příklad akrabat.forms, kde je vidět v činnosti továrnička na komponenty. Díky tomu je celá aplikace postavená pouze na metodách render*.

David Grudl napsal(a):

To prosím předělejte dle návrhu.

Neuklepnul jsi se v odkazu?

EDIT: Ha BUG, na 2. strane nefunguji kotvy:(

Editoval phx (21. 11. 2008 8:25)

romansklenar napsal(a):

Takže zběžně co jsem se na to díval jsem to pochopil asi takto: (kdyžtak mě opravte)

• s komponentami se manipuluje a uchovávají se nyní v ComponentContainer a až když je zavoláno getComponent('komponenta') tak se komponenta vytvoří továrničkou tedy až když je doopravdy třeba

Ano, o továrničku je rozšířena třída ComponentContainer. Jinak tady se nic víc nemění. Díky tomu i jednotlivé komponenty (např. PresenterComponent) mohou používat továrničky.

• před vykreslovací fází už se neukládájí presenterem vnitřní stavy komponent (metoda saveState byla z presenteru odstraněna) a je to v plné režiji PresenterComponent (který ji jako rodič implementuje)

Ano, ukládají se po vykreslovací fázi. Ono ukládání je spíš záležitost výkonnostní optimalizace, nemělo by to mít na nic vliv.

• jaký je rozdíl mezi vytvořením komponenty továrničkou v action{Action} a render{View} a co je na jaké případy vhodnější?

Výhoda továrničky je v tom, že signal handler si může komponentu (nebo subkomponentu) „vytáhnout“ bez toho, že by se musela dopředu inicializovat v action nebo prepare.

Zatím to vypadá, že metody životního cyklu presenteru jsou zachovány, plánuje se ještě eliminovat metody prepare jak je zmíněno v úvodním postu?

Jasně, zpětná kompatibilita je zachována, jen se snažím hledat nové cesty.

Chyby opraveny.

Tak jsem to pustil do ostré distibuce a budu se modlit ;)

David Grudl napsal(a):
Jojo, dar přítele Johna vypadá velmi dobře. Pokusil jsem se do Nette přidat vlastní implementaci – Nette\Annotations

Smrk!