On Fri, 06 Mar 2009 20:01:17 -0000, Marek <m...@s...interia.pl> wrote:

>> Chyba że jest to wyszukiwarka zewnętrzna, w sensie obcy serwis.
>> Odpowiednie oprogramowanie go może być utrudnione :)
>
> Zimno :-) Ja to zrobiłem tak:
> Formularz wyszukiwarki POSTem wysyła parametry. Moduł CMS'a
> odpowiedzialny za wyszukiwanie zapamiętuje te dane w zmiennej sesyjnej i
> wysyła nagłówek zawierający przekierowanie do siebie samego.

To straszne nadużycie HTTP.

Koncepcyjnie wyszukiwanie jest tylko widokiem na dane i nie ma efektów ubocznych. Do
zapytań bez efektów ubocznych jest GET. POST jest przeznaczony do zapytań, które mają
ważne efekty uboczne (rejestracja, dodanie komentarza, zakup, itp.)

Jeśli potem jeszcze przekierowujesz na stronę, która nie ma w URL parametrów
wyszukiwania, to już kompletnie łamiesz bezstanowość HTTP i uzależniasz treść strony
danych, o których istnieniu przeglądarka nie ma pojęcia (zmiany danych w sesji są
niewidoczne dla klientów HTTP).

> Właśnie to samo przerabiałem aż w końcu doszedłem do wniosku aby
> history.back() pozostawić przeglądarce i jeśli koniecznie trzeba ścieżkę
> prezentować to czynię to wyłącznie w formie prezentacji stopnia
> zagłębienia się w drzewku kategorii.

Z tym się zgodzę.

IMHO to nawet jest pożyteczniejsze, bo ścieżka może służyć do nawigacji po serwisie
(np. jak znajdę gdzieś link do produktu, mogę łatwo przejść do odpowiedniej kategorii
produktów, zamiast dostać linki do kręcenia się w kółko po tym samym).

--
http://pornel.net
this.author = new Geek("porneL");

do góry

On Thu, 05 Mar 2009 21:38:59 -0000, Colin <m...@g...com> wrote:

> Nie zawsze można użyć GET do wyszukiwania. Ja musiałem na jednym dużym
> (posiadającym ponad 500 działów/poddziałów) forum phpBB 3 zmienić
> method="get" na method="post", bo były generowane bardzo długie linki,
> których IE nie obsługuje, np.
>
> http://forum.********.org/search.php?keywords=Cross-
Platform+Development+in+C%2B+Building+MAC+OS+X%2C+Li
nux%2C+and+Windows+[Eng]&terms=all&author=&fid[]=19&
fid[]=1&fid[]=20&fid[]=2&fid[]=15&fid[]=24&fid[]=21&
fid[]=4&fid[]=5&fid[]=6&fid[]=7&fid[]=18&fid[]=22&fi
d[]=8&fid[]=9&fid[]=10&fid[]=11&fid[]=12&fid[]=13&fi
d[]=14&fid[]=17&fid[]=26&fid[]=27&fid[]=28&fid[]=23&
fid[]=16&fid[]=31&fid[]=35&fid[]=44&fid[]=45&fid[]=4
6&fid[]=47&fid[]=48&fid[]=51&fid[]=52&fid[]=57&fid[]
=59&fid[]=62&fid[]=63&fid[]=70&fid[]=73&fid[]=74&fid
[]=75&fid[]=76&fid[]=77&fid[]=78&fid[]=79&fid[]=80&f
id[]=81&fid[]=82&fid[]=83&fid[]=84&fid[]=85&fid[]=86
&fid[]=87&fid[]=88&fid[]=89&fid[]=90&fid[]=91&fid[]=
92&fid[]=93&fid[]=94&fid[]=95&fid[]=96&fid[]=97&fid[
]=98&fid[]=99&fid[]=100&fid[]=101&fid[]=102&fid[]=10
3&fid[]=104&fid[]=105&fid[]=106&fid[]=108&fid[]=109&
fid[]=110&fid[]=111&fid[]=112&fid[]=113&fid[]=114&fi
d[]=115&fid[]=116&fid[]=117&fid[]=118&fid[]=119&fid[
]=120&fid[]=121&fid[]=122&fid[]=123&fid[]=124&fid[]=
1


W tak skrajnym przypadku faktycznie POST może być złem koniecznym. Jak wygląda wtedy
link do drugiej strony wyników?


Alternatywnie można by dodać do formularza skrypt JS, który odznacza niepotrzebnie
zaznaczone kategorie (zakładam, że jeśli zaznaczona jest nadrzędna kategoria, to
szukanie odbywa się automatycznie we wszystkich podkategoriach i nie trzeba ich
osobno zaznaczać).


--
http://pornel.net
this.author = new Geek("porneL");

do góry

> To straszne nadużycie HTTP.

Trudno, pójdę do więzienia :-)

> Koncepcyjnie wyszukiwanie jest tylko widokiem na dane i nie ma efektów
> ubocznych. Do zapytań bez efektów ubocznych jest GET. POST jest
> przeznaczony do zapytań, które mają ważne efekty uboczne (rejestracja,
> dodanie komentarza, zakup, itp.)

Nie do końca tak jest w praktyce - nie mówię o teorii. Po pierwsze - ilość
znaków formularza czasem przewyższa możliwości GET. Po drugie znacząco
utrudniam możliwość ręcznego wpływania na sposób funkcjonowania aplikacji
gdyż nie analizuję tego co ktoś z palca wpisze sobie z nudów w adresie URL -
w szczególności automatom spamerskim, które potrafią udawać wypełnianie
formularzy (co już doświadczyłem).

> Jeśli potem jeszcze przekierowujesz na stronę, która nie ma w URL
> parametrów wyszukiwania, to już kompletnie łamiesz bezstanowość HTTP i
> uzależniasz treść strony danych, o których istnieniu przeglądarka nie ma
> pojęcia (zmiany danych w sesji są niewidoczne dla klientów HTTP).

Dokładnie tak jest. Jednakże łamanie konwenansów ma swoje zalety również.
Powrót do wyszukiwarki bez przekazywania do niej jakichkolwiek informacji
prezentuje ostatnio wyszukiwaną treść - wcale nie oznacza to defektu lecz
wręcz przeciwnie: jest to czasem bardzo użyteczne (i werbalnie oczekiwane
przez klientów) np. w przypadku sklepu internetowego. Ktoś przykładowo
kupuje podzespoły elektroniczne z określonej kategorii o określonych
parametrach. Wyszukuje np. rezystory o mocy 1W, klika na jednym z nich,
czyta kartę katalogową, dodaje do koszyka. Koszyk sugeruje mu inny produkt
lub modyfikację zamówionej ilości, klient wchodzi na kartę katalogową tego
innego produktu, znów dodaje do koszyka, modyfikuje ilość, submituje koszyk
(= kartę zamówienia w tym przypadku). Teraz chce kontynuować zakupy w
poprzednio wybranej kategorii więc zamiast klikać 10x wstecz, klika raz
tylko guzik "powrót do wyszukiwarki". Wyobraź sobie co się stałoby gdyby po
drodze przytrafił się jakiś POST. Wtedy taki "wstecz" wywaliłby komunikat o
potrzebie re-akceptacji formularza. Nigdy klientowi nie udałoby się wrócić
do ważnego etapu w procesie kompletacji zamówienia. Musiałby od początku
przechodzić przez procedurę wyszukiwania przy każdym podzespole. Przy ilości
50 szt. to koszmar....

do góry

> No, ja mam do czynienia kilka razy dziennie. Allegro, sklepy internetowe,
> różne skąpce i ceneo, portal Wyborczej itd. itp.

Ja zwykle robię nieco bardziej rozbudowane strukturalnie sklepy / portale
itp. Ten sam produkt / dokument może występować w kilku miejscach: np. w
elektronice / rezystory, w elektronice / zestawy do montażu, w top 10 a
także na głównej stronie jako płatna reklama. No i wtedy powstaje dylemat:
jak zaprezentować taką ścieżkę do produktu? Przedstawić wszystkie warianty?

Może mam takie szczęście lecz sporadycznie trafia mi się realizacja
hierarchicznie jednoznaczna.

> Niekoniecznie o chmury, to tylko metoda wizualizacji. A "słowa kluczowe"
> to pojęcie szersze niż "tagi" czy jak to tam po polsku może brzmieć.

Rozwiń wątek proszę - może jakiś przykład tego co masz na myśli?

do góry

Przepraszam, nie ustosunkowałem się do n/w Twojej wypowiedzi. Za dużo mi się
wycięło :-)

>> Nie zawsze.W przypadku funkcjonalnych sekcji serwisu WWW nie będących
>> dokumentem pojęcie kategorii nie istnieje więc nie można np. wyszukiwarki
>> czy modułu newsów umieścić na jakimkolwiek poziomie hierarchii.
>
> Nie rozumiem.

Przykładowo masz na stronie głównej sklepu internetowego guzik
"wyszukiwarka". Gdy go klikniesz przechodzisz do sekcji pozwalające na
wyszukiwanie produktów. Możnaby więc ścieżkę określić jako Strona główna /
wyszukiwarka. A co jeśli klikniesz guzik "wyszukiwarka" w karcie katalogowej
produktu po przebyciu złożonej drogi do tego produktu? Najwłaściwiej byłoby
pokazać:

antyki / obrazy / .. / .. / obuwie / kapcie domowe / .. / kalosze /
wyszukiwarka

Trudno ją w takim przypadku kategoryzować.

do góry

On 07.03.2009, Marek <m...@s...interia.pl> wroted:

>> Niekoniecznie o chmury, to tylko metoda wizualizacji. A "słowa kluczowe"
>> to pojęcie szersze niż "tagi" czy jak to tam po polsku może brzmieć.
>
> Rozwiń wątek proszę - może jakiś przykład tego co masz na myśli?

Tagi to po prostu rodzaj etykiet. Termin "słowa kluczowe" może być mylący,
bo jest bardziej ogólny (np. stosowany dla terminów wyszukiwania etc).
Chmury to rodzaj wizualizacji, najczęściej tagów "społecznościowych",
czyli metadanych dodawanych przez samych użytkowników, ale spotyka się
też np. tagi stosowane przez autorów serwisu, z możliwością użycia np.
przy wyszukiwaniu.

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

do góry

On 07.03.2009, Marek <m...@s...interia.pl> wroted:

>>> Nie zawsze.W przypadku funkcjonalnych sekcji serwisu WWW nie będących
>>> dokumentem pojęcie kategorii nie istnieje więc nie można np. wyszukiwarki
>>> czy modułu newsów umieścić na jakimkolwiek poziomie hierarchii.
>>
>> Nie rozumiem.
>
> Przykładowo masz na stronie głównej sklepu internetowego guzik
> "wyszukiwarka". Gdy go klikniesz przechodzisz do sekcji pozwalające na
> wyszukiwanie produktów. Możnaby więc ścieżkę określić jako Strona główna /
> wyszukiwarka. A co jeśli klikniesz guzik "wyszukiwarka" w karcie katalogowej
> produktu po przebyciu złożonej drogi do tego produktu? Najwłaściwiej byłoby
> pokazać:
>
> antyki / obrazy / .. / .. / obuwie / kapcie domowe / .. / kalosze /
> wyszukiwarka
>
> Trudno ją w takim przypadku kategoryzować.

No cóż, jak dla mnie, to o wiele za szczegółowe. Poza tym, w tym momencie
mówisz o śledzeniu w breadcrumbsach drogi jaką użytkownik trafił do
wyszukiwarki, a to IMVHO nie ma zbyt wiele sensu. Wyszukiwarka równie
dobrze może być zupełnie wyłączona z hierarchii serwisu, a jeśli równoległych
hierarchii da się wydzielić kilka -- ale jednoznacznych -- to relatywnie
niewielkim wysiłkiem można treść sklasyfikować na kilka sposobów, dając
możliwość przeglądania w kilku hierarchiach (jakieś przyciski w menu
z opisami choćby "według kształtu", "według przeznaczenia", "według
pochodzenia" i po ich wybraniu chodzenie po kategorii z breadcrumbsami
odzwierciedlającymi daną hierarchię). Jeśli nie da się jednoznacznie
klasyfikować, lepsze są jednak tagi.

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

do góry

On Sat, 07 Mar 2009 12:32:58 -0000, Marek <m...@s...interia.pl> wrote:

> Nie do końca tak jest w praktyce - nie mówię o teorii. Po pierwsze -
> ilość znaków formularza czasem przewyższa możliwości GET. Po drugie
> znacząco utrudniam możliwość ręcznego wpływania na sposób funkcjonowania
> aplikacji

Ale POST wcale nie jest bezpieczniejszy niż GET! W obu przypadkach każdy ma możliwość
przesłania ci dowolnych danych.

Nawet nie potrzeba do tego specjalnie hackerskich narzędzi, np. w Operze można
otworzyć źródło strony, przerobić formularz, odświeżyć stronę z cache i wysłać
przerobione dane.

Tak czy inaczej, przychodzące dane musisz sprawdzać. W przypadku PHP kod praktycznie
nie różni się, czy użyjesz $_GET, $_POST czy $_SESSION.

> gdyż nie analizuję tego co ktoś z palca wpisze sobie z nudów w
> adresie URL - w szczególności automatom spamerskim, które potrafią
> udawać wypełnianie formularzy (co już doświadczyłem).

POST przyciąga spamerskie boty znacznie bardziej niż GET, a dobrym botom można
zakazać GET w robots.txt.

>> Jeśli potem jeszcze przekierowujesz na stronę, która nie ma w URL
>> parametrów wyszukiwania, to już kompletnie łamiesz bezstanowość HTTP i
>> uzależniasz treść strony danych, o których istnieniu przeglądarka nie
>> ma pojęcia (zmiany danych w sesji są niewidoczne dla klientów HTTP).
>
> Dokładnie tak jest. Jednakże łamanie konwenansów ma swoje zalety
> również. Powrót do wyszukiwarki bez przekazywania do niej jakichkolwiek
> informacji prezentuje ostatnio wyszukiwaną treść - wcale nie oznacza to
> defektu lecz wręcz przeciwnie: jest to czasem bardzo użyteczne

OK, ale proponuję to robić dodatkowo, a nie zamiast tworzenia niezawodnych URL-i.

> "powrót do wyszukiwarki". Wyobraź sobie co się stałoby gdyby po drodze
> przytrafił się jakiś POST. Wtedy taki "wstecz" wywaliłby komunikat o
> potrzebie re-akceptacji formularza.

To nie ma związku z wyszukiwarką, szczególnie jakbyś prawidłowo użył GET.

Kiedy potrzeba użyć POST, to ten bug obchodzi się wysyłając status 303 i
przekierowanie. Tego się nie czepiam. Czepiam się, że używasz POST zamiast GET tam,
gdzie się nie powinno.

--
http://pornel.net
this.author = new Geek("porneL");

do góry

> Ale POST wcale nie jest bezpieczniejszy niż GET! W obu przypadkach każdy
> ma możliwość przesłania ci dowolnych danych.

Ja nie mówiłem o bezpieczeństwie wcale lecz o utrudnieniu ingerencji. Powiem
na przykładzie: był kiedyś formularz kontaktowy na jakimś serwisie
wykorzystujący GET. Okazało się, że w pewnym momencie przychodziły z niego
jakieś dziwne emaile i to po kilka na sekundę. Poproszono mnie o pomoc w tym
temacie. Z chwilą gdy przerobiłem go na POST ruch natychmiast ustał.
Dodatkowo dorzuciłem jeszcze w ukrytym polu ID transakcji aby jeszcze
bardziej ograniczyć działalność botów spamerskich.

> Nawet nie potrzeba do tego specjalnie hackerskich narzędzi, np. w Operze
> można otworzyć źródło strony, przerobić formularz, odświeżyć stronę z
> cache i wysłać przerobione dane.

Ale to już wymaga znacznie większej ilości pracy. Niewiele osób ma ochotę
grzebać aż tak głęboko. GET wypełnią nawet nudzące się dzieci.

> POST przyciąga spamerskie boty znacznie bardziej niż GET, a dobrym botom
> można zakazać GET w robots.txt.

Sęk w tym, że identyfikacja takiego bota jest żadna. Przypadkowy IP,
podszywanie się pod przeglądarkę itp. Nie ma jak zakazać.

> OK, ale proponuję to robić dodatkowo, a nie zamiast tworzenia niezawodnych
> URL-i.

No dobrze, a po co w serwisie dwie wyszukiwarki oferujące to samo tyle
tylko, że jedna pracująca w trybie GET i nie pozwalająca na łatwy powrót do
niej gdy w łąńcuszku zdarzeń jakiś POST się przytrafił?

> To nie ma związku z wyszukiwarką, szczególnie jakbyś prawidłowo użył GET.

Akurat to ma związek m.in. z wyszukiwarką i każdym innym formularzem w
serwisie. Jeśli wszystkie formularze zostaną zamaskowane w podobny do
wspomnianego sposób to wszystkie zadziałają w sposób intuicyjny dla
oglądającego w chwili gdy będzie on cofał się o dowolną ilość kroków.

> Kiedy potrzeba użyć POST, to ten bug obchodzi się wysyłając status 303 i
> przekierowanie.

Nie zaskoczyłem? Co można w ten sposób zyskać i jak miałoby to działać?
Jeśli możesz to przedstaw mi krok po kroku wypełnienie formularza i wpływ
tej medody na problem "wstecz".

> Tego się nie czepiam. Czepiam się, że używasz POST zamiast GET tam, gdzie
> się nie powinno.

POST tak czy owak muszę stosować choćby z uwagi na limit danych GET. Już raz
musiałem przerabiać formularz gdy zaczął się rozrastać aż w końcu
przekroczył limit. Spróbuj potem namierzyć problem gdy coś bardzo
sporadycznie przestaje działać... GET jest dobry dla prostych i zamkniętych
rozwiązań typu wyszukiwarka Google. Gdy co jakiś czas musisz dodawać nowe
funkcje, bo klient tak sobie życzy, to zrobisz sobie krzywdę prędzej czy
później bazując na GET.

do góry

> Tagi to po prostu rodzaj etykiet. Termin "słowa kluczowe" może być mylący,
> bo jest bardziej ogólny (np. stosowany dla terminów wyszukiwania etc).
> Chmury to rodzaj wizualizacji, najczęściej tagów "społecznościowych",
> czyli metadanych dodawanych przez samych użytkowników, ale spotyka się
> też np. tagi stosowane przez autorów serwisu, z możliwością użycia np.
> przy wyszukiwaniu.

Chmury stosuje np. Empik... Jednakże nadal nie bardzo wiem jak po stronie
wizualnej te tagi miałyby występować. Jak klienci mieliby operować nimi
podczas wyszukiwania jeśli nie są to słowa kluczowe, które gdzieś wpisać
można?

do góry