Forum PHP.pl

[PHP] pobierz, plaintext 
	))))))))))
	))))))))))
	))))))))))
	))))))))))));
[PHP] pobierz, plaintext 

Wiesz, że

[PHP] pobierz, plaintext 
str_replace
[PHP] pobierz, plaintext 

obsługuje tablice?

Najładniej by było zrobić z kodów miasta klucze tablicy, wtedy będzie to bardzo proste, aby uzyskać miasto po podaniu id.

https://stackoverflow.com/questions/3545115...ue-in-php-array

https://www.php.net/manual/en/function.str-getcsv.php

https://www.webslesson.info/2017/09/how-to-...-using-php.html pierwszy wynik z Google.

- środowisko lokalne z php, konsola
- composer
- dodaj bibliotekę do zależności
- zainstaluj
- stwórz formularz HTML
- obsłuż dane POST z formularza używając wspomnianej biblioteki.

Nie da się w kilku słowach, każde wymaga zaznajomienia się z zagadnieniem. Jak masz z tym problem zleć to komuś.

https://github.com/johnzuk/GusApi

Inaczej do 50zł/h brutto.

Nazywa się to zero wiodące, w mysql "zerofill". Generalnie niezalecana praktyka, te zera to warstwa prezentacji.

Nadal to tylko mówi, że aktualna rola jest wczytana w sesji, nie jest to rozwiązaniem wątpliwości, bo moje rozterki nie dotyczą interfejsu. Nie ma dla mnie technicznej różnicy czy rolę wybieram zaraz po zalogowaniu czy w każdym momencie, bo generowałoby to ten sam efekt w postaci przeładowania systemu.

Bardziej pytam o to, że jak przechowywać i obsłużyć te rolę w backendzie, to czy w interfejsie będzie w górnej belce, czy w widoku powitalnym to akurat ma dla mnie drugorzędne znaczenie.

Mamy standardową autoryzację, zalogowanego użytkownika i jest ok. Przychodzi taki moment, że jedna osoba spełnia kilka ról, które się różnią znacząco pod względem zakresu funkcji i dostępu do zasobów. Weźmy za przykład dziennik szkoły gdzie user Jan Kowalski jest skrajnym przypadkiem, że jest nauczycielem wf, uczniem szkoły wieczorowej oraz ma 3jkę dzieci w tym 2 z nich w jednej klasie. Oczywiście wszystko na jednym loginie i haśle.

Jakie mechanizmy, patterny byście użyli dla takiej sytuacji? W jaki sposób przechowywać role, rozróżniać, trzymać w sesji, autoryzować itp? Miałem okazję już wdrażać takich mechanizm, ale chce podejść do tematu na świeżo, bo pozornie prosta sprawa wcale taka nie jest.

Rozdzielić kod na biblioteki, mikroserwisy i przyznać dostęp tylko do części kodu, którą dana osoba będzie się realnie zajmować.

Tutaj parę ściąg, aby rozróżnić integracyjne od jednostkowych:
https://www.google.com/search?q=2+unit+test...off&tbm=vid


Osobiście, ze względu na braki kadrowo/czasowe pisze głównie integracyjne, są one bardziej praktyczne, weryfikują działanie podobnie do testera manualnego, więc po prostu robią to co początkujący programista robi sam po jakimś update - przeklikuje system.

Przemyśleć NoSQL, bo do tego w teorii (nie jestem praktykiem) do tego najlepiej się nadają, gdy dane się rozrastają poziomo i nie jest ich istotny format.

Natomiast w bazie relacyjnej tworzysz 2 tabele - jedną z parametrami, drugą z wartościami. Many to many.
Jest też hybrydowe podejście - z jedną tabelą. Podobne do tego co podał @Pyton_000, ale przez nazwę pola rozumie się nazwę kodową (klucz unique na id produktu + nazwa), a same deklaracje pól określasz w configu aplikacji w php. Można wtedy elastycznie operować parametrami, pobawić się w rzutowanie, zawrzeć logikę walidacji. To by było ciężkie do osiągnięcia gdyby parametry pola były zwykłym wierszem w bazie.

Ta minifikacja Ci nabruździ. To nie jest taka prosta sprawa, że wywalisz białe znaki, bo w niektórych elementach HTML one mają znaczenie, albo nawet są interpretowane. Komentarze można wywalić choć logiczniej i tak używać tych z blade.

To jest typowe zadanie dla relacji Many to many. Pakowanie do json takich idików to anty pattern.

A jak klika 2 razy, ale wolniej to już nie ma problemu?

https://laravel.com/docs/6.x/validation#rule-unique

na samym końcu jest przykład z dodatkowym where.

Średni ten skrypt, zmieniłbym bym to na GROUP BY `date` i COUNT i masz gotową strukturę jednym zapytaniem.
Żeby liczyć unikalne można dodać potem DISTINCT.

REQUEST_URI to nie jest jest stała, tylko string.

Raczej nie, robiłem taki skrypt i do dzisiaj działa.

Google Drive (dysk Google) posiada API za pomocą którego możesz wgrywać pliki dowolną metodą, także tworząc własny skrypt na swojej stronie i tak to tam zrobisz to jest to nieistotne.
Samej usługi Google Sites nie znam, mówię w kontekście normalnej strony www.

Jeżeli baza składa się z czegoś takiego jak to najpierw zajmij się strukturą, a potem z niej coś wyciągaj.

Teraz to rozlane mleko, faktury wystawiasz i numerujesz zgodnie z kolejnością realną, więc jeżeli już wtedy nie zapełniłeś luki to masz błąd księgowy.
Fakturę można usunąć i wstawić za nią nową jeżeli nie weszła w obieg w żaden sposób, jeżeli weszła to się ją zostawia i oznacza jako anulowaną.
Od strony skryptu nigdy nie można dopuścić, aby w danej serii została luka.

Oczywiście mówimy o numerze faktury, numerze w konkretnej serii jeżeli być bardziej precyzyjnym. Primary ID jest tutaj akurat nieistotne, leci sobie swoim życiem i się w nie nie ingeruje.

Dostęp do edycji/dodawania już napisałem jak rozwiązujemy - walidacją/filtracją, a to aby get'em otrzymać odchudzony obiekt możemy wykorzystać API Resource.
Oczywiście możliwe, że już ktoś wpadł na to aby ubrać to w jakąś libkę, która by to robiła za pomocą jednej "konfiguracji".