wavevision/dependent-selectbox – moderní dependent selectbox

teekey99
Člen | 45
+
+3
-

Ahoj všichni,

s kolegou Kubou Fillou, jsme začali na našem Githubu zveřejňovat některé užitečné package, které jsme nashromáždili na našich projektech. U některých je stav stále Work In Progress, protože je postupně extrahujeme do samostantných knihoven a ladíme.

Jeden z těch, které už jsou plně ready, je právě náš wavevision/dependent-selectbox.

Jedná se o moderní, strict typed rozšíření pro Nette 3 s Naja powered front-endem. Potřebné info najdete přímo na githubu. Pokud narazíte na nějaké problémy nebo nejasnosti, rád pomůžu.

Budeme určitě rádi, pokud toto (i další) rozšíření najdou své využití a pomůžou vám s vašimi projekty. Stejně tak budeme rádi za zpětnou vazbu, vylepšení atd.

Marek Bartoš
Nette Blogger | 1171
+
0
-

To rozširování formuláře traitami/děděním není moc ideální, neměli byste mít potřebu přetěžovat getControls()

teekey99
Člen | 45
+
0
-

@Mabar Díky za feedback!

Rozšíření formuláře pomocí trait se nám naopak velmi osvědčilo. Lehce se jednotlivá rozšíření komponují, dobře se to testuje a není nutný vytvářet prázdný třídy s anotací kvůli „oblbnutí“ linteru a IDE.

Každopádně souhlasím s tím přetížením getControls, to je tam opravdu úplně zbytečně. Zatím chystám tuto úpravu.

CZechBoY
Člen | 3608
+
+2
-

No traita by se neměla použít na formulář, ale na Container (který potom ten formulář dědí). Tohle řešení používám taky a je lepší než magický Container::extensionMethod(xxx).

Marek Bartoš
Nette Blogger | 1171
+
+2
-

Tak nejsnadněji rozšiřitelné je používat array access $form['foo] = new DependentSelectBox('foo', []), rozšiřování děděním není moc použitelné pro systémy složené z více balíčků, kde některé mohou chtít nějaký ten formulářový input navíc.

Jinak rozumím, proč jsi zvolil tenhle přístup, šlo mi jen o to, že najití DependentSelectBox ve formuláři šlo udělat i bez dědičnosti, každá komponenta může udělat $this->getForm()->getControls()

teekey99
Člen | 45
+
0
-

@CZechBoY

U toho Container, jak to přesně řešíš ty? Já jsem se na tom zasekl. UI\Form totiž dědí Forms\Form a až ten dědí Forms\Container, takže když chceš, aby tvůj vlastní BaseForm dědil tvůj kontejner, tak mi to přijde prakticky nemožný.

Jak to strukturovat, aby tvůj BaseForm dědil UI\Form, Forms\Form a zároveň tvůj vlastní Container? Přece nejde udělat vlastní Forms\Form, aniž bych dědil ten z nette, tím pádem mu nemůžu dát podědit svůj Container, nebo se pletu?

Tohle jsem nevyřešil a dělám to právě způsobem, kterýho bych se rád zbavil, a sice traita, která jak ve formuláři tak v containeru přetíží addContainer. Kromě toho nette Container v addContainer používá new self, aby to fungovalo, když ho podědíš, musel by přeci použít new static, takhle ti vždycky vytvoří původní nette container.

Budu rád, když mi poskytneš jakýkoliv info, který mě kdyžtak vyvede z omylu. Díky moc!

teekey99
Člen | 45
+
0
-

Mabar napsal(a):
Jinak rozumím, proč jsi zvolil tenhle přístup, šlo mi jen o to, že najití DependentSelectBox ve formuláři šlo udělat i bez dědičnosti, každá komponenta může udělat $this->getForm()->getControls()

Ano, za tohle díky, že jsi na to upozornil. Už jsem upravil v development branchi.

Gappa
Nette Blogger | 199
+
0
-

Mabar napsal(a):

Tak nejsnadněji rozšiřitelné je používat array access $form['foo] = new DependentSelectBox('foo', []), rozšiřování děděním není moc použitelné pro systémy složené z více balíčků, kde některé mohou chtít nějaký ten formulářový input navíc.

Pravda :)

Jak to ale řešit v situacích, kdy formulářový prvek má závislosti? Např. prvek pro upload obrázku, který automaticky dělá náhled již nahraného obrázku a tedy potřebuje resizer.

Tam IMHO asi nezbývá než použít Container::extensionMethod.

Marek Bartoš
Nette Blogger | 1171
+
+3
-

Předáš mu závislost jako kterékoli jiné třídě? Můžeš si na ten prvek i vytvořit továrnu

Gappa
Nette Blogger | 199
+
0
-

Mabar napsal(a):

Předáš mu závislost jako kterékoli jiné třídě? Můžeš si na ten prvek i vytvořit továrnu

Jasně, já myslel automaticky. Na což jsem dostal odpověď v druhé větě, díky :)

Nějak mě tohle řešení v případě formulářů bůhvíproč vůbec nenapadlo.

Marek Bartoš
Nette Blogger | 1171
+
+2
-

Nějak mě tohle řešení v případě formulářů bůhvíproč vůbec nenapadlo.

Celkem klasický problém – přečtu si dokumentaci a místo zamyšlení se nad fungováním hledám magii a dělám přesně podle dokumentace.

teekey99
Člen | 45
+
0
-

@CZechBoY No jasný, to je ale přesně ten způsob, který používám já. Tzn. použiješ trait v custom containeru i formu, ale form už ti ten custom container nedědí.

Většinou to funguje v pohodě, problém ale nastává, když si např. vytvoříš nějakej form helper, kterej má jako argument přijmout abstraktní Container. Ten na sobě totiž reálně tu novou metodu nemá, ale potřebuješ ho použít, aby ti implementovanej helper fungoval jak na formuláři, tak na containeru. Tzn. že musíš type hint Container pro ten vstupní argument přetížit anotací, která řekne, že to může být CustomForm|CustomContainer, což není úplně ideální.