Kawałek Kodu

Programistyczne porady na luzie

Hasz a kysz! Czyli o przekierowaniach serwerowych z hash.

Bez obaw! Nie będziemy negować zalet ziołolecznictwa, ani dyskredytować hashtagów, ani tym bardziej używać środków psychoaktywnych podczas przekierowań użytkowników. Będzie po prostu o hash - najbardziej leniwej części URL. Będziemy go nazywać hash, choć poprawnie by było nazwać fragmentem lub kotwicą.

Czytaj dalej

"The tag is out there", czyli DOMXPath S01E04

Wstęp.

Dziś odcinek w stylu Indiany Jones'a. Pobawimy się trochę linami... tzn. linkami. Szykuj się na przemierzanie gęstej dżungli węzłów!

Czytaj dalej

"The tag is out there", czyli DOMXPath S01E03

Wstęp.

Czekałeś na kolejną część podążania mrocznymi, albo może już teraz jasnymi, ścieżkami XPath? Już nie musisz się nudzić. Dziś kolejna porcja praktycznych przykładów.

Czytaj dalej

"The tag is out there", czyli DOMXPath S01E02

Wstęp.

Dziś to co tygrysy lubią najbardziej. Czysta praktyka i (w miarę) konkretne przykłady. Będziesz mieć niebywałą okazję dostrzec, że XPath może służyć do rozwiązania kwestii, które nie śniły się filozofom. Od czego świat ma Ciebie!

Czytaj dalej

All inclusive... czyli jak unikać dynamicznego budowania zapytania SQL. Part II.

Zdarzyło Ci się pewnie nie raz pracować na więcej niż jednej tabeli (tabeli bazodanowej, a nie wyników meczu). A jeśli tak, to pewnie zdarzyło Ci się również łączyć obydwie przy pomocy złączenia LEFT JOIN. Jeśli nie, to pozwól, że wspomnę pokrótce na czym polega takie złączenie.

Załóżmy, że masz tabele klientów oraz tabele ich zamówień. Jeśli złączysz obydwie poprzez warunek w klauzuli WHERE lub poprzez INNER JOIN, otrzymasz wynik przedstawiający klientów i ich zamówienia. Ale tylko tych klientów, którzy złożyli (tym razem nie złączyli!) zamówienia. Tych, którzy zarejestrowali się w serwisie, ale nie mają zamówień, nie będzie widać w wyniku tego zapytania. Aby wyświetlić wszystkich klientów i zamówienia, należy użyć wspomnianiego złączenia LEFT JOIN. Dla takich klientów w miejscu ich zamówień otrzymasz wartości null.

Wyobraź sobie, że budujesz teraz system, który posiada możliwość filtracji wyników, a dokładnie pokazania wszystkich klientów i tylko tych z zamówieniami (pewnie jest tam jakiś ptaszek w formularzu, którym włączasz i wyłączasz tą opcję).

I tu rodzi się odwieczne pytanie. Czy da się? Czy da się zbudować tak zapytanie, żeby przekazując określoną wartość wybrać daną pulę wyników i wykorzystać tylko jedno złączenie?

Czytaj dalej

To be or not to be, that is the query...czyli jak unikać dynamicznego budowania zapytania SQL w zależności od istnienia wartości.

Czasem masz dobry humor, a czasem zły. W obydwu przypadkach możesz zostać w domu.
Czasem do Twojego zapytania dociera wartość wykorzystywana w klauzuli WHERE, a czasem jej kompletnie brak.

Czy w tym przypadku możesz używać stałej składni zapytania bez potrzeby jej modyfikowania w zależności od istnienia tejże wartości?

Czytaj dalej