v čem je to lepší než
Já neříkám, že je to lepší. Já říkám, že to není horší. Měl to být příklad, který ukazuje, jak lze díky mixinům v Pythonu psát lépe než v Javě, která je nemá a podle mě neukazuje nic.
Cest je vždy více. Mně osobně se víc líbí, když ten timer je přímo součástí komponenty, ...
To mě právě přijde jako hrozná prasárna (no offense), takhle cpát funkcionalitu přímo do třídy. Mnohem lepší mi přijde mít timer jako samostatný objekt s vlastní úlohou/odpovědností (návrhový princip "single responsibility"). A způsob jak to dělá Wicket přes behaviory mi přijde přesně to pravé ořechové.
Rozhodně se s ním musí dobře umět. I pak je třeba hledání chyby dost pracné, protože ve stack trace nic není a jeho debug hlášky nejsou zrovna plné informací. A že se v něm udělá chyba velice snadno, stačí se třeba klasicky příliš brzy odkázat na model object.
Zajímavé. Dělám na poměrně velkém Wicket projektu, kde v něm dělá 5-7 lidí (někteří ne fulltime) a nikdo z nás podobné problémy nemá. Před několika měsíci k nám nastoupila dívčina co Wicket nikdy neviděla, dostala ode mne krátký (1-2 hodiny) "crash course" a vplula do něj úplně v pohodě. Nevím, že by měla nějaké závažnější problémy. Jediné co mě napadá:
- Pokud uděláte naráz velkou stránku s hodně komponentami a nesedí vám struktura HTML versus Java komponenty, tak se (za určitých okolností) opravdu hůř dohledává, kde je v těch strukturách chyba. Řešení je to testovat už po menších kouscích.
- Když přidáte do AjaxRequestTargetu komponentu, která nemá odpovídající HTML tag, tak ji to nerefreshne (tady je zjevné proč to v principu nejde, moc se mi to neděje a když se to stande, tak najít problém bývá jednoduché)
- Když schováte pomocí <wicket:enclosure /> komponentu, na kterou je nabindovaný AJAX, tak Wicket ten AJAX stejně vygeneruje a pak jsou v debugu hlášky, že nenašel komponentu na kterou se nabindovat. To je opravdu lehce zrada, i když aplikace funguje i tak.
Ale na žádný problém typu "brzy odkázat na model object" se nepamatuji. Můžete dát nějaký příklad?