Filtrowanie danych - zapis do bazy, wyświetlanie na stronie, tytuły stron itp. Opcje

[adbacz]

Próbowałem już różnych filtrowań, w różnych momentach działania aplikacji lecz żaden nie spełniał moich oczekiwań - zawsze było coś co nie działało tak jak powinno.

Kiedy i jak bardzo filtrować dane pochodzące od użytkownika?
Nie mówie tutaj o Froncie - bo tutaj filtruje zawsze wszystko i nie ma zmiłuj.

1. Od razu podczas pobierania danych z POST?
- ok, zapisuję takie dane w DB i przefiltrowane dane mają encje HTML, które później sa w wielu miejscach wyświetlane, ale równeż w tytule paska przeglądarki, co czasami sprawia, że zamiast apostrofu mam encję widczną i muszę to naprawiać funkcją htmlspecialchars_decode.
2. Zapisywać dane czysto pobrane od usera ale filtrować dopiero podczas wyświetlania?
- zapisuję do bazy za pomocą nakładki na PDO więc wykonuje escape wartości, ale trzeba byłoby pamiętać, że wyświetlana wartość, na przykład tytuł strony musi być przefiltrowana na stronie, by usunąć znaczniki HTML (by ktoś nie stwierdził, że ładnie będzie tytuł pochylić).
3. Filtrować tylko i wyłącznie kod HTML a całą resztę zostawić i filtrować podczas wyświetlania. Ale to jest wyjście podobne do punktu drugiego.

Jak wy to rozwiązujecie w swoich aplikacjach?

[nospor]

To straszne.... sorki, jesli na danym etapie zakladam, ze nie ma tu byc takich danych to koniec kropka i ma ich nie byc. Nie widze sensu na pozwalanie ich wkladania tylko dlatego ze byc moze za 100 lat mi sie zachce, ze jednak bede teraz pozwalał. Ok, jak za te 100 lat zmienie zdanie i faktycznie bede pozwalał na dane, na ktore teraz nie pozwalam to w czym problem? Od tego nowego momentu te nowe dane będą sie pojawiac.

Wg Twojego toku myślenia, po grzyba w ogole zakładać walidatory na dane? Przeciez za jakis czas zachce mi sie zmienic na co pozwalam i bedzie lipa... totalny bezsens...

Twoja argumentacja do mnie nie przemawia. Do Ciebie nie przemawia moja. Ok. Oboje mamy do tego prawo, nie ma juz dalszego sensu siebie nawzajem przekonywac. adbacz poznał obie opinie, wybierze te, którą mu bardziej bedzie pasowala.

[pyro]

To straszne.... sorki, jesli na danym etapie zakladam, ze nie ma tu byc takich danych to koniec kropka i ma ich nie byc. Nie widze sensu na pozwalanie ich wkladania tylko dlatego ze byc moze za 100 lat mi sie zachce, ze jednak bede teraz pozwalał. Ok, jak za te 100 lat zmienie zdanie i faktycznie bede pozwalał na dane, na ktore teraz nie pozwalam to w czym problem? Od tego nowego momentu te nowe dane będą sie pojawiac.

Twoja argumentacja do mnie nie przemawia. Do Ciebie nie przemawia moja. Ok. Oboje mamy do tego prawo, nie ma juz dalszego sensu siebie nawzajem przekonywac. adbacz poznał obie opinie, wybierze te, którą mu bardziej bedzie pasowala.

Pragnę dodać tylko 3 ostatnie rzeczy:

1.) Napisałeś sobie "100 lat", żeby umyślnie i złośliwie (?) wyolbrzymić. Jeżeli robisz stronki tylko dla siebie, to taki argument jeszcze by miał jakiś sens, natomiast przy pracy np. z klientem (albo zwyczajnie z inną osobą) nie ma tutaj żadnego zastosowania do rzeczywistości. Nie przewidzisz, co dana osoba sobie wymyśli nie za "100 lat", tylko za tydzień, dwa tygodnie, miesiąc, ..., ... Po prostu nie ma takiej możliwości.

2.) Już wiele widziałem projektów / osób, które myślały podobnie jak Ty, ale koniec końców w końcu każdy przyznawał rację, że dane powinny być traktowane w sposób abstrakcyjny. Jednym z przykładów, który ostatnio mi się nasunął na myśl jest Yii i jego niesławne defaultScope, którego po zastosowaniu w praktyce nie sposób było zmienić. Twórcy wielokrotnie na listach dyskusyjnych upierali się, że zastosowanie defaultScope "wynika z designu aplikacji" i jeżeli mamy podejrzenie, że jakaś dana może się kiedykolwiek zmienić, to po prostu nie powinno się go stosować. I tak upierali się do momentu, aż użytkownicy podawali multum przykładów sytuacji, gdzie jakaś dana względnie nie wyglądała na taką, która miałaby się kiedykolwiek zmienić, ale w końcu przychodził taki moment, że w jakiś sposób w końcu musiała się zmienić i DEVowie mieli w tym momencie ogromny problem. Twórcy Yii w końcu zrozumieli swój błąd, przyznali rację i w Yii 2.0 już nie ma jako takiego defaultScope.

3.) Jak sam już przyznałeś - koniec końców istnieje ryzyko zmiany konkretnej danej, więc teraz opcje są dwie:
- Jesteś hazardzistą - wybierasz grę na loterii, że dany sposób przepływu informacji się nigdy nie zmieni
- Jesteś DEVem - masz możliwość dowolnego i swobodnego operowania na abstrakcyjnych danych

Argumenty raczej mówią same za siebie. Teraz niech czytelnik wybiera (IMG:style_emoticons/default/wink.gif)

Ten post edytował pyro 18.11.2014, 19:08:12