Facebook - eeee, taaaa, suuuuper

Po latach ignorowania Facebook'a i zaprzeczaniu temu, iż jest to serwis, który w jaki kolwiek sposób mógłby mnie przyciągnąć postanowiłem pod presją otoczenia ( wszyscy, k***wa mają już konto na Facebook'u ;) ). założyć konto. No więc wpisałem wszystkie informację zalogowłem się i ...

Moim oczom ukazała się wielka biała plama z napisem, że teraz to już będę tylko szukał i aktualizował. Z boku pojawiły się jakieś propozycje znajomych. Ok, 2 osoby faktycznie z okolicy plus 1 z serbii, kumpel z Kielc i jakaś dziewczyna dłubiąca w nosie na zdięciu. Zacząłem więc przeglądać poszczególne elementy i tak naprawdę nic tam nie ma. No chyba, że się wreszcie spojrzy na to małe niewidoczne menu na dole ekranu, które skrywa wszystkie tajemnice serwisu. Nie rozumiem szaleństwa, ale będę rozwijał swoje konto i w końcu może mnie olśni.

Women Know Your Limits

Sgiento-giełda

Scjentolodzy są nieźli. Ostatnio siedziałem sobie na google.com/finance i nagle moim oczom ukazała się taka oto reklama:

W sumie ani mnie to ziębi ani grzeje, ale wiecie o co chodzi ... "takie, coś nie teges" :)

Back to the Router

Ostatnio tworzę pewną aplikację w której wydzielić można w sumie 2 główne części. Pierwsza to panel administracyjny klienta który stanowi 99% aplikacji, druga to serwis www który może oglądać klient klienta :). Ta druga część to dosłownie 1 metoda w kontrolerze odpowiedzialna za wyświetlanie poszczególnych stron serwisu. Patrząc od strony budowy aplikacji stwirdzenie, że mam panel administracyjny jest trochę źle powiedziane ponieważ całość składa się z pluginów ( aplikacja zbudowana jest w CakePHP ) i nie ma w sumie części administracyjnej. Jest zbiór pluginów które same definiują co ma być zabezpieczone a co nie. Przykładem jest właśnie plugin "Strony WWW", który udostępnia publicznie tylko 1 akcję dla kontrolera "Pages" - "show".

W momencie gdy miałem już wszystko gotowe do sprawdzenia nagle zgłupiałem. 99% Mojej aplikacji ma być dostępna po zalogowaniu, strona WWW jest tak naprawdę tylko dodatkiem. Ale z drugiej strony nie chcę, żeby klient klienta wchodząc na www.mojadomena.pl widział logowanie do części zabezpieczonej a dopiero wchodząc na www.mojadomena.pl/site/pages/show/1 stronę główną serwisu WWW, który go interesuje. W ramach początkowej paniki zacząłem już pisać dodatkowe .htaccessy i inne poronione rzeczy tak, żeby trzymało się do kupy i nie wysypało. Ale w pewnym momencie olśniło mnie. Mam aplikację w głównym katalogu "public_html" więc po co mam robić jakieś dziwne rzeczy skoro wystarczy najzwyklejsze zmienienie 1 linijki w routes.php gdzie sobie elegancko zdefiniuje

Router::connect('/', array('plugin' => 'site', 'controller' => 'pages', 'action' => 'display', 'home'));

W tym momencie żaden klient klienta nie będzie musiał wiedzieć o ostnieniu pozostałych pluginów a nawet jak trafi na jakiś inny to automatycznie zostanie przeniesniony do logowania bo tak jest to zbudowane.

CakePHP - Routing.admin

Jedną z najbardziej denerwujących rzeczy jaka pojawia się podczas tworzenia projektu jest stworzenie sekcji administratora. Standardowo wszyscy robią to korzystając ze zmiennej, którą można odkomentować w pliku config/core.php.

Configure::write('Routing.admin', 'admin');

Wszystko pięknie bo odkomentowanie tej zmiennej daje nam możliwość dostępu do kontrolerów z prefixem ( w tym przypadku ) admin, czyli np. localhost/admin/users/add. Dodatkowo możemy oprzeć na tym całą autoryzację itp itd. Mimo to rozwiązanie takie jest totalnie w moim przekonaniu beznadziejne z uwagi na jeden fakt. Korzystając z tego rozwiązania w kontrolerach musimy tworzyć dodatkowe akcje z prefixem ( w tym przypadku ) admin_. Nie wiem kto to wymyślił i czym się kierował ale jest to idiotyczne. Dlaczego chcąc mieć dostęp do standardowych metod CRUD muszę tworzyć metody admin_add, admin_edit i tak dalej? Dlaczego nie można było zrobić to na zasadzie folderu admin w katalogu controllers? Nie wiem i prawdę mówiąc, nigdy nie miałem jakoś ochoty się nad tym dłużej zastanawiać.

Nie zmienia to faktu, że jakoś trzeba robić te panele administracyjne. Oczywiście można strzelić dwie aplikacje stojące obok siebie oparte o jedne core. Nie jest to jednak imho jakieś super rozwiązanie bo ja chcę mieć jedną aplikację.

Z pomocą przychodzą nam pluginy dostępne w CakePHP. Ich oryginalne przeznaczenie jest może trochę inne ale idealnie sprawdzają się do tego typu zadań. Posiadamy w nich własne modele, kontrolery, helpery, komponenty itp., które naturalnie możemy wykorzystywać w całej aplikacji. Pozwalają na separację ( co jest logiczne, w przeciwieństwie do tego co oferuje rozwiązanie z Routing.admin ) logiki, widoków, modeli bla bla bla, panelu administracyjnego od samej aplikacji widzianej przez użytkownika. Przykładowo ostatnio miałem aplikację gdzie klient widzi pewne strony gdzie wykorzystywany jest tylko jeden kontroler i jeden model. Po co miałbym pakować tam jeszcze około 9 dodatkowych kontrolerów i modeli które potrzebne były mi w panelu?

Więcej o pluginach warto poczytać w oficjalnej dokumentacji CakePHP. Wszystko zostało całkiem nieźle opisane, choć nie ukrywam, że oparcie przykładów o plugin Pizzy nie był zbyt trafiony.

A potem inni gadaja, że CakePHP to kicha

Jakoś mnie tak ruszyło strasznie :) Właśnie w niejakim serwisie www.switchonthecode.com ( pierwszy raz o nim słyszę, może jestem cofnięty ). Pojawiła się któraś już z kolei część tutoriala dotyczącego CakePHP. Jako, że generalnie zupełnie mnie ten tutorial nie interesuje postanowiłem jedynie przewinąć się przez całość, żeby zobaczyć co tam chłopaki klecą. No i się zaczęło. Mógłbym teraz zacząć się uzewnętrzniać ale ograniczę się do fragmentów kodu.

echo $html->tableHeaders(
  array(
    'Product ID',
    'Product',
    'Description',
    'Price'
  )
);

foreach($data as $product)
{
echo $html->tableCells(
    array(
      array(
        $product['Product']['product_id'],
        $product['Product']['product_name'],
        $product['Product']['product_desc'],
        $product['Product']['product_price']
      )
    )
  );
}

Zacznę lajtowo bo to nie jest błąd ale moim zdaniem zupełnie zbyteczna rzecz. Tworzenie table za pomocą helperów. Czy naprawdę jest to tak kosmicznie potrzebne? Super, że CakePHP ma taki helper ( ma go pewnie dlatego, że inne frameworki też taki mają ). Ale po kiego grzyba go używać ? Podobnie jest z helperami do tworzenia linków:

echo $htm->link('gdzieś tam','/cos/tam'); 

- super ale

gdzieś tam // echo Router::url('/cos/tam');

ani nie jest dłuższe ani bardziej skomplikowane - jest za to szybsze! No i jeszcze można wymienić tworzenie obrazków, list, divów i całej reszty. Nie musisz, nie używaj!

echo $form->input('product_name');

Zawsze podawaj nazwę pola wraz z modelem, czyli Product.product_name ( pomijam fakt bezsensownej nazwy pola ). Przy formularzach dotyczących pojedyńczego modelu może wydawać się to bezsensowne ale jak pojawi się pole id i potem w zapytaniu wyciągane będzie pole id innego modelu to będzie płacz.

function add()
{
  if(isset($this->data))
  {
    $this->Product->set($this->data);
   
    if ($this->Product->validates())
    {
      if($this->Product->save())
        $this->Session->setFlash('Data Saved Successfully!');

      $this->redirect(array(
        'controller' => 'products',
        'action' => 'index'
        )
      );          
    }
  }    
}

Zacznijmy od

if(isset($this->data))

. Może się nie znam ale jak w klasie zdefiniowane jest

var $data = array();

to imho

isset($this->data);

wywali TRUE. Dalej przejdźmy do

$this->Product->set($this->data);

osobiście użyłbym metody create, no ale tak też działa. Dalej mamy totalną bzdurę

 if ($this->Product->validates())

. Jeżeli autor tutoriala raczyłby zajrzeć do API to pewnie nie sprawiłoby mu problemu przeczytanie dwu zdaniowego opisu metody save gdzie jest wyraźnie napisane

By default, validation occurs before save.

Nie ma więc najmniejszego sensu dodawanie tej linijki.

Naturalnie nie są to gigantyczne błędy ale uczą one nowych użytkowników złych zasad pisania kodu. Nie da się zrobić tak, żeby ktoś sam nie zagląda do API i book.cakephp.org napisał coś z czego można się czegoś nauczyć.

Dlatego jeszcze raz:

• Czytaj API


• Zaglądaj do book.cakephp.org


• Zaglądaj do tworzonych testów

PHP on Rails - chyba trzeba jeszcze poczekać.

Jakiś (znaczny ) czas temu dość intensywnie obserwowałem próby przeniesienia magii Ruby on Rails do PHP. Naturalnie można powiedzieć, że CakePHP też coś takiego robi ale na chwilę obecną wydaje mi się, że główne założenia były podobne ale teraz Cake idzie już swoją drogą. Poza CakePHP na arenie trzymały się jeszcze dwa frameworki : Akleos i PHP on Trax. Niestety z tego co widzę teraz to raczej nic z nich nie będzie. Akleos stara się przenieść możliwości Ruby on Rails jak najdokładniej. Jednak moim zdaniem robienie tego, patrząc się nieustanie czy się nie sypie w PHP4 jest drogą do do nikąd. Co do PHP on Trax tutaj nie będę się długo rozwodził, wystarczy spojrzeć na aktywne tickety.
Szkoda, bo jestem dość ciekawy co mogłoby wyjść z takiego frameworka :)

CakePHP, zgrzyt w SecurityComponent

Dostępny w CakePHP SecurityComponent to bardzo fajna sprawa. Szczególnie przydatną funkcją tego komponentu jest możliwość zwiększenia bezpieczeństwa formularzy tworzonych przy użyciu FormHelper. Jak wiadomo standardowo Cake w momencie gdy wywoływana jest metoda save modelu przyjmuje cała tablice z danymi które zostaną zapisane w bazie. Nie jest on jednak w stanie sprawdzić czy ktoś przypadkiem nie dopisał do formularz za pomocą np. FireBug'a jakiegoś dodatkowego pola którego dopisywać nie powinien. Oczywiście można w metodzie save dopisać listę dopuszczalnych pól ale jest to imho bardzo niewygodne. W tym momencie z pomocą przychodzi SecurityComponent. Poprzez proste dodanie go do aplikacji:

public $components = array('Security');

w momenci gdy tworzony będzie dowolny formularz doda on do niego token który będzie zawierał zakodowaną informację na temat pól jakie znajdują się w formularzu. Wszystko pięknie tyle, że podczas tworzenia tokenu Cake zakłada, że pola ukryte czyli takie które mają type = hidden nie będą zmieniały wartości. I tu pojawia się problem bo co zrobić jak ktoś wstawił sobie w formularzu kalendarz albo mapę Google i przed wysłaniem formularza chce zapisać w ukrytych polach nowe wartości? Za pewne można tworzyć zwykłe input'y i ukrywać je CSS'em ale nie o to chodzi. Naturalnie można temu zaradzić korzystając z możliwości ustawienia dla SecurityComponent wartości disabledFields:

$this->Security->disabledFields = array('Model.pole_1','Model.pole_2');

Wszystko byłoby pięknie gdyby nie fakt, że informację taką trzeba zawrzeć w metodzie beforeFilter() co trochę komplikuje sprawę w momencie gdy różne dane z jednego modelu edytujemy w różnych akcjach. Pewnie, że można dodać wszystkie pola jednocześnie ale czasami może przecież zdarzyć się tak że w jednej akcji na jakieś pole nie zwracamy uwagi a w innej w zależności od tego jaką ma ono wartość uzależniamy jakieś tam konkretne działania.
I to właśnie jest mój zgrzyt który naturalnie można obejść na milion sposobów w 2 minuty, tworząc np. tablicę zawierającą nazwy akcji oraz listę pól jakie mają być dopisane do disabledFields i w beforeFilter na podstawie nazwy akcji jaką chcemy wywołać dopisywać je do SecurityComponent.

jQuery 1.3

Dzisiaj ( 14.01.2009 ) ekipa jQuery ogłośiła zakończnie prac nad jQuery w wersji 1.3. Jako główne zmiany wymienione zostały:

• Sizzle: A sizzlin’ hot CSS selector engine.
• Live Events: Event delegation with a jQuery twist.
• jQuery Event Overhaul: Completely rewired to simplify event handling.
• HTML Injection Rewrite: Lightning-fast HTML appending.
• Offset Rewrite: Super-quick position calculation.
• No More Browser Sniffing: Using feature detection to help jQuery last for many more years to come.

Zmian naturalnie jest dużo więcej - o wszystkich można przeczytać na stronie informacyjnej tej wersji.

Moim zdaniem najważniejszymi zmianami jest wykorzystanie Sizzle który według różnych testów jest znacznie szybszy od innych silników.

Bardzo podobają mi się też tzw. "Live Events". Nie jest to może gigantyczna zmiana ale brak konieczności przypisywania elementów po każdym AJAX'owym zapytaniu itp. może znacznie przyspieszyć pracę.

Poza zmianami w samej bibliotece zmienia się również część strony jQuery.com na której możemy przeglądać API. Moim zdaniem zmiana na plus bo przegląda się teraz wszystko dużo szybciej. Ale to nie koniec. Aby było bardziej spektakularnie stworzona została również aplikacja w Adobe AIR pozwalająca na przeglądanie API bez odpalania przeglądarki internetowej.

Linki w CakePHP a'la Rails.

Piszą aplikacje w Ruby on Rails bardzo podobał mi się sposób tworzenia linków :

link_to "Dodaj", new_admin_client_reservation_path(client)

Może nie do końca chodzi mi o samo link_to ale już tworzenie url'a to fajna sprawa.

Pisząc aplikacje w CakePHP nie jestem szczególnie fanem korzystania z metody link znajdującego się w HtmlHelper. Osobiście wolałem wykorzystać samo Router::url() i wstawić to w element. Wszystko pięknie ale w momencie gdy trzeba zrobić link w którym konieczne jest podanie kontrolera, akcji, prefixu admin, id i jeszcze czegoś to już nie wygląda to tak pięknie gdy przekazujesz wszystko za pomocą tablicy:

Router::url(array('controller'=>'posts', 'action'=>'view', 'admin'=>true, 'id'=>$post['Post']['id']))

Dlatego też postanowiłem napisać mały helper który pozwala na tworzenie linków w trochę przyjemniejszy sposób. Oto mały przykład. Powiedzmy że mamy w aplikacji

Configure::read('Routing.admin') => secure
//w widoku
$post = array(['Post']=>array('id'=>3,'title'=>'Test post','slug'=>'test-post'));

Możemy teraz tworzyć linki tak :

$r->posts() # => /posts
$r->securePosts() # => /secure/posts
$r->formatedPosts('xml') # => /posts.xml
$r->secureFormatedPosts('xml') # => /secure/posts.xml

$r->addPost() # => /posts/add
$r->secureAddPost() # => /secure/posts/add
$r->formatedAddPost('xml') # => /posts/add.xml
$r->secureFormatedAddPost('xml') # => /secure/posts/add.xml

$r->editPost($post) # => /posts/edit/3
$r->secureEditPost($post) # => /secure/posts/edit/2
$r->formatedEditPost($post,'xml') # => /posts/edit/3.xml
$r->secureFormatedEditPost($post,'xml') # => /secure/posts/edit.xml

Naturalnie nie ma problemu żeby podać również standardowe argumenty jakie można przekazać do Router::url()

$r->SecureFormatedEditPost($post,'xml',array('full_base'=>true,'simple','#'=>'top')); # => http://example.com/secure/posts/edit/3/simple.xml#top
$r->SecureFormatedEditPost($post,'xml',array('full_base'=>true,'simple','foo'=>'bar','#'=>'top')) # => http://example.com/secure/posts/edit/3/simple/foo:bar.xml#top

Postanowiłem również ułatwić trochę proces przekazywania danych z wybranego rekordu do linku. Zawsze denerwowało mnie gdy musiałem wpisywać $post['Post']['id'] itp. Dlatego też w moim helperze można zrobić to tak:

$r->SecureFormatedEditPost($post,'xml',array('foo'=>'bar','title'=>':slug')); # => /secure/posts/edit/3/foo:bar/title:test-post.xml
$r->ViewPost($post,array(':slug')); # => /secure/posts/view/3/test-post

Uwaga! nie jest to jeszcze finalna wersja helpera! To co jeszcze trzeba zrobić

• Poprawienie wydajności ( helper jest minimalnie wolniejszy od samego Router::url() ale wydaje mi się, że można jeszcze to poprawić )
• Dla tych co jednak używają $html->link() możliwość tworzenia kompletnych linków

Helper był testowany w CakePHP 1.2  korzystając z PHP 5 ( sorry, PHP 4 jest blee ).

class rHelper extends AppHelper{
  private $adminRouting = null;
  private $idMethods = array('view','edit','delete');
  private $methods = array('add','view','edit','delete');
  public function __construct(){
      parent::__construct();
      $this->adminRouting = Configure::read('Routing.admin');
  }
  public function __call($method,$args){
      $method = explode('_',Inflector::underscore($method));
      $url = array();
      if($this->_adminSection($method[0])){
          $url[$this->adminRouting] = true;
          array_shift($method);
      }
      if($method[0]=='formated'){
          array_shift($method);
          if($this->_idRequired($method[0])){
              if(isset($args[1])  && is_string($args[1])){
                  $url['ext'] = $this->_clearArgs($args,1);
              }else{
                  throw new Exception('Link format is not specified or it\'s not a string.', E_USER_ERROR);
              }
          }else{
              if(isset($args[0])  && is_string($args[0])){
                  $url['ext'] = $this->_clearArgs($args,0);
              }else{
                  throw new Exception('Link format is not specified or it\'s not a string.', E_USER_ERROR);
              }
          }
      }
      if($this->_hasMethod($method[0])){
          $url['action'] = $method[0];
          array_shift($method);
      }else{
          $url['action'] = 'index';
      }
      $url['controller'] = Inflector::pluralize($method[0]);
      array_shift($method);
      if($this->_idRequired($url['action'])){
          if(!is_array($args[0])){
        throw new Exception('Param $args must be an array.', E_USER_ERROR);
      }
          $model_name = Inflector::classify($url['controller']);
          $data = $this->_clearArgs($args,0);
          if(!isset($data[$model_name])){
              throw new Exception('"'.$model_name.'" Model data not found.', E_USER_ERROR);
          }else{
              $data = $data[$model_name];
          }
        $model = ClassRegistry::getObject($model_name);
        if(!$model){
          App::import('model',$model_name);
          $model = new $model_name;
        }
        if(!is_object($model)){
          throw new Exception('Model "'.$model_name.'" not found.', E_USER_ERROR);
        }
          $model_id = $model->primaryKey;
      if(!isset($data[$model_id])){
        throw new Exception('Column "'.$model_id.'" is not specified.', E_USER_ERROR);
      }
          $url['id'] = $data[$model_id];
      }
      if(isset($args[0]) && is_array($args[0])){
          foreach($args[0] as $n => $v){
              if($v[0]==':' && isset($data[substr($v,1)])){
                  $v = $data[substr($v,1)];
              }
              if(is_numeric($n)){
                  $url[] = $v;
              }else{
                  if($n[0]==':' && isset($data[substr($n,1)])){
                      $v = $data[substr($n,1)];
                  }
                  $url[$n] = $v;
              }
          }
      }
      return Router::url($url);
  }
  private function _idRequired($method){
      return in_array($method,$this->idMethods);
  }
  private function _adminSection($method){
      return $method == $this->adminRouting;
  }
  private function _hasMethod($method){
      return in_array($method,$this->methods);
  }
  private function _clearArgs(&$args,$index){
      $value = $args[$index];
      unset($args[$index]);
      $args = array_values($args);
      return $value;
  }
}