Integracja Kohany i OPT

Jak pisałem w poprzednim poście - pierwsze co należało zrobić z Kohaną to zintegrować ją z systemem szablonów OPT.

Poszło wszystko dość gładko, już przy pierwszym podejściu. Łatwo bo miałem już zintegrowane CI z OPT, w Kohanie było analogicznie. Więc krok po kroku:

1. Stworzyć katalog application/libraries/opt i wgrać do niego pliki OPT
2. Stworzyć plik Opt.php i umieścić w nim kod:
   

   defined(’SYSPATH’) or die(’No direct script access.’);
   define( ‘OPT_DIR’, ‘application/libraries/opt/’ );
   require_once( OPT_DIR . ‘opt.class.php’ );
   class OPT extends optClass
   {
   public function __construct()
   {
   $this -> root = ‘application/views/’;
   $this -> compile = ‘application/views_c/’;
   $this -> cache = ‘application/cache/’;
   $this -> plugins = OPT_DIR . ‘plugins/’;
   $this -> charset = ‘UTF-8′;
   $this -> httpHeaders( OPT_HTML );
   }
   };

3. Stworzyć katalog application/views_c i nadać mu chmod 0777
4. Można w application/config/config.php dodać autoładowanie biblioteki:
   

   $config['preload'] = array
   (
   ‘libraries’ => ‘Opt’,
   ‘models’ => ”,
   );

Teraz w kodzie kontrolera można umieścić przykładowy kod:

//$this->Opt = new Opt(); // jeśli nie ma autoładowania biblioteki Opt
$this->Opt->assign( ‘title’, ‘My welcome to Kohana!’ );
$this->Opt->parse( ‘welcome.tpl’ );

Oczywiście szablon welcome.tpl musi istnieć i mieć zmienną $title, aby można było zobaczyć efekt. I to tyle, można się cieszyć tandemem Kohana + OPT

Kohana się rozwija

Od mojego ostatniego wpisu o Kohanie musiałem wykonać jeszcze jeden projekt w CodeIgniterze ( mam nadzieję, że ostatni ). Teraz już zasiadam do Kohany - widzę, że się rozwija i framework i dokumentacja. Zaimplementowane jest też ORM - ta część wiedzy jeszcze przede mną, nigdy z tego nie korzystałem, ale zdaje się, że w Symfony jest to powszechne ‘zjawisko’.

Kohana pojawiła się już w wersji 2.2 - liczę, że jej intergracja z systemem szablonów OPT pójdzie tak zgrabnie jak w CI.

PHP pójdzie do lamusa?

Odwiedziłem dzisiaj stronę code.google.com - dawno tam nie byłem. I pierwsze co mnie naszło jak zobaczyłem zbiór produktów Google to myśl, że jeszcze trochę i całe strony będzie można budować bez użycia PHP lub z jego szczątkowym użyciem. Jest API do map google, jest do użycia AJAX’a z poziomu Javy, są API do tworzenia wykresów, kalendarzy oraz App Engine API, o którym piszą:

Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.

Poczekamy i zobaczymy, ale ekspansja potenta jest dla mnie czasami porażająca…

Asynchroniczna komunikacja za pomocą Google Maps API

GM API udostępnia własną nakładkę na obiet HttpRequest, standardowo używany przy korzystaniu z technologii AJAX ( zakładając nie korzystanie z bibliotek pomocniczych ). Ostatnio siedzę więcej w Google Maps no i uznałem, że bez sensu jest zaprzęgać zewnętrzną bibliotekę skoro API GM udostępnia do tego własne funkcje. Oto jak wygląda prototyp funkcji:

GDownloadUrl(url, onload, postBody?, postContentType?)

Bardzo często ostatnie dwa parametry nie są używane ( są opcjonalne ). Wtedy komunikacja odbywa się za pomocą metody GET. Jak wiadomo, ma to swoje wady, bowiem są problemy z przesyłaniem dużej ilości informacji oraz z kodowaniem polskich znaków diakrytycznych. W dokumentacji można bez problemu znaleźć przykłady z wykorzystaniem GDownloadUrl i metody GET więc opiszę pokrótcę metodę POST. Najlepszym tłumaczeniem jest zwykle przykład kodu więć oto on:

function saveData()
{
var name = document.getElementById(”name”).value;
var info = document.getElementById(”info”).value;
var latlng = marker.getLatLng();
var lat = latlng.lat();
var lng = latlng.lng();

var url = “file.php”;

GDownloadUrl(url, function(data, responseCode) {
if (responseCode == 200 && data.length <= 1)
{
marker.closeInfoWindow();
document.getElementById(”message”).innerHTML = “Znacznik dodany.”;
}
}, “name=” + name + “&info=” + info +
“&lat=” + lat + “&lng=” + lng, “application/x-www-form-urlencoded”);
}

Funkcja ta przetwarza formularz i przesyła dane do pliku PHP metodą POST. Na początku pobierany wartości pól z formularza i ustalamy URL pliku, do którego prześlemy dane. Jest to też pierwszy argument funkcji GDownloadUrl. Kolejnym jest funkcja zwrotna, wykonywana po zakończeniu GDownloadUrl. Trzeci argument to lista danych w postaci nazwa=wartość a ostatni to typ MIME.

I to w zasadzie tyle, prosty przykład można dostosować do swoich potrzeb i wykorzystać.

FCKEditor i CodeIgniter

Zadanie było proste, żeby nie powiedzieć banalne: podpiąć edytor WYSIWYG o nazwie FCKEditor do frameworka CodeIgniter. Oczywiście byłoby zbyt pięknie, żeby działała instrukcja z Wiki CodeIgnitera więc zaczęły się kombinacje. Wogóle ta instrukcja przewidywała, żeby katalog z edytorem umieścić w głównym katalogu aplikacji co samo w sobie mi się nie podobało - w końcu po co jest katalog “libraries”?

Więc do wspomnianego katalogu wrzuciłem cały katalog “fckeditor” z edytorem w wersji 2.6 a następnie skopiowałem plik fckeditor/fckeditor_php5.php do “libraries” i rozpocząłem edycję. Po pierwsze zmieniłem nazwę klasy na “Fckeditor” ( wielkość liter znacząca ). Z pliku fckeditor/fckeditor.php skopiowałem jedyną tam funkcję i wkleiłem to do modyfikowanej klasy. Zapisałem zmiany oraz zmieniłem nazwę pliku na “Fckeditor.php”. Teraz wewnątrz kontrolera:

$this->load->library( ‘fckeditor’, ‘name’ );
$this->fckeditor->BasePath = base_url().’system/application/libraries/fckeditor/’;
$this->fckeditor->BasePath = ‘/system/application/libraries/fckeditor/’;
$fck_news = $this->fckeditor->CreateHtml();

Aby mieć dwa edytory jednocześnie wystarczy zmienić InstanceName:

$this->fckeditor->InstanceName = “new_name”;

i już można wyświetlić obydwa.

UPDATE

Ta wersja jest bezpieczniejsza - powinna działać na każdym serwerze.

PHP4 a PHP5

Dzięki linkowi podrzuconemu przez znajomego ( nie dotyczącego bezpośrednio tego wpisu ) znalazłem wspaniały cytat, który zdecydowanie nadaje się na cytat dnia:

PHP 4 is really a big pain in the ass, so try to talk your host into upgrading to PHP 5

Kohana - pierwsze starcie

Jak już pisałem w Kohana welcome to przesiadam się na tego frameworka, porzucając już całkowicie Code Ignitera ( na jego własne życzenie niestety ). Dziś nastąpiło pierwsze zderzenie z rzeczywistością.

Na stronie domowej projektu jest szybki tutorial jak odpalić pierwszą stronę w tym frameworku: ściągnąć, rozpakować, skonfigurować i jest :) Przejście z samego CI też nie jest trudne, kwestia zmiany nazw klas kontrolerów i modeli + kosmetyczne zmiany w helperach - nadal są to funkcje jednak tym razem jako metody statyczne. Pierwsza konfiguracja polega na przejrzeniu tylko jednego pliku application/config/config.php i wpisaniu ścieżki.

Co było inne niż w CI to fakt, że w katalogu application/config znalazłem tylko w/w plik konfiguracyjny. Jak się potem okazało, prototypy pozostałych są w system/config. I tak oto, jak potrzebowałem połączenie z bazą danych to przekopiowałem plik database.php do application/config, wpisałem odpowiednie dane i voila :)

Zachęcałem do spróbowania CI, teraz tak samo zachęcam do spróbowania z Kohaną - ta sama idea, prostota i wygoda używania.

CodeIgniter bye bye, Kohana welcome to

Temat o którym trąbiło i nadal trąbi wielu programistów - CI w zasadzie traci wsparcie. Mówienie, że framework jest rozwijany i trzymanie go dalej na PHP4 jest zwykłą bzdurą.

Z końcem poprzedniego roku Zend oficjalnie ogłosił koniec wsparcia dla PHP4.x, zostaje PHP5!
Co na to twórcy CI? Ano, że zanim PHP5 wejdzie w powszechne użycie to minie co najmniej 10 lat.
Kpina? Nie, oni naprawdę tak mówią…

Los frameworka w swoje ręce wzięła społeczność zgromadzona wokół CI. Zaczęli przepisywać 
frameworka na PHP5, jednocześnie poprawiając błędy popełnione przez Ellis Labs. 
Polecam powolną przesiądkę już na nowocześniejszą wersję…

Webmaster mówi “nie”

Co tu dużo pisać, wystarczy link:

http://www.wykop.pl/ramka/35453/10-pytan-na-ktore-webmaster-odpowiada-nie

Ustawienia z bazy danych w CI

Na potrzeby własnego projektu musiał napisać sobie klasę do CI, która by mi ładnie wczytywała ustawienia z bazy danych. Piszę o tym ponieważ jest to przykład jak można rozwiązać to w tym frameworku - sama klasa niczym rewelacyjnym nie jest. Idea polega na tym, aby wczytać wszystkie dane do tablicy asocjacyjnej i na niej operować zamiast ciągle męczyć bazę danych o jeden czy dwa rekordy. Jako, że są to operacje na danych to oczywiście klasa rozszerza Model.

class Preferences extends Model
{
private $prefs;
private $changes;

public function __construct()
{
parent::__construct();
$this -> prefs = array();
$this -> changes = false;
$this -> init();
}

Zmienna changes przyda się później - wtedy wyjaśnie sens jej istnienia, poza tym wywołanie konstruktora klasy nadrzędnej i inicjalizacjaklasy Preferences.

private function init()
{
$query = $this -> db -> get( ‘preferences’ );
foreach( $query -> result() as $row )
{
$this -> prefs[ $row -> pref_name ] = $row -> pref_value;
}
}

Tutaj następuje wczytanie danych jednorazowo do tablicy. Klucze tej tablicy to również klucze w bazie danych więc para klucz-wartość jest taka sama tu i tu.

public function get( $key )
{
if( array_key_exists( $key, $this -> prefs ) )
return $this -> prefs[$key];
else
return false;
}

public function set( $key, $value )
{
if ( array_key_exists( $key, $this -> prefs ) )
{
$this -> prefs[$key] = $value;
$this -> changes = true;
return true;
}
else
return false;
}

Metody dostępowe. Jeśli istnieje element o podanym kluczu to można go odczytać/zapisać w nim nową wartość.

public function __destruct()
{
if ( $this -> changes )
{
$this -> db -> query( ‘TRUNCATE `preferences`’ );
foreach( $this -> prefs as $key => $value )
$this -> db -> insert( ‘preferences’, array( ‘pref_name’ => $key, ‘pref_value’ => $value ) );
}
}

I tu widać po co była zmienna $changes. Jeśli coś się zmieniło ( tzn była wywołana metoda set dla jakiegoś klucza w tablicy ) to trzeba zaktualizować również bazę danych na końcu. Jeśli były same odczyty to nic destruktor nie robi. Taki obiekt można potem przekazywać poprzez sesje ( zserializowany ) i możemy mieć sporą oszczędność na zapytaniach do bazy.