Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu php Kanał ATOM (tag: php)

Autor wpisu: Athlan, dodany: 04.01.2009 19:03, tagi: php

Zaczynając swoją przygodę z PHP nie miałem pojęcia jak wykonać paginację newsów, która załamywałaby łańcuchy liczb w momencie, w których chce. Na dzień dzisiejszy postanowiłem napisać swój nowy pager, gdyż ten, który dotychczas używałem przez ostatnie 2 lata nie odpowiadał mi pod trzema względami:

  • nagromadzenie metod, tj. setLimit(), getLimit(), zamiast pojedynczego limit(),
  • brak możliwości ustawienia załamywania się łańcucha (domyślnie były to 2 liczby): 1, 2 ... 6, 7, 8 ...  12, 13.
  • brak możliwości definiowania limitu, ilości elementów oraz aktualnie przeglądanej strony w jednej metodzie, najchętniej w samym konstruktorze.

Ostatnio potrzebowałem zwiększyć limit liczb “z przodu” i “tyłu” oraz “w środku”: 1, 2, 3 ... 5, 6, 7, 8, 9 ...  11, 12, 13

Dla tych, którzy ciągle szukają komponentu obsługującego paginację prezentuję Vframe_Pagination.

Implementacja od strony kontrolera (metoda krótka):

$oPager = new Vframe_Pagination($iItemsCount, $iLimit, $iCurrentPage);

Metoda długa:

$oPager = new Vframe_Pagination(); $oPager->limit($iLimit); $oPager->items($iItemsCount); $oPager->page($iPage);

Metody limit, items oraz page zwracają liczby odpowiadające ich nazwą niezależnie od tego, czy została podana nowa wartość w argumencie, czy nie, co jest absolutnie wygodnym (dla mnie) rozwiązaniem.

Aby wyświetlić oczekiwane rekordy, wykorzystujemy pagera:

$aData = $oModel->GetList($iUser, $oPager->start(), $oPager->limit());

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Athlan, dodany: 28.12.2008 15:35, tagi: php, internet

Projektując serwisy zaczynam ostrożnie podchodzić do usability. Temat jest bardzo wrażliwy, każdy webmaster to inne zdanie. Dziś chciałbym przedstawić problem logowania do serwisu. Oprócz hasła, przy logowaniu używamy:

  • standardowo nazwy użytkownika,
  • w niektórych serwisach adresu email, rzadziej spotykane zjawisko.

W trosce o użytkowników w kilku moich serwisach zastosowałem możliwość logowania się na adres email lub nazwę użytkownika. Wszystko po to, aby ułatwić dostęp do ukrytej części witryny, aby nikt nie “zwątpił” bo nazwy użytkownika, lub adresu email, który podał przy zakładaniu profilu. Sam używam w sieci kilku adresów email oraz kilku prefixów i suffixów do nicka Athlan. Mam problem z zalogowaniem, gdy danie nie pasują, a potrzebuję dostęp tylko na chwilę.

Przygotujmy zatem tok myślenia programu, który pobierze dane, w zależności od tego, jakie dane podał użytkownik. Pomijam walidację hasła etc:

  1. Wykrycie, czy nick jest adresem email.
  2. Jeżeli tak, pobierz dane użytkownika po polu user_mail i zapisz je do zmiennej $aUser.
  3. Jeżeli nie, pobierz dane identyfikując rekord po kluczu user_name i zapisz pobrane dane do zmiennej $aUser.

Jak możemy zauważyć, w obu przypadkach dane zapisujemy do tej samej zmiennej $aUser, więc możemy je dalej tak samo wykorzystywać. Różni się tylko pobieranie, dlateg nie trzeba w żadnym wypadku powielać kodu.

Jak słusznie zauważył devnull, należy wykluczyć możliwość użycia znaku małpy w loginie przy rejestracji użytkownika. Wyjaśnienie znajdziecie w komentarzach.

Dla programisty nie jest wiele pracy, a warto ułatwić dostęp użytkownikowi do serwisu. Usability na pierwszym miejscu ;-)

Autor wpisu: Diabl0, dodany: 28.12.2008 01:01, tagi: php, eclipse

var-autocomplete-example_0Podpowiadanie typu zmiennej za pomocą @var jest bardzo użyteczne, jednak wpisywanie tego to droga przez mękę. Niestety twórcy PDT/ZS nie pomyśleli o żadnych mechanizmach podpowiedzi zmiennych czy klas, tak że zwykle kończy się to metodą copy/paste albo żmudnym literowaniem:

/* @var $controller Zend_Controller_Front */

Przypadkiem jednak trafiłem na blog Alex @ Net na którym podpowiada on pewną sztuczkę. Poniżej tłumaczenie na polski

Na szczęście na ratunek przychodzą “szablony” dzięki którym możliwe jest uzyskanie podpowiedzi:

var-autocomplete-example_0

Aby dodać odpowiedni szablon otwórz menu Window, wybierz Preferences i przejdź do sekcji PHP/Templates. Następnie kliknij przycisk “New…” i w oknie wypełnij pola według poniższego schematu:

var-autocomplete-settings_0

Pole Pattern przepisz jak najdokładniej. ZS proponuje mi w miejsce wartości ${dollar} wartość $$ - nie słuchaj ZS ;)

Po tym zabiegu już w kodzie wpisz sobie “var” i wciśnij Ctrl+Space. Wybierz “var - Variable type hint” z listy i kontunuuj wpisując bądź wybierając nazwę zmiennej oraz klasy, jak zaprezentowano na filmiku poniżej:

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Diabl0, dodany: 27.12.2008 20:54, tagi: php

Axure

Axure

Dzisiaj chciałbym poruszyć kwestię projektowania w małych i pojedyńczych zespołach. Od razu zaznaczę że nie jestem z wykształcenia informatykiem - wszystkiego uczyłem się sam i do wszystkiego sam dochodziłem, tak więc teoretyków i uczelnianych purystów proszę o nie zabieranie głosu. Poniżej zaprezentuję bowiem podejście które nie zawsze jest zgodne z “oficjalnymi  szkołami”, ale za to sprawdzone w boju i praktyce.

Zacznę od pierwszego etapu “projektowania” czyli zbierania informacji “co chce klient”. Co prawda w moim przypadku “klient” jest zarazem moim szefem, ale nie zmienia to faktu że nie jest on programistą ani informatykiem i należy do niego podchodzić tak jak do każdego innego niedokońca zdecydowanego i wiedzącego co chce klienta.

Tak więc w moim przypadku pierwszy etap to zbieranie wszystkich wolnych myśli, pomysłów, oderwanych od siebie pragnień i wizji oraz zapisywanie ich i późniejsza próba uporządkowania. Doskonałym narzędziem wspomagającym ten proces są diagramy burzy mózgów.

Burza mózgówOsobiście wykorzystuję do tego celu Microsoft Visio. Zapewne istnieją do tego lepsze, bardziej rozbudowane lub wygodniejsze narzędzia, ale… to działa, też jest wygodne,  i mam je pod ręką ;) W każdej chwili mogę szybko otworzyć projekt i dopisywać kolejne luźne myśli oraz pomysły, a później uporządkować je w chierarchię przypominającą drzewo. W moim przypadku taka burza mózgów tworzona jest od pierwszych rozmów o projekcie do czasu zakończenia drugiej fazy jakim jest przygotowanie prototypu - projektu funkcjonalnego.

Do przygotowania prototypu wykorzystuję komercyjne narzędzie jakim jest Axure. Pozwala on na budowanie prostych witryn których jedynym celem jest zobrazowanie jak projektanci i programiści widzą to co zostało zanotowane w burzy mózgów. Prototyp taki przypomina prosty serwis, ale jest statyczny i pozbawiony elementów layoutu. Najważniejsze w nim jest przedstawienie wszystkich podstron, tabel, form, przycisków, linków i zależności typu - dodając produkt klikam tutaj, wpisuję to i to, klikam “dalej” gdzie wpisuję tamto i tamto, itp.

screen_003Dobrze wykonany rozbudowany prototyp daje klientowi namiastkę działania docelowego serwisu, pozwala nam zorientować się czy to co my widzimy to jest to co klient chce, daje możliwość wstępnego rozplanowania serwisu. Dzięki prototypowi można łatwo stworzyć odpowiednie procedury i procesy (dodanie produktu do magazynu, proces rejestracji itp), a także  odnaleźć i wyeliminować wszelkie niejasności oraz problemy z funkcjonalnością wynikające z różnej wiedzy informatyków i późniejszych użytkowników końcowych (których wiedza informatyczna często kończy się na klikaniu największych przycisków). Prototyp taki daje także możliwość szybkich poprawek i uwzględniania uwag klienta zanim jeszcze siądzie się do edytora.

Co również ciekawe, dopracowany i zaakceptowany prototyp pozwala później na łatwe odwzorowanie projektu na wzorzec MVC - dość wyraźnie widać podział na kontrolery i akcje.

Polecam obejrzenie sobie “wycieczki” prezentującej możliwości i zalety Axure - http://axure.com/tour.aspx czy przykładowego prototypu.

Kolejny 3 etap projektowania do przygotowanie bazy danych. Mając informacje z burzy mózgów oraz “podgląd” jak to będzie wyglądało w gotowym serwisie, dość łatwo możemy wywnioskować jakie informacje będziemy przechowywali, i jak będziemy na nich pracować. Ale to już temat który dość często i szeroko jest poruszany w internecie, i łatwo znaleźć odpowiednie informacje.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Athlan, dodany: 26.12.2008 20:35, tagi: php, internet

Dla niektórych wygasanie sesji jest zabezpieczeniem (banki, etc.). Realizując jeden z projektów oczekiwałem od systemu tego, aby użytkownik nigdy nie gubił sesji, gdy ma otwarte okno w przeglądarce. Dlaczego? Może dodaje posta, być może uzupełnia dość obszerny tekst na stronie. Gdy klika zapisz, przerzuca go do strony logowania, a cały tekst zniknął za sprawą tego, że jego przeglądarka nie zapisuje wartości pól formularza. Skąd to znamy.

Jak użytkownik gubi sesję?

  1. Jego ciastko wygasa, więc serwer nie może go zidentyfikować z sesją.
  2. Po jakimś czasie, choćby odtworzył ciastko, plik sesji znika z naszego serwera (garbage collection).

Rozwiązania:

  1. Wydłużenie czasu wygasania ciastka i sesji.
  2. Odświeżenie strony w interwale mniejszym, niż wynosi czas wygasania sesji i ciastka.

Rozmyślając nad podtrzymaniem sesji, próbowałem znaleźć wszystkie metody oraz wybrać najlepszą. Wszystkie sprowadzają się do “odświeżenia” strony lub jej fragmentu tak, aby nasz silnik wykonał tylko potrzebne session_start(); czyli podtrzymanie aktywności sesji. Jest kilka mniej lub bardziej zadowalających sposobów:

  1. Odświeżenie całej strony. To może spowodować, że dane wprowadzane przez użytkownika w formularzu zostaną utracone. Ponad to, jeżeli użytkownik czyta newsy, denerwującym może być fakt, że lista nagle zostanie przescrollowana do góry (prócz opery).
  2. Wysłanie requestu ajax w tle. Minusem jest to, że trzeba używać biblioteki ajax lub pisać dodatkowy kod javascriptu. Jeżeli ktoś na stronie używa jakiegoś ajaxa - co za różnica. Poza tym same plusy.
  3. Odświeżanie ukrytej ramki iframe lub elementu frameset. Minusów usablity prawie brak. Brak potrzeby instalacji javascriptów i ajaxa. Odświeżacz powinien wysłać nagłówek Refresh lub odpowiedni metatag.

Sposób 3 wydaje mi się najlepszy. Można go ulepszyć w ten sposób, aby ramka nie wysyłała żądania zaraz po załadowaniu strony. Powodowałoby to podwójne requesty do serwera.

Zapewne znajdą się osoby, które powiedzą: a co z użytkownikami, którzy mają wyłączone ramki, lub ich przeglądarki w ogóle ich nie obsługują. Zapytam wówczas: a co z użytkownikami, którzy nie akceptują cisteczek (wówczas sesje nie są dla nich użyteczne, chyba, że użyjemy przesłyki jej identyfikatora w adresie url). Dopytam również: a co z użytkownikami, którzy mają wyłączony Javascript? Patologiczne przepadki się po prostu pomija ;)

Autor wpisu: Diabl0, dodany: 26.12.2008 01:42, tagi: php

Większość użytkowników Zend Studio narzeka na powolne działanie debuggera w Zend Studio for Eclipse. Co prawda w 6.1 znacznie poprawili jego działanie, ale nadal pozostaje sporo do życzenia. Przed chwilą przypadkiem dokopałem się do ciekawej dyskusji na grupie poświęconej ZS, i wypowiedzi jednego z developerów. Cytuję z kilkoma skrótami i bez tłumaczenia.

Regarding the slow debugging – until we release an update – please approach support and you will get a patch to fix the slow debugging issue.

Has been tested and verified here and with customers.

Gadi Goldbarg, Development Tools , QA Team Leader , Zend.

I po kilku postach mocno krytykujących zachowanie firmy Zend i podejście do klienta oraz problemu kolejna odpowiedź:

You guys are correct , we should have posted it here and let you all know - please find attached a patch for slow debugging (when debug starts from toolbar).

Please replace the file under - C:\Program Files\Zend\Zend Studio for Eclipse - 6.1.0\plugins\ org.eclipse. php.debug. core_1.0. 5.v20080907. jar with attached one.

Gadi Goldbarg, Development Tools , QA Team Leader , Zend.

Plik:  orgeclipsephpdebugcore_105v20080907

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Athlan, dodany: 22.12.2008 19:50, tagi: php

Przeglądając forum.php.pl często widziałem, jak użytkownicy przechowują hasła w swoich bazach danych. Najczęściej używają funkcji hashujących md5, sha1 i sha2. Wszystko wygląda bardzo dobrze, hasła są przechowywanie bezpiecznie. No właśnie… na ile bezpiecznie.

Nie będę tutaj rozwodził się nad zabezpieczeniem baz danych, w których owa baza haseł się znajduje, ale nad samym zahashowanym ciągu. Wszyscy doskonale wiemy, że istnieją bazy md5 (sha1, sha2 również).

Przezorny zawsze ubezpieczony. Wiadomo, że nigdy nic nie wiadomo.

Pokażę, jak dodatkowo zabezpieczyć nasze hasła. Będą przechowywane w tej samej bazie danych, używając tych samych metod hashowania, a jednak szansa na “złamanie” hasła (wyszukania w bazie) będzie niemożliwa. Posłużymy się ciągiem znaków zwanym przez programistów solą (salt). Przykład implementacji możemy znaleźć w forum IPB, natomiast phpBB pozbawione jest tego fjuczuru ficzera. Cała sprawa sprowadza się do wygenerowania dowolnego kawałka ciągu znaków i doklejenia go do hasła. Sól potrzebna nam będzie również przy porównaniu hasła, więc trzeba ją zapisać w bazie danych obok hasła.

Poniżej zamieszczam przykładową klasę, która obsługuje solenie haseł. Doklejanie soli może być napisane w dowolny sposób, zależy to od Waszej wyobraźni. Ja dodatkowo dodałem element “losowy” w postaci doklejenia do soli wyniku działania funkcji microtime().

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.