Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: bastard13, dodany: 31.01.2012 10:35, tagi: oop

I'm Object almighty!

Czym jest boski obiekt? Najkrótsza odpowiedź na to pytanie jest zarazem chyba najlepszą: jest wszystkim, odpowiada za wszystko. I choć może wydawać się, że stworzenie takiego bytu jest naprawdę trudne, to rzeczywistość udowodniała mi wiele razy, że aplikacje zawierają pełno tego typu tworów.Czytaj więcej »

Autor wpisu: Load, dodany: 30.01.2012 12:35, tagi: php, framework, zend_framework

Wstęp

Od czasu do czasu pomiędzy obszernymi wpisami będą się pojawiać tz. mini wpisy których treść nie nadaje się na cały wpis, a informacje w nich zawarte są dość użyteczne i nie chciał bym ich wykładać poza kurs. Ten wpis będzie pierwszym takim mini wpisem, w tytule będę podawać pomiędzy jakimi wpisami został opublikowany z racji na inną numerację. ;-)

Konfiguracja wyświetlania błędów w Zend Framework

Miejscem w jakim ustalamy czy Zend ma nas informować o szczegółach błędów jest plik .htaccess w katalogu public każdego projektu, jego standardwa zawartość to:

RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ – [NC,L] RewriteRule ^.*$ index.php [NC,L]

Jak widać są to zwykłe regułki .htaccess, przed nimi mamy pustą linię wpisując w niej:

SetEnv APPLICATION_ENV development

Mówimy naszej aplikacji, że pracujemy w trybie deweloperskim dzięki czemu wyświetlanie błędów zostanie uruchomione, aplikacja posiada również inne tryby w jakich może pracować, wszystko jest opisane w plikach konfiguracyjnych, podam przykład by wyjaśnić na czym to polega, plik z projketu użytego w ostatniej części kursu (#03):

H:\zf\application\configs\application.ini

I jego zawartość:

[production] phpSettings.display_startup_errors = 0 phpSettings.display_errors = 0 includePaths.library = APPLICATION_PATH „/../library” bootstrap.path = APPLICATION_PATH „/Bootstrap.php” bootstrap.class = „Bootstrap” appnamespace = „Application” resources.frontController.controllerDirectory = APPLICATION_PATH „/controllers” resources.frontController.params.displayExceptions = 0

[staging : production]

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

Autor wpisu: Load, dodany: 29.01.2012 22:58, tagi: php, zend_framework

Wstęp

W tym wpisie dowiemy się jak dodawać i usuwać kontrolery i akcje dwoma sposobami „ręcznie” i za pomocą pliku zf.bat, zabieramy się do roboty bez zbędnego gadania.

Tworzymy aplikację testową

Dlaczego kolejną? Nie chcę by kolejne zmiany były wprowadzane na jednym projekcie spowodowało by to zamieszanie więc za każdym razem będziemy tworzyć nowy projekt najlepiej w czystym katalogu www, czyli wypadało by przenieść jego zawartość do innego miejsca tak by nie pomieszać wszystkiego i mieć do czego wrócić w razie niepewności.

Ostatni wpis nadał tak na prawdę całemu kursowi pewien schemat katalogów idę za obietnicą i będę się go trzymać!

W roli przypomnienia dodam, że mój server jest skonfigurowany w następujący sposób, katalog www/public jest głównym katalogiem servera, nowy projekt tworzę w pustym katalogu www, a katalog public jest generowany przy tworzeniu nowego projektu.

Odpalamy cmd, wchodzimy do katalogu www (chyba, że wedle mojej rady mamy plik do odpalania cmd – wtedy mamy jedną komendę z głowy), tworzymy nowy projekt używając znanej nam już komendy z małą zmianą:

zf create project . ZF#o3

Tak komenda tak jak i jej pierwowzór stworzy nam nowy projekt, a od poprzedniczki różni się tylko lokalizacją w jakim zostanie umieszczony, mianowicie nowy projekt pojawi się w katalogu aktualnie wybranym, dzięki czemu efekty stworzenia nowego projektu możemy podziwiać od razu pod adresem lokalnej maszyny w moim przypadku zf.server.

Tworzenie kontrolerów

Nasza aplikacja jak wiecie z poprzedniej części już na strat posiada dwa kontrolery:

  • index
  • error

A w niech odpowiednie akcje, teraz zajmiemy się stworzeniem nowego kontrolera tak by dołączył do tej dwójki, są na to dwa sposoby przedstawione poniżej.

zf.bat

By stworzyć nowy kontroler za pomocą pliku zf.bat musimy odpalić cmd i wejść do katalogu projektu, w tym przypadku jest to katalog www i znów przydaje się nasza magia – korzystając z pliku index.bat i stosując kropkę od razu jesteśmy w dobrym miejscu. Tak by operacje na naszym projekcie za pomocą zf.bat powiodły się plik .zfproject.xml powinien znajdować się w głównym folderze aplikacji, zawiera on informacje o projekcie i jest wymagany.

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

Autor wpisu: Vokiel, dodany: 29.01.2012 15:00, tagi: jquery, javascript, css

src: http://http.cdnlayer.com

Ochrona własnego adresu poczty elektronicznej stała się „oczywistą oczywistością”. Niezliczone spam-boty przeczesują Internet w poszukiwaniu adresów email, które później zalewane są falą niechcianej poczty. Niestety często jesteśmy zmuszeni udostępnić swój adres. Wpisany zwykłym tekstem, a tym bardziej dodany do linku z mailto stanie się bardzo szybko łupem spamerów. O ile na formę upublicznienia adresu w obcych serwisach zwykle nie mamy wpływu, o tyle mamy w przypadku własnych. Jako, że potrzeba jest matką wynalazku, postanowiłem stworzyć własne rozwiązanie. Połączenie CSS i JavaScript przyniosło oczekiwany skutek.

Założenia protectEmails

Tworząc założenia starałem się patrzeć na problem możliwie z wielu stron. Najważniejszymi punktami są:

  1. Czytelność dla użytkownika końcowego
  2. Ochrona przed podstawowymi mechanizmami spam-botów
  3. Łatwość modyfikacji wyglądu
  4. Prostota w stosowaniu

Czytelność dla użytkownika końcowego

Przede wszystkim chciałem uniknąć rozwiązań typu info [at] example.com, które poza tym, że już dawno nie chronią przed botami, to dodatkowo są męczące dla użytkowników. Wszystkie odmiany tego rozwiązania charakteryzują się tą samą trudnością w pozyskaniu maila przez odwiedzającego stronę – podmiana fragmentów, łatwość pomyłki. Tworząc swoje rozwiązanie, chciałem, aby adres email był widoczny w zwykłej formie, po prostu jako info@example.com.

Dodatkowo, uważam, że ważne jest też zachowanie standardowej funkcjonalności linku, który otwiera domyślny program pocztowy klienta.

Ochrona przed podstawowymi mechanizmami spam-botów

Rozwiązanie musi być w jakiś sposób unikatowe, tak aby standardowe funkcje spamerów nie były w stanie takiego adresu wyłuskać. Oczywiście, nie da się zabezpieczyć w 100%, zawsze znajdzie się ktoś, kto napisze dedykowane rozwiązanie. Jednak dużą część automatów można wyeliminować.

Poszukując gotowych rozwiązań spotkałem się z dużą ilością pseudo-zabezpieczeń. Nie dość, że utrudniają one życie użytkownikom, to dodatkowo wystawiają adresy na pastwę botów, np.:

<a href="mailto:info@example.com">info [ at ] example.com</a>
<a href="mailto:info@example.com">info [ at ] example [dot] com</a>

Lub po prostu utrudniają życie, np.:

<span class="email">info [ at ] example [dot] com</spam>

W przypadku powyższego istnieją rozwiązania oparte na JavaScript, które na podstawie klasy modyfikują znacznik span, przerabiając go na klikalny adres email. Jest to dość dobre rozwiązanie z jednym mankamentem – adres jest czytelny dla botów.

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

Autor wpisu: zleek, dodany: 27.01.2012 12:27, tagi: php

Nawiązując do wpisu, który zamieściłem wcześniej o przekazywaniu zmieninnych pomiędzy testami, chciałem przedstawić krótką instrukcję dotyczącą wykonywania różnych funkcjonalności przed i po testach. Metody setUp() i tearDown() Metody te służą do wywołania odpowiednich funkcjonalności w sytuacji, gdy chcemy aby były one wywołane odpowiednio przed testami i po nich. Metoda setUp() może być więc wykorzystana do [...]

Autor wpisu: Wojciech Sznapka, dodany: 25.01.2012 19:10, tagi: php, symfony

In my previous post Modern framework comparison I presented performance tests, which compared Ruby On Rails, Django and Symfony2. After recieving a feedback in comments I decided to run this benchmark one more time on my own laptop (instead of on my hosting). The reason was simple: enviroment was outdated. I installed mod_python and configured [...]

Autor wpisu: singles, dodany: 23.01.2012 23:53, tagi: php

Mikrostrona w mikroczasie w mikroframeworku.

21 stycznia 2012 roku odbyło się kolejne spotkanie z serii meet.php, a ja miałem okazje poprowadzić na nim prezentację na temat mikroframeworków – na bazie SlimFramework.

Wprowadzenie

Mikroframeworki, w przyciwieństwie do tzw. full-stack frameworków udostępniają najczęściej minimum funkcjonalności potrzebnej do zbudowania prostej strony internetowej (celowo nie używam słowa aplikacja). Zawierają najczesciej mechanizm routingu i prosty system szablonów, obsługę sesji i cookies. Resztę, w razie potrzeby możemy dodać sobie sami.

W poniższej prezentacji (gdyby się nie wyświetlała, wyłączenie AdBlocka powinno pomóc) zawarte są kody źródłowe, które pokazują, jak łątwo osiągnąć niektóre funkcjonalności w narzędziu tego typu.

Micropage in microtime using microframework View more presentations from Radosław Benkel

To samo co wcześniej, tylko na SpeakerDeck.

Podusmowanie

Uważam, że mikroframework nadaje się idealnie do prostej strony internetowej, a przy dobrze zaprojektowanej warstwie modelu mogą także służyć jako lekkie RESTowe API – dodajemy autoryzację i uwierzytelnianie jako middleware, a logikę biznesową i tak trzymamy po stronie modelu. W przypadku Slima, jak nie pasuje nam domyślny system szablonów, bardzo łąwto możemy podpiąc inny – dla najpopularniejszych są dostępne gotowe klasy.

Od siebie dodam tylko, że na Slimie zrobiłem dwa małe projekty, teraz najpewniej będę robił trzeci. I absolutnie nie żałuję godziny czasu poświeconego na zapoznanie się z dokumentacją :)

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