W czwartek 6 czerwca 2013 o 16:15 na Uniwersytecie Marii Curie – Skłodowskiej, już po raz drugi będę miał przyjemność poprowadzić wykład w ramach projektu: „Zdobądź wiedzę z Performance Media”. Temat mojegowykładu nie uległ zmianie, wprowadziłem jedynie drobne zmiany / poprawki w samej prezentacji: „Ewolucja projektowania aplikacji w PHP na bazie frameworka Symfony2″.

Dla przypomnienia poniżej znajduje się krótka agenda:

• Ewolucja PHP. Krótka historia, ekosystem, co nowego w PHP?
• Dlaczego Symfony2? Przegląd najważniejszych i najciekawszych możliwości frameworka;
• Symfony2 w praktyce. Mini przegląd popularnych Bundli + CMS w 5 minut.

Wszystkich zainteresowanych tematem PHP / Symfony2 serdecznie zapraszam!

Więcej informacji na temat samych wykładów można znaleźć na stronie: Wykłady Performance Media

zp8497586rq

Nawigacja

• Wprowadzenie
• Przygotowanie środowiska i instalacja
• Routing
• Widoki 1/2 (Tu jesteś)

Laravel, widoki

Witaj w kolejnej części kursu Laravel. W ostatnim wpisie pokazałem Ci podstawy routingu oraz starałem się wytłumaczyć co to w ogóle jest ten routing. W dzisiejszej części wytłumaczę czym są widoki, dlaczego powinieneś ich używać oraz jakie dają Ci korzyści. Pokaże to na przykładzie małej aplikacji, którą napiszę w trakcie przedstawiania kolejnych części frameworka Laravel. Jaką aplikację przedstawię? Niestety nie wprowadziłem jeszcze chociażby bazy danych więc pole do popisu jest zawężone. Pomyślałem, że napiszę aplikację pozwalającą na szybkie skrócenie adresu URL. Przy okazji pokażę też jak zainstalować dodatkowe pakiety przez composer. Zaczynajmy!

Czysty projekt

Na początek będziemy potrzebować utworzyć nowy projekt. Jeśli nie pamiętasz jak to zrobić, wróć po prostu do jednego z poprzednich plików. Ja już to zrobiłem i mój projekt leży w katalogu ~/Documents/secondProject. Na razie jest całkowicie defaultowy. Jeśli i Ty już masz czysty projekt: przejdźmy do zastanowienia się jak będzie wyglądał nasz skracacz linków.

Projektowanie aplikacji

Nazwa nagłówka jest trochę na wyrost, ale nieważne. Zacznijmy od zaprojektowania interfejsu naszej nowej aplikacji, potem będziemy się martwić implementacją. Podaję przykładowy projekt interfejsu. Widać, że jest tylko jedna funkcja, która ma działać. Będziemy używać widoków, a więc na początek pokrótce napiszę czym są widoki. Widoki to nic innego jak pliki .php, które składają się głównie z kodu html. Na szczęście do tych plików można dodawać zmienne, pętle itd. W Laravel istnieje silnik szablonów nazywający się Blade. Posiada on bardzo prostą składnie:

// Wyświetlenie zmiennej

{{ $zmienna }}

// Wyświetlenie zmiennej escape'ując (??;D) znaki specjalne

{{{ $zmienna }}}

// Wyświetlenie zmiennej jeśli jest ustawiona, jeśli nie, tekst alternatywny

@if (isset($zmienna))

{{$zmienna}}

@else
Zmienna nie jest ustawiona
@endif

// Pętla foreach, analogicznie while i for

@foreach ($zmienna as $i)

{{$i}}

@endforeach

// Wczytanie innego szablonu

@include('nazwaszablonu')

System szablonów Blade posiada jeszcze kilka bardzo fajnych opcji, o których powiem potem. Na początek warto wiedzieć, że pliki z szablonami zapisujemy w katalogu app/views/. Stwórzmy sobie przykładowy widok:

<meta charset="utf-8" />Nauka widoków</pre>
<h1>Mój pierwszy szablon</h1>
<pre>

Zapisz taki plik w katalogu app/views pod nazwą na przykład index.blade.php (to jest wymagane rozszerzenie, blade.php. Teraz przypomnij sobie lekcję o route’ach, zrobimy tak, aby dla strony głównej wyrenderował (wyświetlił) się nasz nowo utworzony widok. Do tego istnieje konstrukcja return View::make(‚nazwa_widoku’).

Route::get('/', function(){

return View::make('index'); // jeśli plik się nazywa index.blade.php

});

Nie podajemy rozszerzenia! Poza tym jeśli mielibyśmy w views podkatalog, to rozłączamy podkatalogi kropką. Na przykład jeśli ścieżka do pliku widoku byłaby: app/views/blog/index.blade.php – to podajemy w kodzie:

return View::make('blog.index');

To na prawdę proste i intuicyjne, szybko przywykniesz. Wyrenderuj więc nasz pierwszy widok. Powinieneś zobaczyć po prostu ten kod HTML (wyrenderowany przez przeglądarkę). Oczywiście zrobisz to poprzez wejście w przeglądarce na katalog główny projektu.

Kolejną ważną rzeczą jaką warto wiedzieć o widokach są parametry do nich przekazywane. Spójrz na poniższy kod:

// app/route.php

Route::get('/', function(){

$some_var = "blablabla";

return View::make('index', ['name' => $some_var ]);

});

// app/views/index.blade.php</pre>
<h1>{{ $name }}</h1>
<pre>

Nie jest zbyt trudno odgadnąć co robi dany kod. Po prostu przekazujemy do widoku zmienną (której to zmiennej możemy zmienić nazwę). Zasada jest taka, że w tablicy jako klucz występuje nazwa, pod jaką będzie widziana zmienna w widoku, a jako wartość -> ta właśnie zmienna. Możemy przekazywać więcej niż jedną zmienną po prostu dodając do tablicy kolejne pary klucz->wartość.

Masz teraz podstawowe pojęcie o widokach. Kończę teraz pierwszą część tego wpisu, zostawiając Cię z zadaniem zaprojektowania widoków dla aplikacji, której projekt podałem na screenshotach. W części drugiej dodamy do aplikacji silnik! Serdecznie zapraszam w sobotę!

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

Zwiń
Czytaj na blogu autora...

Posiadając wersje językowe na stronie internetowej jesteśmy zobowiązani do stworzenia mechanizmu tłumaczenia tekstów (przeważnie stałych, bo pozostałe wprowadzimy korzystając z CMS), które występują na witrynie. Jednym z rozwiązań, który dzisiaj omówię, jest wykorzystanie...

Nawigacja

• Wprowadzenie (Tu jesteś)
• Przygotowanie środowiska i instalacja

Na wstępie pragnąłbym zaznaczyć, że jest to tylko pierwszy wpis, mam nadzieję cotygodniowej serii wprowadzającej do frameworka Laravel.

Jako, że tak na prawdę jest to mój początek z blogowaniem i pisaniem czegokolwiek innego niż kod, maile, wypracowania w czasach liceum lub <160 znakowe wiadomości na blipie czy innym twitterze. Tylko nie przypominajcie mi o moim poprzednim blogu. Powiedzieć, że jestem niezadowolony z jego wartości merytorycznej to za mało.

Pozwolę sobie zarzucić sucharem rozluźniającym atmosferę:

A SQL query goes into a bar, walks up to two tables and asks, „Can I join you?”  

Czas jednak przejść do rzeczy, mianowicie czym będzie, a raczej czym chcę aby była ta seria. Moim celem jest napisanie kompletnego wprowadzenia do frameworku Laravel,  nauczenie kogoś, kto zna PHP tylko w podstawowym stopniu. O MVC coś tylko słyszał (lub nawet nie). Nie będzie to seria wpisów przydatna dla kogoś, kto od 2 lat pisze w Symfony lub kogoś kto choć raz w życiu pisał swój własny framework. Najbardziej chciałbym aby tą serią zainteresowały się osoby całkowicie nowe w świecie programowania, które obrały PHP jako coś czego chcą się uczyć. Zależałoby mi też na osobach, które nawet zarabiają na pisaniu kodu jednak nie są świadome możliwości jakie dają im frameworki, biblioteki, dobre praktyki.

Pozwolę sobie zwracać się do czytelnika, jakby był bardzo początkujący. Proszę przy okazji osoby, które są bardziej doświadczone, aby nie czuły się obrażone.

„Czemu miałbym się uczyć Laravel skoro…co to jest w ogóle framework?!”

Wyobraź sobie, że jesteś freelancerem przyjmującym zlecenia na tworzenie różnych prostych stron oraz bardziej zaawansowanych aplikacji internetowych. Nie stronisz także od poprawek w istniejących serwisach. Czemu miałbyś je odrzucać, przecież to duża część rynku.  Dostajesz maila z powiedzmy taką treścią:

Witam, jestem właścicielem małej firmy, w której pracuje 5 osób. Wszystkie te osoby siedzą w jednym biurze. Lwią częścią ich pracy jest rozmowa przez telefon oraz praca w excelu. Ważnym szczegółem jest jednak to, że zbiory zewnętrznych rozmówców pracowników nachodzą na siebie. Innymi słowy pracownicy często rozmawiają z osobami, do których wcześniej dzwonił, któryś z współpracowników. Klienci często są bardzo specyficzni i potrzebują specjalnej opieki (nie troski). Na jednego na przykład nie wolno w ogóle krzyczeć ponieważ jego lekarz twierdzi, że może to spowodować u niego zawał, inny w ogóle nie odbiera telefonów przed 14. Jeszcze inny chce rozmawiać tylko z kobietami. Są też tacy, którzy wymagają włączenia im rosyjskiego hymnu zanim się w ogóle można przywitać.

Obecnie w mojej firmie funkcjonuje aplikacja zainstalowana na wewnętrznym firmowym serwerze, gdzie każdy klient ma swoją podstronę z tekstem, który opisuje zasady rozmowy z nim. Niestety (dla mojego portfela wprost przeciwnie) w ostatnim roku baza naszych stałych klientów zwiększyła się z 2 aż do 400. Można sobie tylko wyobrazić jak to wpłynęło na przydatność owego rozwiązania (aplikacji). Pracownicy zaczęli się przerzucać na żółte karteczki. Dziś przyjeżdża kolejna ciężarówka z dostawą karteczek – mówię Panu, te karteczki śnią mi się już po nocach, chcę z tym skończyć!

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

Zwiń
Czytaj na blogu autora...

Dzisiejszy wpis jest tym z rodzaju błahych, ale nie do końca. Często zapominamy, że przeniesienie słowa z życia codziennego (w tym wypadku: float) do świata maszyn nie zawsze jest właściwe.

Często w projektach, w których uczestniczę projektowanie bazy danych oddaje się w ręce niedoświadczonych osób. Bo dlaczego nie może jej zaprojektować osoba, która będzie tworzyła logikę w aplikacji do niej?

Zaprojektować owszem – może, ale często osoba odpowiedzialna za część programistyczną aplikacji ma nikłe pojęcie o projektowaniu bazy, a szczególnie dostępnych typach, procedurach itp.

INT(10) != VARCHAR(10)

Szczególnie studenci i osoby z firm, gdzie wyznaje się zasadę „człowiek-orkiestra” popełniają ten błąd. Korzystając z typu VARCHAR i podając jego wielkość (10) sądzą, że tak samo można ograniczyć wielkość (długość) pól liczbowych, np. INT.

Tym bardziej powielają ten błąd, gdy silnik bazodanowy podczas tworzenia tabeli nie zwraca błędu. Zapis INT(10) jest poprawny, ale nie powoduje on, że ograniczymy INT do 10 miejsc (pomijam fakt, że niektórzy sądzą, że podając INT(18) przeskoczą definicję długości samego INT-a). Z założenia zapis INT(X) powinien iść w parze z opcją ZEROFILL. Konstrukcja:

CREATE TABLE `codes` (

`code` INT(5) ZEROFILL COMMENT 'kod, ktory zostanie dopełniony zerami'

)

To spowoduje, że gdy dodamy kod o wartości 1, to wynik zapytania zwróci nam 00001 (czyli cyfrę 1 uzupełnioną do 5 miejsc zerami – ZEROFILL). I tylko dlatego istnieje zapis INT(X), a nie z powodu ograniczenia długości pola danego typu numerycznego. Od tego mamy masę aliasów (jak SMALLINT czy TINYINT).

FLOAT czy DECIMAL/INT?

Jedną sprawę mamy wyjaśnioną. Teraz poważniejsza sprawa, która wpływa na wyniki zapytań bazy danych. Raz na jakiś czas zdarza mi się zetknąć z kodem, gdzie kwoty z faktur, rachunków są umieszczane w polach typu FLOAT. Wydaje mi się, że autorów takich konstrukcji popycha posługiwanie się tłumaczeniem FLOAT na język polski jako liczba zmiennoprzecinkowa. Człowiek widzi hasło „liczba … przecinkowa” i sądzi, że służy do zapisu ogólnie pojętych cen. Dlatego lepiej odwołać się do angielskich definicji, które moim zdaniem są jaśniejsze: float jest to liczba aproksymowana, czyli przybliżona. A najlepiej posłużyć się przykładem. Utwórzmy tabelę:

CREATE TABLE `invoice_record` (

`price` FLOAT NOT NULL

)

Następnie umieśćmy w niej dane z wartościami po przecinku, np. kwotę „29.99„. Cała operacja się powiedzie, a zapytanie SELECT zwróci nam odpowiednie wyniki. Oto nam chodziło. Na pewno?

W przypadku, gdy będziemy chcieli uzyskać faktury, które mają pozycje z ceną ”29.99” lub są większe równe to nie zobaczymy żadnych wyników. Dlaczego? Ponieważ jest to liczba zmiennoprzecinkowa, a prościej nieprecyzyjna. Nasze „29.99” wygląda tak naprawdę tak:

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

Zwiń
Czytaj na blogu autora...

Na jednym z forów trafiłam na świetną prezentację na temat programowania w PHP, w której autor podejmuje się pokazać różnice między programowaniem w PHP a klepaniem kodu nazwanym przez niego PHPowaniem. Błądzić jest rzeczą ludzką, ale najważniejsze by się umieć krytycznie przyjrzeć sobie. Na szczęście stać mnie na to, więc się sobie przyglądam. Od kilku [...] No related posts.

Ostatni projekt w Kohana napisałam chyba wieki temu. Wprawdzie pokusiłam się wtedy o użycie wersji 3 i nawet mi się spodobało wiele ze zmian jakie wprowadzono, w stosunku do wersji 2. Tyle, że po za użyciem wersji 3 nie pokusiłam się o pełne wykorzystanie jej możliwości. A mianowicie tego że obsługuje ona model HMVC. Nie [...] No related posts.