Wyciąganie danych z formularzu HTML, aby utworzyć plik tekstowy

0

Cześć,

proszę mnie nakierować jak wyłuskać dane z formularzu html do pliku tekstowego, aby móc go wkleić jako opis badania.

3

Dane przesłane przez formularz pobierasz po stronie serwera wykorzystując zmienne superglobalne $_POST i/lub $_GET. Więcej o nich możesz przeczytać chociażby tutaj:
https://www.w3schools.com/php/php_superglobals_get.asp
https://kursphp.com/zmienne-superglobalne/
https://www.w3schools.com/php/php_superglobals_post.asp
https://phpkurs.pl/przekazywanie-danych/
https://www.php.net/manual/en/reserved.variables.get.php

Samo zapisanie do pliku przez PHP możesz obczaić chociażby tutaj:
http://funkcje.net/view/3/1/12520/index.html
https://phpkurs.pl/operacje-na-plikach/
https://kursphp.com/rozdzial-5/zapisywanie-pliku/
http://www.kess.snug.pl/?sid=10&pid=19

Tylko się upewnij, czy masz prawa zapisu do katalogu/lokalizacji, w której chcesz dokonać zapisu, a także czy ten folder nie jest publicznie dostępny - żeby nie okazało się, że zapisane przez Ciebie do pliku wyniki badania są dostępne dla wszystkich przez Twój serwer WWW ;)

1

Ale tak swoją drogą, po co opisy badań przechowywać w plikach tekstowych,? Po to jest baza danych, np. MySQL. Jeżeli później chcesz pobrać taki plik to takie php pobiera wartości z bazy według zapytania, a następnie generuje plik i przesyła go w nagłówku do pobrania. Oczywiście po ówczesnym napisaniu kodu, który to zrobi :P

0
KrisKros123 napisał(a):

Ale tak swoją drogą, po co opisy badań przechowywać w plikach tekstowych,? Po to jest baza danych, np. MySQL. Jeżeli później chcesz pobrać taki plik to takie php pobiera wartości z bazy według zapytania, a następnie generuje plik i przesyła go w nagłówku do pobrania. Oczywiście po ówczesnym napisaniu kodu, który to zrobi

@KrisKros123: A co mu to da?

Pliki tekstowe są dużo lżejsze, nie wymagają działających procesów, tańsze w tworzeniu i utrzymaniu.

Bazy danych trzeba konfigurować, pilnować struktur, tworzyć migracje, są też trudniejsze w utrzymaniu i łatwo o błędy, np sql injection.

Mam wrażenie że usłyszałeś po prostu "bazy są najlepsze" i teraz wciskasz je wszędzie. Poza tym, wątpię żeby gość który nie umie obsługiwać plików poradził sobie z bazą.

@3l3ctric_philip Skorzystaj z linków od cerrato, będzie git.

1
TomRiddle napisał(a):

Bazy danych trzeba konfigurować, pilnować struktur, tworzyć migracje, są też trudniejsze w utrzymaniu i łatwo o błędy, np sql injection.

Kij ma dwa końce.

  • Gospoodarka plikami wymaga katalogów otwartych do zapisu itd, których nie potzreba, gdy mamy serwerową bazę (tj nie SQLite). Często się okazuje, że w intencji uchylenia lufcika w prawach dostępu, otwiera się wrota.
  • plik trzeba dobrze zaplanować, oj naprawdę dobrze, jeśli mam być wczytywany automatycznie, np do modyfikacji. Bardziej sformalizowana baza zmniejsza szanse na strzał w stopę. Sądzę, ze większość plikowych projektów od początkujących ląduje z plikami nie dającymi się przetwarzać. Wystarczy znak "umownie specjalny" pojawiający się we wprowadzonych danych, i leci w pi...u
  • współbieżność
0

Pliki tekstowe są dużo lżejsze, nie wymagają działających procesów, tańsze w tworzeniu i utrzymaniu.
Bazy danych trzeba konfigurować, pilnować struktur, tworzyć migracje, są też trudniejsze w utrzymaniu i łatwo o błędy, np sql injection.

Ale masz SQLite, które tak zasadniczo jest bardziej rozbudowanym plikiem tekstowym. W sensie - można tego użyć jako zamiennika "prawdziwej" bazy - przy mniejszym obciążeniu/niewielkich wymaganiach, ale także jako alternatywę dla pliku. O wiele łatwiej się do takiej bazy zapisuje dane, odczytuje, filtruje, mniejsze jest ryzyko niż w przypadku ręcznego grzebania w pliku - tutaj chciałem z grubsza napisać to, co @AnyKtokolwiek powyżej, ale typek był szybszy ;)

0
cerrato napisał(a):

Pliki tekstowe są dużo lżejsze, nie wymagają działających procesów, tańsze w tworzeniu i utrzymaniu.
Bazy danych trzeba konfigurować, pilnować struktur, tworzyć migracje, są też trudniejsze w utrzymaniu i łatwo o błędy, np sql injection.

Ale masz SQLite, które tak zasadniczo jest bardziej rozbudowanym plikiem tekstowym. W sensie - można tego użyć jako zamiennika "prawdziwej" bazy - przy mniejszym obciążeniu/niewielkich wymaganiach, ale także jako alternatywę dla pliku. O wiele łatwiej się do takiej bazy zapisuje dane, odczytuje, filtruje, mniejsze jest ryzyko niż w przypadku ręcznego grzebania w pliku - tutaj chciałem z grubsza napisać to, co @AnyKtokolwiek powyżej, ale typek był szybszy ;)

No racja, SQLite część tych wad ogarnia.

Ale still, nie jestem taki pewien czy dla początkującego lepsze byłoby file_put_contents('plik.json', json_encode($date)), czy pisanie query z PDO. Oczywiście dobrze byłoby żeby znał bazy danych; ale dla mnie takie podejście, że potrzbuje persystencji - ergo od razu robię bazę nie ważne co, to jest takie trochę meh. To jakby powiedzieć "jestem głodny - kupię restaurację" :D

1

takie podejście, że potrzbuje persystencji - ergo od razu robię bazę

Tylko żeby ogarnąć JSON i jak działa encode/decode to też trzeba chwilę posiedzieć, więc równie dobrze można te kilka minut poświęcić na całkowite podstawy PDO, które jednak nie są czarna magią, nie trzeba mieć doktoratu ani 7 lat doświadczenia, bez przesady. Wydaje mi się, że osobie która nie miała styczności ani z PDO ani JSON, załapanie o co chodzi przyjdzie porównywalnie łatwo/trudno. Przy czym (to oczywiście - zależy od zastosowań) SQL daje o wiele więcej, niż można sobie wyczytać z JSON. Weź np. w oparciu o plik tekstowy (w dowolnym formacie - może być ten JSON) znajdź wszystkie wpisy zrobione przez Anię w czerwcu zeszłego roku o tematyce "koty i inne przedmioty kultu". Oczywiście - da się, ale trzeba trochę powalczyć. A przy SQL to jedno zapytanie - piszesz co chcesz, a potem już sam silnik się zajmie sprawą. Oczywiście - JSON też się da tak przeszukać, ale (moim zdaniem) ilość pracy będzie większa.

"jestem głodny - kupię restaurację"

Ja w takich sytuacjach używam innej analogii - kupować TIR'a, żeby przewieźć babci szafkę ;) Ale sens dokładnie ten sam

0
cerrato napisał(a):

takie podejście, że potrzbuje persystencji - ergo od razu robię bazę

Tylko żeby ogarnąć JSON i jak działa encode/decode to też trzeba chwilę posiedzieć, więc równie dobrze można te kilka minut poświęcić na całkowite podstawy PDO, które jednak nie są czarna magią, nie trzeba mieć doktoratu ani 7 lato doświadczenia, bez przesady. Wydaje mi się, że osobie która nie miała styczności ani z PDO ani JSON, załapanie o co chodzi przyjdzie porównywalnie łatwo/trudno. Przy czym (to oczywiście - zależy od zastosowań) SQL daje o wiele więcej, niż można sobie wyczytać z JSON. Weź np. w oparciu o plik tekstowy (w dowolnym formacie - może być ten JSON) znajdź wszystkie wpisy zrobione przez Anię w czerwcu zeszłego roku o tematyce "koty i inne przedmioty kultu". Oczywiście - da się, ale trzeba trochę powalczyć. A przy SQL to jedno zapytanie - piszesz co chcesz, a potem już sam silnik się zajmie sprawą. Oczywiście - JSON też się da tak przeszukać, ale (moim zdaniem) ilość pracy będzie większa.

"jestem głodny - kupię restaurację"

Ja w takich sytuacjach używam innej analogii - kupować TIR'a, żeby przewieźć babci szafkę ;) Ale sens dokładnie ten sam

No tak, zgadzamy się :D

Po prostu chciałem zasugerować, że baza danych to nie jest jedyna możliwość, i są inne które mają swoje wady i zalety. Nie powinniśmy automatycznie wybierać jakichś rozwiązań bo są popularne, tylko na chłodno się zastanowić co się opyla.

PS: Jeszcze włożę kij w mrowisko, A przy SQL to jedno zapytanie - piszesz co chcesz, a potem już sam silnik się zajmie sprawą. - tak, ale potem to trzeba zserializować na domenę biznesową; a serializując dane do pliku nie musisz. Także coś za coś :D Ale to totalnie włożyłem kij w mrowisko po nic.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0