Mamy święta i dużo wolnego czasu, dlatego dzisiaj będziemy zajmować się modułem Zend Framework odpowiedzialnym za czas – Zend_Date. Proponuję przeczytać moje gryzmoły zamiast objadać się nadmiernie karpiem czy co tam macie. Dodatkowo zahaczymy o Zend_Config w postaci odczytu, modyfikacji i zapisu nowych danych do pliku .ini.

Będziemy robić moduł odpowiedzialny za automatyczne usuwanie dawno otwartych (a zatem niepotrzebnych) jakichś plików na serwerze. Mogłyby to być pliki miniaturek obrazków, które kiedyś nam system wygenerował i są już niepotrzebne.

Domyślnie każda aplikacja w ZF ma plik konfiguracyjny application.ini zapisany w /application/configs/. Dla naszych celów założymy sobie plik thumbs.ini, który będziemy mordować czytaj: ciągle nadpisywać. W pliku zapiszemy sobie 4 linijki:

[production]
cleanafter = "Dec 25, 2010 6:26:09 PM"
checkinterval = "5"
intervalunit = "MINUTE"

Wyraz w nawiasie oznacza środowisko, w którym pracujemy, cleanafter to data zapisana w formacie DATETIME. Checkinterval i intervalunit to zmienne służące nam do wygenerowania nowej daty cleanafter.

Kod, który podam poniżej można sobie zapisać w jakimś kontrolerze albo jako plugin.

// ważne jest ustawienie opcji 'allowModifications' na true,
// bo inaczej konfiguracja będzie w trybie tylko do odczytu
$config = new Zend_Config_Ini(ROOT_DIR.'/application/configs/thumbs.ini','production',
   array('allowModifications' => true));
// konstruujemy obiekt Zend_Date na podstawie danych z
// konfiguracji i podajemy format, w jakim dostarczymy dane nt. daty
$cleanAfter = new Zend_Date($config->cleanafter, Zend_Date::DATETIME);
// jeżeli nic nie podamy to Zend weźmie sobie datę i czas obecny
$currentDate = new Zend_Date();
// bardzo fajna funkcja isEarlier() porównująca daty
if ($cleanAfter->isEarlier($currentDate)) {
   echo 'coś robię';
   // wyznaczamy nową datę do wpisania do konfiguracji;
   // myślę, że sklonowanie obiektu daty powoduje trochę mniejszy
   // narzut zasobów niż tworzenie od nowa obiektu
   $newCleanDate = clone $currentDate;
   // dodajemy datę; funkcja add() ma 2 argumenty: ile dodać i co dodać;
   $newCleanDate->add(
      $config->checkinterval,
      constant('Zend_Date::' . $config->intervalunit)
      );
   // przypisujemy do configa datę w formacie DATETIME
   $config->cleanafter = $newCleanDate->get(Zend_Date::DATETIME);
   // tworzymy obiekt służący do zapisu configów
   $writer = new Zend_Config_Writer_Ini();
   $writer->setConfig($config);
   $writer->setFilename(ROOT_DIR.'/application/configs/thumbs.ini');
   $writer->write();
 
   // przygotowujemy obiekt daty, z którym będziemy
   // porównywać czas ostatniego otwarcia plików
   $deleteOlderThan = clone $currentDate;
   // add() dodawało, sub() odejmuje; my odejmiemy 1 tydzień
   $deleteOlderThan->sub(1, Zend_Date::WEEK);
   // tworzymy iterator podając katalog z miniaturkami do sprawdzenia
   $dirIterator = new DirectoryIterator(APPLICATION_PATH  . '/../public/thumbs');
   foreach ($dirIterator as $file) {
      // $getATime() podaje czas ostatniego otwarcia pliku
      // w formacie TIMESTAMP, z którego skonstruujemy datę
      $fileOpenDate = new Zend_Date($file->getATime(), Zend_Date::TIMESTAMP);
      // jeżeli data ostatniego otwarcia jest wcześniejsza
      // niż przyjęty przez nas limit 1 tygodnia to wywalamy plik
      // wygłuszając ewentualne komunikaty poprzez @
      if ($fileOpenDate->isEarlier($deleteOlderThan)) {
         @unlink($file->getRealPath());
      }
   }
}

Polecam zwrócić uwagę na constant(), który w locie na podstawie nazwy odwoła się do stałej obiektu. Konstrukcja typu ${'jakas' . $zmienna} prawidłowa dla zmiennych nie jest dostępna dla stałych i należy użyć funkcji constant().

A poza tym to Wesołych Świąt

Od czasu do czasu potrzebujemy użyć niestandardowych czcionek w tworzonym projekcie. Nie musimy już przy tym wykorzystywać grafiki w zastępstwie dla tekstu, jak to robiono kiedyś, powodując tym samym niepotrzebny wzrost liczby zapytań do serwera. Dzisiaj mamy biblioteki pokroju sIFR, FLIR czy cufón, a także Web Fonts. W niniejszym wpisie kilka moich przemyśleń nad poszczególnymi [...]

Ekipa odpowiedzialna za Doctrine poinformowała o wydaniu pierwszej stabilnej wersji Doctrine 2. Spośród wszystkich zmian jakie zaszły w projekcie, najważniejszą zdaje się być brak kompatybilności z poprzednią wersją oraz fakt, iż Doctrine 2 działa tylko na PHP 5.3.

Pełną informację na temat zmian znajdziecie na blogu Doctrine. Zachęcam również do zapoznania się z tutorialem oraz dokumentacją.

Ostatnio z przypływu różnych myśli, zacząłem się zastanawiać nad własnym biznesem. Doszedłem do wniosku, że podstawą by odnieść sukces na polu tworzenia jakichkolwiek aplikacji www potrzebne jest posiadanie zestawu narzędzi/środków, dzięki którym będę mógł szybko i sprawnie tworzyć rozwiązania dla klientów. Potrzebny jest więc, framework obudowany własnymi bibliotekami albo kilka gotowych produktów open source, które trzeba będzie modyfikować do własnych potrzeb. Żeby podjąć jakąkolwiek decyzje w tej materii (wyboru rozwiązania) skonstatowałem, że najlepiej będzie zrobić charakterystykę kilku głównych typów aplikacji webowych.

Oto ona (należy kliknąć aby zobaczyć ją w 100% ponieważ niestety nie mieściła się na stronie):

I teraz krótkich kilka słów, co, dlaczego i po co ? Zacznijmy może od opisu poszczególnych kolumn:

• nazwa – przyjęta w branży nazwa charakteryzująca dany typ aplikacji www
• dostawca głównej treści – ta kolumna mówi nam, kto w głównej mierze tworzy „widoczną” treść serwisu
• sprawca działania – typ użytkownika, który głownie powoduje przepływ danych w serwisie
• skomplikowana logika biznesowa – dla wielu może trochę zagadkowa kolumna, mówi ona o tym, czy reguły wg których ma działać nasz kod są jednoznaczne i można je łatwo wtłoczyć w jakieś schematy czy też zawierają dużo wyjątków od głównej reguły i rozgałęzień sterowania
• nakład pracy przy kodowaniu – w pewnym stopniu wynika z poprzedniej kolumny, jest to nakład pracy potrzebny przy stworzeniu danego typu aplikacji od podstaw, ewentualnie przy użyciu popularnego frameworka
• flow – opisuje sposób przepływu zdarzeń na które reaguje aplikacja, zdarzenia mogą być przekazywane przez url, albo przez wywołania webservice’ów różnej maści
• poziomy uprawnień – opisuje jak bardzo aplikacja jest podzielona ze względu na poziomy dostępu użytkowników, czy można zaprojektować ją sztywno dzieląc ją na obszary do których użytkownicy mają dostęp, czy też poszczególne uprawnienia zależą od kontekstu roli użytkownika
• główny problem  - jest to najczęstszy i najdroższy problem, który zwykle pojawia się przy tworzeniu danego rodzaju aplikacji
• standartyzowalność – określa czy można w łatwy sposób stworzyć framework, czy system, dzięki któremu będzie można składać aplikację z „klocków”
• gotowe rozwiązania open source – zawiera informacje, czy istnieją już gotowe i darmowe systemy, których można użyć do tworzenia danego rodzaju aplikacji

Na pewno nie ująłem wszystkich typów aplikacji jakie istnieją. Jednak uważam, że ta tabela daje dobry ogólny pogląd na to, jak się sprawy na rynku mają. Trzeba wziąć też pod uwagę, że na rynku zdarzają się i będą coraz częściej zdarzać się aplikacje, które są miksem jednego lub kilku wymienionych rodzajów aplikacji. Patrząc na wymienione typy stron www nasuwa mi się taka konkluzja, że o ile komponenty potrzebne do budowania ich, w głównej mierze są dość wspólne (od strony widoku i może kontrolera) to każda będzie miała trochę inny charakterystyczny „workflow” działania. Myślę, że takie zestawienie jest dobrą szansą np. dla twórców wszelakich frameworków, które mają różnego rodzaju automatyczne generatory kodu, na przygotowanie kilku bazowych „profili” wg. których tworzona jest podstawowa struktura aplikacji.

Jestem bardzo ciekawy Waszych spostrzeżeń na ten temat, oraz tego czy macie może propozycje na inne rodzaje aplikacji www, i/lub kolumn w tym zestawieniu.

Mieliście kiedyś do pocięcia layout, który był “bogaty” w gradienty? Jeśli tak, to szczerze współczuję. Jest to niewdzięczna robota,  której i tak nikt nie doceni, a przy okazji zmiany identyfikacji graficznej strony trzeba będzie robić wszystko od nowa. Tak się składa, że ostatnio mam dużo cięcia i postanowiłem coś z tym zrobić. W końcu zmniejszenie ilości grafik ładowanych na stronie wyjdzie serwisowi na dobre. Co więcej, do szerszego grona zaczynają docierać takie terminy jak graceful degradation oraz progressive enhancement. IE6 również nie ma łatwego i powoli dokonuje swojego żywota w korporacyjnych gabinetach i bardzo starych komputerach kupionych na komunię.

Na takim właśnie podłożu wykiełkowała we mnie myśl “Może warto w końcu przenieść ciężar prezentacji danych z grafiki na CSS? Przecież po to właśnie powstały.” I w ten oto sposób duży serwis składa się jedynie z około dziesięciu plików graficznych (w tym jeden css sprite) i całkiem zgrabnego pliku CSS. Ale do rzeczy. Styl, dzięki któremu można uzyskać gradient na stronie (również w IE6 – a co tam, niech mają) jest stosunkowo prosty i nie działa jedynie w Operze. Podobno Opera 11 miała już wspierać gradienty, jednak nie udało mi się znaleźć żadnej informacji na ten temat.

Kompletny kod CSS wygląda następująco:

background: #ffffff;
background: -webkit-gradient(linear, left top, right top, from(#000000), to(#ffffff));
background: -moz-linear-gradient(left top, #000000, #ffffff);
filter:progid:DXImageTransform.Microsoft.Gradient(StartColorStr=#FF000000, EndColorStr=#FFffffff, GradientType=1);

Pierwszy wiersz to tzw. fallback cololr, czyli kolor jaki zostanie zastosowany w przeglądarce nieobsługującej gradientów.

Drugim wierszem zadowolimy wszystkie przeglądarki oparte o webkit. W pierwszym parametrze przekazujemy informację o rodzaju gradientu. Następnie musimy zdefiniować pozycję z jakiego miejsca, do jakiego miejsca będzie przechodził gradient. Na sam koniec podajemy kolor początkowy oraz docelowy. Nie są jedyne możliwości webkita, niestety jeśli chcemy zadowolić użytkowników IE nie możemy z nich skorzystać.

Trzeci wiersz działa prawie identycznie jak drugi, z tą różnicą, że dla Firefoxa definiujemy rodzaj gradientu już w nazwie. Następnie podajemy jedynie kolor początkowy i końcowy.

Ostatnim wierszem dodajemy gradienty w IE (testowane na IE6, IE8 oraz IE9). Tutaj nie trzeba raczej tłumaczyć kolejnych parametrów. Wyjaśnienia wymaga jedynie GradientType. Ustawiony na 1 oznacza gradient poziomy, na 0 lub wcale – pionowy.

W przypadku przeglądarek IE warto jeszcze mieć na uwadze, jeden drobny szkopuł. Aby gradient się wyświetlił wymagają ustawienia wysokości.

W poprzedniej części serii zaczęliśmy poznawać kontrolery w wydaniu ASP.NET MVC. Dzisiaj poznamy kolejne możliwości przez nie oferowane. Zaczniemy od filtrów, a dokładniej rzecz ujmując od filtra odpowiedzialnego za obsługę błędów.

Jeśli mieliście styczność z Zend Frameworkiem, na pewno waszej uwadze nie umknął kontroler o nawie Error, który uruchamiany jest za każdym razem, gdy w aplikacji źle się dzieje. W przypadku ASP.NET MVC nie ma domyślnego kontrolera, który obsługuje błędy. Obsługą błędów zajmuje się klasa HandleErrorAttribute. Niestety w przypadku PHP nie ma czegoś takiego jak atrybuty, więc z początku zapis filtrów może wydawać się dziwny. Gwarantuję jednak, że dają one ogromne możliwości.

Korzystanie z obsługi błędów należy rozpocząć od wprowadzenia modyfikacji do pliku konfiguracyjnego web.config. Domyślnie wyświetlanie błędów przy pomocy plików widoku działa na zdalnych maszynach. Innymi słowy my jako programiści widzimy wszystkie robaczki, a użytkownik końcowy tylko ładną informację o problemie. Aby to zmienić w sekcji system.web pliku web.config należy umieścić następujący kod:

<customErrors mode="On"></customErrors>

Jest to najprostsza forma jaką można dodać do pliku konfiguracyjnego. W wersji bardziej rozbudowanej mamy możliwość określenia do jakiego pliku nastąpi przekierowanie w przypadku wystąpienia konkretnego statusu błędu (o pliku web.config napiszę osobny wpis)

Teraz jeśli dodamy do klasy kontrolera filtr [HandleError], nasza aplikacja będzie w stanie wykryć nieobsłużone wyjątki i wyświetlić przygotowany przez nas komunikat błędu. Przykładowy kod kontrolera:

namespace MvcApplication1.Controllers
{
    [HandleError]
    public class HomeController : Controller
    {
        public ActionResult Index()
        {
            return View();
        }
    }
}

Filtr [HandleError] przechwytuje wyjątki i wyświetla widok Error z bieżącego kontrolera (w tym przypadku z kontrolera Home). Jeśli widok nie zostanie odnaleziony, kolejnym przeszukiwanym folderem będzie Shared.

Domyślnym zachowaniem filtra [HandleError] jest przechwytywanie wszystkich wyjątków jakie pojawią się w aplikacji. A co jeśli chcielibyśmy wyświetlać różne komunikaty błędów w zależności od rodzaju wyjątku? Nic prostszego. Wystarczy ustawić właściwości odpowiedzialne za przechwytywanie wyjątków i zwracanie widoku.

Właściwościami tymi są:

• ExceptionType – rodzaj przechwytywanego wyjątku
• View – widok, który zostanie wyrenderowany
• Master – szablon strony wzorcowej
• Order – kolejność z jaką filtry są stosowane

Prosty przykład przechwytywania konkretnego wyjątku oraz wyświetlenie komunikatu błędu innego niż domyślny:

[HandleError(ExceptionType = typeof(IndexOutOfRangeException), View = "AnotherError")]

W przypadku przechwytywania kilku różnych wyjątków należy pamiętać, że filtry dopasowywane są od góry i w momencie napotkania filtra, który może dany wyjątek obsłużyć, dalsze sprawdzanie filtrów zostaje przerwane. Dlatego ważne jest w takich sytuacjach umieszczanie najbardziej szczegółowych filtrów jak najwyżej

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

Zwiń
Czytaj na blogu autora...

Niestety burzliwa końcówka studiów oraz praca uniemożliwia mi zajęcie się Open Power Template'm od strony organizacyjnej, tj. pakowanie tego wszystkiego i wydawanie nowych wersji, jednak prace nad tym systemem cały czas trwają dzięki sprytnemu wykorzystaniu go w moim projekcie inżynierskim. Wersja 2.1 została mocno zdebugowana w ostatnich miesiącach, a dziś chciałbym bliżej przedstawić jedną z nowości, o które prosili mnie użytkownicy, czyli argumenty snippetów.