Použití jedné metody na více místech

před 2 měsíci
grovik
Člen | 69
+
0
-

Mám v aplikaci posílání vzkazů, potažmo notifikací.
Mám to pro běžného uživatele, ale i pro administrátory a hlavního admina.
Jde o to, že je to na všech místech to stejné, ale jen to jinak vypadá. Rád bych to sjednotil, aby v každém presenteru nemuselo být všechno třikrát.

Mám dvě myšlenky:

  1. Udělat metodu, která bude tohle sjednocovat, ale přiznám se, že si nejsem jistý jak to bude řešit handly.
  2. Udělat třídu pro tuhle komunikaci a tu pak použít a v ní mít všechny ty metody.

Přemýšlím nad tím a přiznám se, že nevím jak a z které strany na to jít. Potřeboval bych nakopnout.
Nějaké nápady? :-) předem díky.

před 2 měsíci
m.brecher
Generous Backer | 863
+
+1
-

@grovik

Rád bych to sjednotil, aby v každém presenteru nemuselo být všechno třikrát.

Řešil bych to komponentou – třídou, jít cestou univerzální metody bych nedoporučoval. Poradil bych, ale potřebuji nějaké detaily zadání, tohle např. je příliš obecné:

Jde o to, že je to na všech místech to stejné, ale jen to jinak vypadá.

Namátkou mě napadá třeba: kam se notifikace zapisují, jak by se měly zobrazovat, jaký by měl být jejich životní cyklus – vytvořit, označit jako přečteno, do koše, smazat, atd…

před 2 měsíci
mystik
Člen | 308
+
+7
-

Composition over inheritance. Takze za me urcite tridu.

Navic je vudy lepsi drzet logiku co se vylozene netyka presenteru samotneho mimo presenter. Lip se to testuje, rozsiruje, pridavaji zavilosti,…

před 2 měsíci
Kamil Valenta
Člen | 815
+
+3
-

Nehledal bych v tom vědu a udělej to jako zbytek aplikace. „Notifikace“ je běžná modelová třída, která bude mít metody na vytvoření, získání, měnění stavu. Do presenterů injectuješ jako servicu. Komponentou pak můžeš řešit zobrazení, odklikávání apod. Ta komponenta se přihlásí k závislosti stejně jako presenter.

před 2 měsíci
grovik
Člen | 69
+
0
-

Díky všem za nápady a rady.
Zkusil jsem to jako servisu a zdá se to použitelné. I když následně mě pár věcí vypeklo :D. Takže jsem manipulaci se vzkazem přesunul do služby. Což se zdá jako použitelné a funkční.
Teď ladím jak z toho vytáhnout formulář pro odeslání a ideálně to celé zajaxovat.
Ted nápad s komponentou se mi zdá dobrý, ale zatím jsem ještě nikdy neřešil komponentu, krom datagridu a formuláře. Ideální by bylo mít komponentu co by vytvořila HTML bez tříd a třidy tam nasázet až podle místa použití. Hlavně kvůli formuláři. Protože po poslání vzkazu je potřeba formulář (designově největěí peklo) :D.

Ještě mě napadá, řešil někdo někdy takové to, ukazování kolik zpráv je nepřečtených. Tak nějak aby se to samo aktualizovalo? Napadlo mě udělat to přes javascript a v intervalech si sáhnou po počtu zpráv.

před 2 měsíci
m.brecher
Generous Backer | 863
+
+1
-

@grovik

Ideální by bylo mít komponentu co by vytvořila HTML bez tříd a třidy tam nasázet až podle místa použití.

to je dobrý nápad, je vhodné zapouzdřit konkrétní css třídy v šabloně a do šablony předávat logický typ/stav, ze kterého se css třídy odvodí.

komponenta:

class NotifyControl extends UI\Control
{
	public function __construct(private NotifyModel $notifyModel)
    {}

    // ....

    public function render(string $style): void  // argument se předá v šabloně akce
    {
        $this->template->style = $style;
        // ...
    }
}

Šablona komponenty:

{var
    $class = match($style){
        'Style1' => 'class-one',
        'Style2' => 'class-two',
        // ...
	},
}
<div class="{$class}">
   //.....
</div>

Vykreslení komponenty v šabloně akce

{control 'notifyControl' style: 'Style1'}  {* zadáš konkrétní styl pro dané místo ;) *}
před 2 měsíci
Kamil Valenta
Člen | 815
+
+1
-

m.brecher napsal(a):

{control 'notifyControl' style: 'Style1'}  {* zadáš konkrétní styl pro dané místo ;) *}

Tohle se mu v ajaxu rozpadne. Když už jít touto cestou, tak si styl předat v createComponent(). Další úskalí je, že vývojář musí nosit v hlavě množinu korektních aliasů pro styly. Co když se splete? Co když použije nedefinovaný? Bude to stále dohledávat v kódu. Ale to by šlo pokrýt našeptávanou konstantou.

Asi bych v takovém případě zvážil, zda nemít abstraktní komponentu pro vykreslování notifikací (bez css class) a z ní podědit konkrétní komponenty s classami. Použití by pak bylo intuitivnější:

{control notifikaceVMenuBar}
{control notifikaceVDashboardu}
před 2 měsíci
m.brecher
Generous Backer | 863
+
+1
-

@KamilValenta

Tohle se mu v ajaxu rozpadne.

Ano, to je správná poznámka, lepší je $style nastavovat setterem, nebo v konstruktoru komponenty.

vývojář musí nosit v hlavě množinu korektních aliasů pro styly

Property $style není alias pro css třídu, ale je to parametr business logiky. Ideální je použít místo stringu typový enum, kde nemůže dojít k překlepu a oddělí se konkrétní grafické ztvárnění od logiky. Vývojář se nemusí v kódu modelu/presenteru/komponenty zabývat tím, jak se css třídy budou jmenovat.