Jak każdy programista przychodzi czas na to by ułatwić sobie pracę, piszemy dziesiątki albo i setki małych lub większych narzędzi. W 90% przypadków używamy ‘echo’ lub ‘print’ zamiast systemu szablonów i jest to chyba dość oczywiste. Najnormalniej w świecie jest to zbędne i szkoda na to czasu.
Ale czemu rezygnować z jakiegoś ładnego formatu, zaznaczenia ważnych rzeczy lub błędów które pojawiły się podczas pracy. W HTML’u nie jest to trudne, użycie stylu nadanie mu koloru czcionki i po sprawie. Sprawa może wyglądać trochę gorzej jeśli (np. tak jak ja) robicie małe skrypty odpalane pod konsolą Linuksa. Tak zazwyczaj tekst jest zawsze biały, a tło czarne. Kolorowanie tekstu pod konsolą jest stosunkowo proste. Trzeba jedynie pamiętać o tym, aby po wyświetleniu treści przywrócić kolor do swojej pierwotnej postaci.

Format kolorowania tekstu jest dość prosty, składa się ze znaku specjalnego ESCAPE, oraz definicji kolorów. Aby otrzymać znać ESCAPE użyjemy jego zapisu ósemkowego (Wartość \033, zapisana jako ‘\033‘), zupełnie tak samo jak w konsoli Linuksa oraz funkcji echo. Nastepnie po znaku ‘[‘ może występować do trzech wartości określających fomat tekstu, wszystkie oddzielane od siebie znakiem średnika ‘;’. Cały kod zakańczamy literą ‘m’. W całości kod tworzony jest na takiej zasadzie.

\033[kod_formatujący;kod_koloru;kod_tłam

przykład: \033[1;31mCzerwony gruby napis\033[0m
otrzymamy taką treść Czerwony gruby napis
Oczywiście nie musimy na końcu dawać kodu ‘\033[0m’ ale cała konsola będzie wyświetlać jedynie czerwoną pogrubioną czcionkę do czasu aż zostanie ona zamknięta lub otrzyma kod resetujący ustawienia.
Poniżej podaje listę kodów które można wykorzystać do formatowania konsoli.
Kody formatujące

• 0 – resetuje wszystkie ustawienia
• 1 – pogrubiona
• 2 – przyciemniona czcionka
• 4 – podkreślona
• 5 – mrugająca
• 7 – zamienia miejscami kolor czcionki i tła

Kody kolorów czcionki

• 30 – czarny
• 31 – czerwony
• 32 – zielony
• 33 – brązowy
• 34 – niebieski
• 35 – magenta
• 36 – turkusowy
• 37 – biały

Kody kolorów tła

• 40 – czarny
• 41 – czerwony
• 42 – zielony
• 43 – brązowy
• 44 – niebieski
• 45 – magenta
• 46 – turkusowy
• 47 – biały

Poniżej podaje przykład jak zastosować to praktycznie w kodzie PHP. Szczerze mówiąc jest to jedynie wycinek który wykorzystuje w swoich klasach, można to oczywiście zamienić na normalną funkcję. Używana przeze mnie metoda używana jest aby wyświetlać pokolorowaną treść w konsoli oraz w przeglądarce. Równie dobrze można by zdefiniować wszystkie kolory tła i format czcionek, ale podejrzewam, że każdy może to zmodyfikować w swoim zakresie.

Przykładowa klasa Display której sam używam.

bibliografia:
http://www.newlinuxuser.com/linux-console-codes/
http://www.linux.gr/cgi-bin/man2html?console_codes+4
oraz wielkie Google

DataGrid for Zend Framework

Wczoraj wieczorem na forum zend-framework.pl pojawił się link do ciekawego projektu realizującego tak oczekiwany przez wielu scaffolding.  Projekt nazywa się DataGrid for Zend Framework i obudził moje nadzieje na szybkie implementacje CRUD w rozwijanych przeze  mnie projektach. Niestety, nie jest jeszcze aż tak różowo

Po wstępnych testach mogę już napisać parę słów co o tym sądzę, i niestety optymizm miesza się z garścią zawodów. O ile sam “grid” działa bezproblemowo, można szybko i prosto wstawiać sortowalne i paginowalne (dziwne słowo) tabele do projektów, to sposób realizacji jest już mniej przyjemny.

Niestety, cały system działa w oderwaniu od zendowskich modeli. Inicjalizacja grida wygląda mniej więcej tak:

$grid = new $grid (  $db, 'Grid Example', APPLICATION_PATH . 'public_html/temp', array ('download', 'save' ) );
$grid->from ( 'table' )->order ( 'id ASC' );

Jak widać wewnątrz kontrolera musimy nie tylko mieć adapter bazy, ale także znać dokładną nazwę tabeli.  W moim przypadku kiedy samych baz w projekcie mam 6, a tabel nawet nie liczyłem, jest to kłopotliwe.

Kolejny problem wynikający z niekorzystania z modeli, jest niemożliwość zachowania logiki biznesowej która w takich modelach może się znajdować.  Bardzo często w modelach wykorzystuję $_rowClass i możliwości oferowane przez takie metody jak Zend_Db_Table_Row::_insert() Zend_Db_Table_Row::_postUpdate().  Pozwala mi to automatycznie filtrować dane, czyścić odpowiedni cache przy modyfikacjiach, tworzyć/modyfikować powiązane wpisy itp. Oderwanie grida od modelu uniemożliwia natomiast takie rozwiązania i zmusza do dodatkowego kodu.

Resumując, na obecnym etapie ten komponent może się sprawdzić jako narzędzie do szybkiego przeglądu zawartości tabel (zwłaszcza jeśli w modelu zaimplementujemy sobie metodę w rodzaju getGrid), ale jeśli chodzi o funkcjonalność CRUD to oderwanie ich od modeli w moich oczach dyskfalifikuje to rozwiązanie. Szkoda.

Related posts

• Łączenie wielu plików PDF w jeden (2)
• Zend_Captcha::factory() (2)
• Zend_Auth i modyfikowany rekord usera bazujący na Zend_Db_Table_Row (0)
• TCPDF i ZF (0)
• Firebug, FirePHP – nowa jakość w debugowaniu i monitorowaniu aplikacji (0)

W odpowiedzi na liczne pytania, chciałbym krótko przedstawić moją opinie na temat plusów i minusów korzystania z frameworków w małych aplikacjach i czy warto w ogóle z nich korzystać.

Moja odpowiedź to stanowcze TAK. Jest bardzo dużo plusów i raczej znikoma ilość minusów (w tym momencie, żadne nie przychodzą mi do głowy). Oczywiście podstawa to poznać framework nim zaczniemy jakąkolwiek pracę - obsługę żądań, przepływ danych, nazewnictwo metod/akcji/kontorlerów, warstwę abstrakcji dla bazy danych i widoki.

Trudno mówić tutaj o wyborze najlepszego rozwiązania, każdy framework ma swoje wady i zalety. Ja szczerze polecam Syfmony i Zend Framework - niestety nie miałem jeszcze wystarczająco dużo czasu by móc poznać cakephp czy code ingniter, z drugiej jednak strony te których używam w zupełności mi wystarczają i jak do tej poty nie musiałem szukać innych rozwiązań.

Do rzeczy. Symfoni do małych projektów raczej bym nie polecał, szczególnie początkującym. By móc pracować z nową wesją 1.2 trzeba poświęcić sporo czasu na czytanie dokumentacji - szczególnie skomplikowany może wydawać się obiektowy model budowy formularzy, który jest naprawdę świetny gdy się go już pozna. Zainteresowani znajdą więcej informacji tutaj: Symfony 1.2 lub na stronie projektu.
Co do Zenda i małych aplikacji to uważam, że to bardzo dobre zestawienie (w żadnym wypadku nie wykluczam Zenda z dużych projektów). W przypadku niedużej aplikacji w zupełności wystarczą nam dwa moduły: default i admin (wykorzystując oczywiście modułową strukturę) + kilka/kilkanaście kontrolerów w każdym z nich. Dodałbym do tego ORMa Doctrine (bardzo prosta integracja którą opisałem w grudniu: Zend Framework + Doctrine - introduction) lub jeśli ktoś się uprze to Propela. W ostateczności można użyć Zend_dbTable, ale z doświadczenia wiem, że jest On bardzo niewygodny. Ponadto raczej nie polecam Zend_Form (nie używałem, ale nie słyszem nic dobrego w tym temacie), godne zainteresowanie są: Zend_Layout oraz Zend_View. Dodatkowo możemy dołożyć system szablonów Smarty i już mamy gotowy do działania szkielet aplikacji. Na pewno sprawdzi się w przypadku niedużych serwisów/stron, ale nic też nie stoi na przeszkodzie by móc go z czasem znacznie rozbudować.

Registry to wzorzec projektowy, który ma za zadanie przechowywać i udostępniać dane w obrębie aplikacji. Implementacja wzorca zastępuje globalny zasięg wartości zarejestrowanych w przestrzeni klasy. Różnicą globalnego zasięgu zmiennych oraz wartości ujętych w Registry jest to, że można je ściśle kontrolować (dostęp w aplikacji itd.). W tej publikacji przedstawię jedną z najprostszego wykorzystania wzorca Registry.

Głównym założeniem Registry jest globalny zasięg (pomijając już zabezpieczenia dostępowe, którymi się nie zajmujemy). Język PHP od wersji 5 obsługuje statyczne static wywołania metod klas, czyniąc tym samym ich globalny zasięg wraz z połączeniem ze słowem kluczowym public. Dla wygody - nie trzeba tworzyć instancji klasy, więc wywołanie jest bardzo proste i nie zajmuje dużo miejsca w naszym kodzie.

Podstawowymi funkcjonalnościami Registry będzie:

• dodawanie i usuwanie,
• pobieranie

…zmiennych z rejestru. Pojęcie zmienna jest bardzo względne. Przechowywać w rejestrze możemy praktycznie wszystkie typy zmiennych dostępnych w PHP, włączając w to typ resource (zasoby). Registry to nic innego, jak przechowywanie zmiennych w przestrzeni jednej klasy, więc nie mamy wobec tego żadnych ograniczeń.

• Przykładowy kod najprostszej implementacji wzorca Registry.
• Użycie powyższej klasy RegistrySimple.

Zajmiemy się teraz bardziej rozbudowanym przykładem wzorca. Wykonamy następujące operacje:

1. Nowa klasa RegistryAdvenced będzie dziedziczyła z RegistrySimple na potrzeby metody Registry().
2. Zaimplementujemy interfejsy:
   • Iterator
   • ArrayAccess (na potrzeby poruszania się po instancji jak po tablicy)
   • Countable (aby łatwo otrzymać liczbę przechowywanych danych)
   • Serializable (żeby można było zaserializować i odserializować instancję obiektu)
3. Dodamy prywatny konstruktor, skorzystamy ze wzorca Singleton.

Gotowy kod klasy RegistryAdvenced.

Interpretacja i rozwijanie swojego wzorca Registry jest szeroka, można na przykład zastosowac przestrzenie rejestrów, tj. tworzyć wiele rejestrów na podstawie ich instancji. Ile programistów, tyle pomysłów, ale zasada działania nie zmienia się. Zainteresowanych zapraszam do manuala, jak problem został rozwiązany w Zend_Registry.

A couple of weeks ago i have shown you really useful example about unsetting sfForm fields - unsetAllExcept. Since that i was palying with sfForm and i found more functions that could help you working with symfony forms.

All methods shown below have to be added to BasePropelForm class (or Doctrine depending on ORM we use).

Setting single form value
There is no really simple way to set single value of field - i’m not talking about setting default value. We can call getValue on Form but not setValue. Imagine situation when we post a form and just after binding we want to set value. You can find exampe in this post.

<?php

   /**
   * Sets a value for a form field.
   *
   * @param string $field	The field name
   * @param mixed  $value	The default value
   */
    public function setValue($field, $value){

    	if(!in_array($field, array_keys($this->values))){

    		throw new sfException(sprintf('Unkown field" "%s" in "%s" object.', $field, get_class($this)));
    	}

    	$this->values[$field] = $value;
    }

?>

Getting single embed form
Sometimes we need to get single embedded Form to call on it our custom method or get some value. So:

<?php

  /**
   * Gets the embedded form by given name.
   *
   * @param string $name  Name of embedded form
   * @return moxed sfForm obejct
   */
  public function getEmbeddedForm( $name)
  {
      return ( isset($this->embeddedForms[$name]) ) ? $this->embeddedForms[$name] : null;
  }

?>

Setting and getting parent form
Next three functions i’m using together during embedding forms. The problem i had lately, was that my embedded form knew nothing about his parent (i will try to show you some example next time). So i added protected field “parentForm” which i’m setting during embedding process.

<?php

abstract class BaseFormPropel extends sfFormPropel
{
  protected $parentForm = null;

    # We are overriding embedForm method
  public function embedForm($name, sfForm $form, $decorator = null)
  {
   	$form->setParentForm($this);

   	parent::embedForm($name,$form, $decorator);
  }

  public function setParentForm($form){

  	$this->parentForm = $form;
  }

  public function getParentForm(){

  	return $this->parentForm;
  }

}

?>

Zend_Captcha_Image

Wczoraj przy okazji drobnych modyfikacji w jednym z starszych projektów zaszła potrzeba użycia mechanizmu Captcha. Oczywiście pierwsze spojrzenie padło na komponent Zend_Captcha. Po drobnych walkach związanych z błędami w dokumentacji (konkretnie przykład użycia isValid()), udało nam się doprowadzić ją do działania, i jak na razie się sprawdza. Przy okazji jednak zauwżyłem brak jednej, IHO bardzo przydatnej funkcjonalności jaką jest Factory. A skoro czegoś nie ma, to trzeba to sobie napisać

Zanim przejdę do klasy Factory, dla potomności i innych drobna uwaga na temat użycia isValid(). Dokumentacja ZF zawiera następujący przykład:

if ($captcha->isValid($_POST['foo'], $_POST)) {
    // Validated!
}

Natomiast z praktyki i analizy kodu wyszło nam że prawidłowa kontrukcja to:

			if ($captcha->isValid(
				array(
					'input' => $this->getRequest()->getParam('foo'),
					'id' => $this->getRequest()->getParam('id')
				) )) {
			    // Validated!
			}

To tyle dla potomności, teraz wracamy do sprawy Factory.

Dlaczego klasa faktorująca jest tak istotna? Przyjrzyjcie się jak działa Zend_Cache czy Zend_Db. W onfigu trzymamy sobie parametry konfiguracyjne, a w samym kodzie wywołujemy przykładowo:

$cache = Zend_Cache::factory ( $config->cache->frontend, $config->cache->backend, $config->cache->frontendOptions->toArray(), $config->cache->backendOptions->toArray());

Chcąc zmienić metodę cachowania czy dowolny parametr, robimy to w jednym pliku bez potrzeby wgłębiania się w kod i wyszukiwania wszystkich wystąpień. Natomiast w przypadku Zend_Captcha, każdorazowo w kodzie musimy decydować jakiego adaptera używamy oraz przekazywać parametry. Używając Zend_Captcha w kilku miejscach, i potrzebując nagle zmienić adapter np. z Zend_Captcha_Figlet na Zend_Captcha_Image, musimy wyszukać wszystkie wystąpienia, i ręcznie je zmienić.

Dlatego napisałem sobie Mao_Captcha::factory()

Przykłady użycia:

Standardowy Zend_Captcha_Image

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

Zwiń
Czytaj na blogu autora...

Build-in symfony form validation is really great feature. Using Propel or Doctrine ORM we have simple validation by default which we can modify in simple way.
But sometimes we want something more than server side validation (later in post SSV) and then we can easliy use javascript. Client side validation (CSV) is nice and useful but we need to remember that it could be easily switched off. So SSV is always required.

Let’s begin.

I’m not going to build a whole application. I just want to show you how to create simple contact form, validate it using SSV and CSV (with jQuery) and save it.

First of all we need to create new symfony app. If we have symfony already installed on our PC, we can just create new project directory, for example sfSimpleApp and then call:

<?php

    symfomy generate:project sfSimpleApp

?>

Remember that you need to write symfony tasks in command line (on windows -cmd prompt).
As it is a simple example we are not going to configure a web server.

If We don’t have symfony - it’s not a problem - download Symfony 1.2 sandbox.

Then generate standard frontend app and contact module:

<?php

    symfony generate:app frontend
    symfony generate:module frontend contact

?>

Now we can configure our database:

<?php

    symfony configure:database "mysql:host=localhost;dbname=sfSimpleApp" user password

?>

In our example we need just one table - to store our contacts. The follwing schema is just what we need:

propel:
  contact:
    id:       ~
    name:     { type: varchar(255), required: true }
    email:    { type: varchar(255), required: true }
    subject:  { type: varchar(255), required: true }
    message:  { type: longvarchar, required: true }

No it’s time for symfony. First, we will generate and insert sql:

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

Zwiń
Czytaj na blogu autora...