Autor Zpráva
nethor
Profil
V procedurálním programování se mi osvědčily pomocné funkce pro rutinní převod hodnot podle zdroje a účelu.
např.
post2db() { /* příprava $_POST hodnot pro zápis do db  */  }
db2form() { /* výpis hodnoty z databáze do pole formuláře */  }
db2text() { /* výpis hodnoty z databáze do HTML */  }
...
.. a další pro nejběžnější operace, většinou jde o serii 2-3 běžný fcí php.
Některé sekvence závisí na nastavení serveru, takže je výhoda, když se dají změnit na jednom místě.

Při výrobě obdobného 'nářadí ' v OOP nějak nevím kam s nimi.
Tématicky spolu souvisí, vyskytovat se ale mohou ve všech třídách.
Napadá mě dát je všechny do zvláštní statické třídy, to ale zjevně neposkytuje žádnou výhodu, jen neříjemně prodlužuje zápis:
post2db() na MyFce::post2db() .

Z praktického hlediska bych je nechal tak, jak jsou, v samostatném souboru.
To ale asi není moc OOP.

Kam s nimi?
mimiru
Profil *
pokud jsou to skutečne samostatné univerzální pomocné funkce napříč celou aplikací (což dle mého uváděné příklady rozhodně nejsou) tak je můžeš klidně nechat i jako funkce v samostatném souboru. pokud používáš namespace tak pak bude výhodnější použít třídu se statickými metodami - zase o tolik delší ten zápis není
Alphard
Profil
Např. post2db() udělat jako součást databázové vrstvy, protože escapování závisí na konkrétní databázi a je potřeba jen při práci s databází. Ty další v závislosti na potřebě aplikace buď jako metody nějaké třídy String, nebo je dát to šablon, nejsou-li třeba jinde.
span
Profil *
Môžu byť tiež vo vlastnej triede typu "common", a každá ďalšia trieda ktorá bude použivať tieto funkcie, jednoducho tú triedu "common" rozšíri.
Napriklad:
class dbHandler extends common {}
Alebo je to somarina?
hugo
Profil *
zalezi od konkretnej situacie, ale ked taketo funkcie chces mat v classe, tak pouzi staticke metody.
Napriklad si vytvorit classy StringUtils, MathUtils, FileUtils atd..
a potom v nich budes mat napriklad:
StringUtils::urob_neco1();
StringUtils::urob_neco2();
MathUtils::urob_neco1();
Alphard
Profil
[#4][#5]
To jsou pořád rady... Pro obecné textové funkce ano, radějí podle [#5]. Ale escapovací funkce pro konkrétní databázi se přece nebude dávat jako předek všech tříd ani do obecné knihovny Strings.
span
Profil *
[#6] Alphard
Vo všeobecnosti zaleži aj na tom či konkretnu metodu bude použivať iba jeden potomok alebo viacero.
nethor
Profil
Mno, jak se teď OOP prokousávám,
připadá mi, že by se měly zapsat do interface.

To je mimochodem i slovo, které skupinu těchto fcí celkem přesně vystihuje.
Tori
Profil
nethor:
připadá mi, že by se měly zapsat do interface.
No ale týkají se přece různých oblastí - úprava vstupních dat pro uložení do DB vs. úprava dat (libovolného původu) před odesláním na výstup v kontextu HTML. Mně třeba spíš než rozhraní (které vnímám - možná chybně - víc jako "dohodnutý způsob komunikace" než "spojení dvou [odlišných] vrstev") připomněly návrhové vzory Adapter nebo Bridge.
Joker
Profil
nethor:
Stejně jako Alphard si myslím, že escapovací funkce patří do třídy spravující připojení k dané databázi.

U těch dalších mi není úplně zřejmé, co by měly dělat. Třeba „výpis hodnoty z databáze do pole formuláře“ má udělat co?
Jestli to je zase escapování, tak v první řadě na to už v PHP funkce existuje (htmlspecialchars).
Jestli to je opravdu metoda, která dostane nějakou identifikaci záznamu v databázové tabulce a vypadne z ní HTML kód, tak pokud to není zrovna aplikace na správu databáze, přijde mi podezřelé, proč by něco takového potřebovala.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0