Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: batman, dodany: 18.10.2009 21:19, tagi: javascript

W poprzednim artykule poświęconym Adobe AIR, pokazałem co i jak zainstalować, by móc  korzystać z Adobe AIR. Dzisiaj przedstawię krok po kroku proces tworzenia aplikacji. Zanim jednak przejdziemy do istoty problemu, muszę nieco ponudzić na temat samej technologii. Co to jest i dlaczego jest takie fajne? Do tworzenia aplikacji Adobe AIR w zupełności wystarczy znajomość tego samego HTML-a, CSS

Autor wpisu: stormfly, dodany: 17.10.2009 18:32, tagi: php

Wydawałoby się, że sprawdzenie czy w danym terminie są wolne pokoje to coś prostego. Przysporzyło mi to jednak dość dużo problemów i z pomocą przyszedł mi CoYoT (#php.pl), który podesłał mi gotowe zapytanie, które sam kiedyś opracował. Zanim jednak podam to zapytanie, stwórzmy...

Autor wpisu: batman, dodany: 17.10.2009 09:42, tagi: zend_framework

Każdy, kto chociaż raz musiał dodać menu i breadcrumbs do strony internetowej, wie jak niewdzięczne jest to zadanie. Można je wykonać na dwa sposoby – ręcznie (i modyfikować za każdym razem, gdy w strukturze strony zajdą jakieś zmiany) lub przy pomocy skryptu. W tym drugim przypadku należy napisać/znaleźć odpowiedni skrypt, który będzie prosty w użyciu oraz utrzymaniu. Rozwiązaniem takim jest

Autor wpisu: batman, dodany: 14.10.2009 21:45, tagi: javascript

Stosunkowo niedawno pojawiła się nowa technologia, umożliwiająca tworzenie aplikacji desktopowych przy użyciu HTML, CSS oraz javascript. Wbrew pozorom aplikacje stworzone w Adobe AIR, oferują szeroki wachlarz możliwości, który w zupełności zadowoli większość programistów, chcących pisać aplikacje desktopowe. W dzisiejszym artykule opiszę czym jest Adobe AIR oraz co trzeba zainstalować w systemie

Autor wpisu: thejw23, dodany: 14.10.2009 20:24, tagi: php

zabierajac sie za robienie stron, umowa jest podstawowa rzecza od ktorej powinno sie zaczynac prace. nie ma umowy - nie ma pracy. koniec i kropka. poczatkujace osoby lubia wierzyc na slowo i np. wykonac polowe serwisu bez umowy, ale takie postepowanie w koncu sie zemsci, a jedyna stratna na tym osoba bedzie programista. dlatego warto sie zastanowic co tak na prawde powinno byc w umowie aby on tez byl zabezpieczony w razie konfliktu.0) wszystko musi byc ustalane na pismie, mozna w to wliczyc email. nie mam emaila z informacja o czyms - nie bede tego robil. na wszelki wypadek, klient nie powie pozniej, ze czegos nie chcial, albo chcial inaczej.1) umowa zawsze powinna miec zakres prac oraz specyfikacje dokladnie wyjasniajaca (strona po stronie) funkcjonalnosc wszystkich elementow strony. bez tego mozna ocenic strone na xx godzn pracy, a w trakcie zorientujemy sie, ze na polowie podstron wymagane sa fikusne animacje js plus zaleznosci miedzy obiektami w bazie maja byc znacznie bardziej skomplikowane niz poczatkowo deklarowano i... jestesmy yyy godzin pracy  (i zzz PLN) w plecy - bo miesci sie to w zakresie umowy i ogolnych ustaleniach, ale nie bralismy tego pod uwage przy wycenie.2) specyfikacja to jedno, ale wazne jest jasne postawienie sprawy: specyfikacja zawiera podstawowa funkcjonalnosc i to programista okresla co to znaczy 'podstawowa funkcjonalnosc'. czyli nikt nam nie wcisnie finezyjnego prezentowania wynikow wyszukiwania na stron, gdzie animowany renifer przeskakuje przy stronicowaniu. w umowie bylo 'wyszukiwanie i stronicowanie' i to ja okreslam co to znaczy (chyba, ze w specyfikacji jest uwzgledniony renifer)i chyba tyle jesli chodzi o to aby nie dac sie zrobic w bambuko i nie pracowac 50% wiecej za ta sama kase. pozostale punkty sa juz tylko emanacja rownouprawnienia w umowie.3) akceptacja dziela. czesto wymagana do zaplaty. warto dac zapis, ze musi byc on np. w przeciagu 7 dni od daty przekazania dziela, po tym terminie dzielo uznaje sie za zaakceptowane. inaczej mozemy sporo czekac az laskawie nam panujacy klient przeleje pieniadze.4) termin oddania. czesto jest zwiazany z karami za opoznienia. ok, ale co z karami za brak wynagrodzenia? czyli np. wynagrodzenie jest platne w przeciagu 14 dni od daty akceptacji. kazdy dzien spoznienia wiaze sie kara umowna xxx - gdzie xxx to kara adekwatna do spoznienia z terminem oddania dziela5) konsultacje. jesli nie ma kwoty za dzielo, a np. kwota za godzine pracy nad strona, to zawsze musi tam byc informacja, ze w ramach pracy nad strona rozumiane sa rowniez wszelkie konsultacje w tej sprawie. konsultacja rowna sie niemal zawsze przekazaniu wiedzy, a od kiedy to jest darmowe? (ok, sa instytucje  pro publico bono, prawnicy tez maja czasami darnowe porady... ale nie kazdy musi)6) klient ma strone, a jeszcze nie zaplacil. zamiast siedziec i plakac warto dac w umowie podpunkt informujacy, iz do czasu pelnego rozliczenia dziela prawa autorskie i wszystkie inne naleza do wykonawcy, zamawiajacy nie ma prawa dysponowac dzielem bez zgody wykonawcy. do czasu wyplaty pelnego wynagrodzenia wykonawca ma prawo usunac wczesniej przekazane dzielo w stanie w jakim ono jest w dniu skasowania. do czasu zaplaty pelnego wynagrodzenia zamawiajacy nie ma prawa do samodzielnego dysponowania dzielem oraz na zadanie powinien w terminie 24h dzielo usunac z serwera, tak aby nie bylo ono dostepne w internecie. tak na wszelki wypadek jak by zmienili hasla na ftp.wiem, temat rzeka. mozna sie zastanawiac po co to miec, po sadach sie ciagac potem? nigdy nie wiadomo. lepiej nosic niz sie prosic - lepiej miec, niz potem zalowac. to jest kilka podpunktow w umowie dajacych oparcie prawne przed podpisaniem umowy oraz w razie problemow wieksze szanse pomyslnego jej zakonczenia. dzieki nim mamy prawo (a nie tylko mozliwosc, co jest istotna roznica) skasowania klientowi strony jesli nie chce placic. mozemy smialo mowic, ze reniferka nie bylo w umowie i jak chce go miec to musi doplacic. a w razie ciagania sie po sadach mozemy spokojnym krokiem wejsc na sale rozpraw ;)oczywiscie sa to tylko luzne uwagi, a nie gotowe do wstawienia paragrafy. uwagi majace na celu li tylko pokazanie potencjalnych problemow jakie moga sie pojawic oraz jak moze wygladac przykladowe ich unikniecie poprzez odpowiedni zapis w umowie. to, ze umowy nalezy czytac ze zrozumieniem jest chyba oczywiste. inaczej moze sie okazac, ze zrobilismy komus strone za free :)

Autor wpisu: m1chu, dodany: 13.10.2009 22:23, tagi: css, php

Gotowe wyrażenia regularne

W pewnym stadium zaawansowania wyrażenia regularne stają się potężnym narzędziem każdego programisty PHP (i nie tylko). A to dlatego, że pozwalają na wykonywanie operacji, których często nie sposób dokonać w prosty sposób przy pomocy standardowych funkcji zawartych w tym języku. Walidacja zawartości zmiennych, czy podmienianie specyficznej części ich zawartości - na to pozwalają wyrażenia regularne. 15-ście przykładowych, najbardziej niezbędnych dla każdego web developera, skompletowałem w dalszej części artykułu. Do Waszej dyspozycji oddaję także prosty serwis sprawdzający poprawność wprowadzanych wzorców.

1. Walidacja adresu e-mail opartego na hoście

Wzorzec:

PLAIN TEXT CODE:
  1. /^([a-z0-9]{1})([^\s\t\.@]*)((\.[^\s\t\.@]+)*)@([a-z0-9]{1})((([a-z0-9-]*[-]{2})|([a-z0-9])*|([a-z0-9-]*[-]{1}[a-z0-9]+))*)((\.[a-z0-9](([a-z0-9-]*[-]{2})|([a-z0-9]*)|([a-z0-9-]*[-]{1}[a-z0-9]+))+)*)\.([a-z0-9]{2,6})([.]?)$/Diu

Opis:

Wyrażenie ma za zadanie sprawdzać, czy wprowadzony przez użytkownika adres e-mail ma poprawną formę. Aby test zakończył się sukcesem muszą zostać spełnione następujące warunki:

  • nazwa użytkownika musi zaczynać się od znaku litery lub cyfry, nie może zawierać spacji, tabulatorów, aty, za to mogą się znajdować w nim kropki, pod warunkiem, że nie występują jedna, po drugiej,
  • po nazwie użytkownika musi pojawiać się znak małpy,
  • domena, podobnie jak nazwa użytkownika, musi rozpoczynać się od litery, bądź cyfry, po czym do znaków dozwolonych dochodzą - oraz ., pod warunkiem, że pierwszy z wcześniej wymienionych znaków nie znajduje się na początku lub na końcu nazwy subdomeny (wyjątkiem są dwa myślniki na jej końcu odpowiadające często prefiksom xn--), a drugi nie jest poprzedzany swoim odpowiednikiem. TLD może mieć długość od dwóch do sześciu znaków,
  • domena może być zakończona kropką,
  • rozwiązanie nie sprawdza jak długi jest wprowadzony adres e-mail.

Strona testowa:

Tutaj.

Tekst spełniający warunki:

2.a_a-d@n-do.x-d.pl

Tekst nie spełniający warunków:

2.a_a-d@n-do.x-d.v-.pl (część domeny kończąca się nieprawidłowym znakiem)

Uwagi:

Jeżeli rozwiązanie w jakimkolwiek stopniu zawiedzie można pokusić się o użycie wyrażenia z ostatniej aktualizacji pliku logical_filters.c ze źródeł PHP.

Rozwiązanie oparte o wyrażenie regularne:

PLAIN TEXT PHP:
  1. $email = trim('adres@domena.pl');
  2. if ( !preg_match('/^([a-z0-9]{1})([^\s\t\.@]*)((\.[^\s\t\.@]+)*)@([a-z0-9]{1})((([a-z0-9-]*[-]{2})|([a-z0-9])*|([a-z0-9-]*[-]{1}[a-z0-9]+))*)((\.[a-z0-9](([a-z0-9-]*[-]{2})|([a-z0-9]*)|([a-z0-9-]*[-]{1}[a-z0-9]+))+)*)\.([a-z0-9]{2,6})([.]?)$/Diu', $email) )
  3. {
  4.     print 'Nieprawidłowy adres e-mail';
  5. }

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

Autor wpisu: cojack, dodany: 09.10.2009 18:11, tagi: php

Od jakiegoś czasu jak sobie przeglądam różne fora, cały czas widzę że ludzie mają problemy z kodowaniem na stronie, a to nie widzą co jest tego przyczyną, a to znowu ustawiają kodowanie w nagłówku html inne niż w pliku, a to do bazy danych podczas połączenia zapominają ustawić kodowania znaków. Jest to trochę smutne a rzecz jest tak prosta, że mógłbym rzec trywialna. Co należy zrobić by tego uniknąć.

Kodowanie w pliku

I tutaj chciałbym Wam wszystkim powiedzieć że iso-8859-2 nie jest standardem kodowania, tak nie jest! Są dwa standardy kodowania pliku, jeden to iso-8859-1 a drugi to mój ulubiony utf-8. O każdym z nich możecie sobie przeczytać na wiki. Jeżeli pracujecie na systemach z rodziny windows, to od razu Wam współczuje, ponieważ słabe edytory plików są ustawione defaultowo na kodowanie windowsowkie czyli cp 1250, co jest bardzo złym podejściem dla programistów, oraz złym nawykiem jeżeli się do tego przyzwyczaimy. Ci którzy pracują na linuxie, mogą sobie darować resztę tego paragrafu ponieważ u nas domyślnie wszystko jest w utf-8 (wyjątkiem od tej reguły jest slackware), ale co tam.

O co chodzi, dajmy na to że używamy notatnika do edycji plików php czy html. W nagłówku head ustawiamy kodowanie strony np dla iso-8859-2, zapisujemy, przeglądamy treść i co? I błędy! Tak Polskie znaki diakrytyczne (mowa o znakach alfabetu z ogonkami) są w postaci tzw. krzaków. Spowodowane jest to tym iż plik jest zapisany w formacie cp 1250 (czyli windowsowskim). Nie pamiętam w tej chwili czy notatnik pozwala nam na zmianę kodowania, ale wydaję mi się że nie, i w cale bym się nie zdziwił gdyby tak było.

Co należy zrobić, otóż sprawa jest prosta, pobrać jakiś edytor tekstu, który pozwala nam na zmianę formatu zapisu pliku, jednym który znam, oraz w pełni darmowym jest Notepad++, pewnie nie jeden z Was już o nim słyszał lub go używa. Nie będę nikogo nakłaniał na żadne z IDE, ponieważ DE ma pomagać a nie przeszkadzać a początkującemu programiście może utrudniać życie. Wracając do Notepad++, ustawiamy w nim kodowanie na UTF-8, ustawiamy w nagłówku dokumentu html charset również na utf-8 i odświeżamy stronę. Proszę jak ładnie wyglądają teraz nasze Polskie literki.

Kodowanie bazy danych

W komentarz pewnie zostanę zlinczowany za to co tutaj napiszę, ale to mój blog i mogę sobie pisać co chce ;] A więc nawiązując do powyższego paragrafu, w dalszym ciągu będę się upierał przy kodowaniu w UTF-8, sprawa ma się tak iż dostępnych mamy b.dużo baz danych, a hostingi przeważnie udostępniają nam jedną w porywach do dwóch typów baz danych są nimi MySQL oraz PostgreSQL. Co do drugiej sprawa ma się krótko, defaultowo kodowanie ustawione na utf-8, sprawa zamknięta, ale że Postgres w naszym kraju jest jakimś małym procentem (nie wiadomo czemu), przejdźmy do MySQL. Przykładowy kod do utworzenia tabeli w bazie danych.

CREATE TABLE `users` (
  `id` int(4) NOT NULL AUTO_INCREMENT,
  `slogin` varchar(128),
  `shaslo` varchar(32),
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Jak widać po zamknięciu definicji kolumn w tabeli, mamy ustawiony typ tabeli na InnoDB oraz ustawiony domyślny typ zapisu danych do bazy na kodowanie utf-8, i na samym końcu o ile ma być zwiększany id przy nowym rekordzie.

Gdybyśmy się pozbyli wpisu dotyczącego CHARSET, najprawdopodobniej domyślnym kodowaniem zostałby iso-1, tak 1 nie 2. A my gupie polaczki jedziemy ostrona na 2 jakby to było spełnieniem naszych marzeń. NIE! I jeszcze raz nie! Tak jak pisałem wyżej Standardami są iso-1 oraz utf-8.

Następnym krokiem jest ustawienie typu kodowania podczas połączenia się z bazą danych, zróbmy tak:

$link = mysql_connect('host', 'user', 'password');
$charset = mysql_client_encoding($link);
if ( $charset != 'utf8' ) {
  mysql_set_charset('utf8',$link);
}

Co tutaj robimy, łączymy się z bazą danych w najprostszy z możliwych sposobów, pobieramy kodowanie bazy danych, jeżeli jest inne niż utf8, ustawiamy je na właśnie ten typ kodowania. Wymagania co do komendy mysql_set_charset, manual przedstawia nam: mysql >= 5.0.7, oraz jednoznacznie jest napisane że SET NAMES nie powinno się wykonywać poprzez mysql_query, przykład:

$result = mysql_query("set names 'utf8'";);

Dobrym też nawykiem, bynajmniej dla mnie jest też stosowanie htmlspecialchars (oczywiście z utf-8 i ENT_QUOTES) przy zapisie danych do bazy, powoduje to konwersję znaków na encje, przy czym kodowanie tego typu znaków nie powinno się burzyć. Kolejnym dobrym nawykiem podczas walidacji danych z formularza powinno być z Waszej strony sprawdzanie typu kodowania znaków przesyłanych przez formularz do Waszego skryptu, poprzez mb_check_encoding, używamy:

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

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