Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu php Kanał ATOM (tag: php)

Autor wpisu: sokzzuka, dodany: 04.07.2011 22:53, tagi: php

Podczas swojej już kilkuletniej pracy zawodowej przy tworzeniu aplikacji internetowych, niejednokrotnie musiałem implementować różnego rodzaju systemy kontroli dostępu. Jedne były proste, drugie bardziej skomplikowane, nie mniej jednak każda aplikacja, którą rozwijałem takowy posiadała.

System kontroli dostępu zwykle opiera się na dwóch założeniach:

  1. istnieją zasoby do których należy ograniczyć dostęp
  2. ograniczenia dostępu przypisywane są wg ról użytkowników w systemie

Powyższy opis dokładnie odzwierciedla ideę, która leży za każdym rozwiązaniem typu ACL (ang. Access Control List). Zapewne większość z Was miała styczność z różnymi bibliotekami wspomagającymi tworzenie takich list, jak chociażby Zend_Acl z ZF.

W niniejszym artykule pragnę zaprezentować alternatywne rozwiązanie, luźno inspirowane filozofią DDD (ang. Domain Driven Design) i OOD (ang. Object Oriented Design) oraz pokazać gdzie drzemie potencjalna siła systemu typów.

By dobrze zrozumieć całą ideę należy wpierw zadać sobie pytanie „czym jest system typów” ?

Wikipedia definiuje system typów w następujących słowach

W językach programowania system typów może być zdefiniowany jako system klasyfikacji wyrażeń w zależności od rodzajów wartości, jakie one generują. Każdej obliczonej wartości przypisywany jest pewien typ, który jednoznacznie definiuje, jakie operacje można na niej wykonać. Śledząc przepływ wartości, system typów stara się udowodnić, że w programie występuje poprawne typowanie, tzn. nie dochodzi do sytuacji, w której na wartości określonego typu próbujemy wykonać niedozwoloną operację.

W prostych słowach można by powiedzieć, że system typów jest pewnym zbiorem reguł, dzięki którym możemy narzucić takie ograniczenia (constraints) w naszym programie, że będzie on „poprawny”. Oprócz tej definicji, w zorientowanym obiektowo języku programowania, dzięki systemowi typów, możemy kompleksowo opisywać rzeczywistość dokonując jej „klasyfikacji”.

Idąc dalej tym tokiem myślenia, jeżeli przestaniemy przez chwilę traktować elementy systemu typów czysto pragmatycznie – jako narzędzia do upychania kodu i poszukamy dla nich analogii w świecie rzeczywistym, to możemy dość do następujących wniosków:

  • klasa – opisuje pewną grupę realnych obiektów
  • interfejs – opisuję umiejętności obiektu
  • klasa abstrakcyjna – jest szerszym określeniem dla pewnej grupy klas

Jak to się ma do rzeczywistości ? Prześledźmy to na przykładzie klasyfikacji zwierząt:

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

Autor wpisu: batman, dodany: 04.07.2011 08:00, tagi: php

Podstawowym elementem wykorzystywanym podczas tworzenia aplikacji w PHP są klasy. Tworzenie strukturalnego kodu od dłuższego czasu jest passé, a każdy kto publicznie przyznaje się do tego procederu, staje się ofiarą “ewangelistów obiektowości”. Trzeba przyznać, iż twórcy PHP zadali sobie sporo trudu, aby programowanie obiektowe w PHP nie było powodem do kpin i od piątej wersji języka dodają coraz to nowe usprawnienia wspomagające obiektówkę. Odkąd zacząłem poznawać Ruby (oraz Railsy), zaczynam powoli dochodzić do wniosku, iż OOP w PHP jest nieco przekombinowane. Zwłaszcza w kontekście tworzenia aplikacji internetowych.

Tworzenie klasy

W obu językach tworzenie klasy wygląda bardzo podobnie.

<?php
class Foo
{
}
class Foo
end

W przypadku Ruby ważne jest aby nazwa klasy zaczynała się wielką literą. W przeciwnym wypadku zgłoszony zostanie błąd.

Dodawanie metod

Dodawanie metod do klasy również zbytnio się nie różni.

<?php
class Foo
{
	public function bar()
	{
	}
}
class Foo
	def bar
	end
end

W obu językach istnieją modyfikatory widoczności metod. Zarówno w PHP jak i w Ruby metoda domyślnie jest publiczna, czyli można ją wywołać z dowolnego miejsca w kodzie. Zasadniczą różnicą jest sposób określania widoczności metod. W PHP można to zrobić tylko i wyłącznie podczas deklarowania metody, Ruby natomiast pozwala zdefiniować widoczność na dwa sposoby.

Pierwszym sposobem jest użycie modyfikatora widoczności między metodami. Wszystkie metody będą posiadały widoczność określoną modyfikatorem, pod którym się znajdują. Modyfikator obowiązuje do końca klasy lub do definicji kolejnego modyfikatora.

class Foo
	def bar
	end

	protected

	def baz
	end

	private

	def barbaz
	end
end

Drugim sposobem określenia widoczności metod jest wypisanie po modyfikatorze dostępu metod, oddzielonych przecinkami. W tym sposobie ważne jest aby deklaracja widoczności znajdowała się po metodzie. Należy również pamiętać, aby nazwę metody zapisać jako symbol, czyli poprzedzić ją dwukropkiem.

class Foo
	def bar
	end

	def baz
	end

	def barbaz
	end

	protected :baz
	private :barbaz
end

Właściwości

W obu językach możemy dodać do klasy właściwości. W PHP są to po prostu właściwości lub właściwości statyczne. Ruby określa je jako zmienne instancji (obiektu) oraz zmienne klasy. W przypadku PHP właściwości posiadają takie same zasady określania widoczności jak metody. Z kolei w Ruby zmienne instancji oraz klasy są niewidoczne poza obiektem/klasą.

<?php
class Foo
{
	public $publiczna;
	protected $chroniona;
	private $prywatna;

	public static $publicznaStatyczna;
	protected static $chronionaStatyczna;
	private static $prywatnaStatyczna;
}
class Foo
	@zmienna_instancji
	@@zmienna_klasy
end

Settery i gettery

W PHP dostęp do właściwości odbywa się przy pomocy ręcznie tworzonych metod, tzw. setterów i getterów. Od biedy można skorzystać z magicznych metod, jednak i tak wymagają one od programisty napisania sporo kodu. Ruby oferuje dwa sposoby tworzenia setterów i getterów – tradycyjny, polegający na napisaniu dwóch metod do każdej zmiennej obiektu/klasy oraz akcesory – dynamiczne generowanie wymaganych metod dla wskazanych zmiennych. Zobaczmy najpierw tradycyjny sposób.

<?php
class Foo
{
	protected $chroniona;

	public function getChroniona()
	{
		return $this->chroniona;
	}

	public function setChroniona($value)
	{
		$this->chroniona = $value;
	}
}
class Foo
	@zmienna_instancji

	def zmienna_instancji
		@zmienna_instancji
	end

	def zmienna_instancji= value
		@zmienna_instancji = value
	end
end

Warto tutaj wspomnieć o dwóch konwencjach przyjętych w języku Ruby. Po pierwsze – wynik ostatniej instrukcji metody jest automatycznie zwracany (dlatego nie jest wymagane słowo return). Po drugie, przyjęło się, iż setter kończy się znakiem równości (w Ruby jest to znak jak każdy inny). Nie jest to wymagane, ale warto trzymać się przyjętych konwencji. Warto również wiedzieć, że możemy pomijać nawiasy zarówno w deklaracji metody, jak i jej wywołaniu. Zapis metody z nawiasami wyglądałby następująco:

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

Autor wpisu: Tomasz Kowalczyk, dodany: 03.07.2011 21:23, tagi: php

W karierze programisty ważne jest, aby ciągle rozwijał się poprzez lekturę różnego rodzaju materiałów dotyczących technologii, z jakich korzysta w pracy. Dlatego w serii Linkdump pojawiają się serie linków dotyczących narzędzi wykorzystywanych podczas tworzenia stron internetowych. Czasem jednak warto też spojrzeć na inne artykuły, pozwalające na wzniesienie się ponad typowe problemy z kodem i zobaczenie [...]

Autor wpisu: bigzbig, dodany: 02.07.2011 13:31, tagi: php

Stawiałem już projekty oparte na frameworku Kohana 3 na różnych serwerach. Jak dotąd zawsze działał mi plik .htaccess o treści: # Turn on URL rewriting RewriteEngine On   # Installation directory RewriteBase /   # Protect application and system files from being viewed RewriteRule ^(?:application|modules|system)\b - [F,L]   # Allow any files or directories that [...]

Autor wpisu: Diabl0, dodany: 29.06.2011 15:37, tagi: mysql, php, sql, zend_framework

Od jakiegoś czasu borykałem się z problemem dlaczego czasami zapisywane do bazy danych zserializowane dane są „obcinane. Poszukiwania, googlanie niewiele pomagało aż a końcu trafiłem gdzieś na informację że problemem może być znak NULL (0×00) w którym PHPowe serialize się lubuje :) . A koro tak, to postanowiłem napisać swoją wersję serialize.

Kod tutaj:

<?php
/**
 * Serializowanie i deserializowanie treści zawierających 0x00
 *
 * @category    Mao
 * @package     Mao_Serializer
 * @author      Krzysztof 'Diabl0' Szatanik
 * @copyright   Copyright (c) 2011, MAO Group
 * @version     $Id: Form.php 1164 2009-11-10 13:01:53Z diabl0 $
 */

/**
 * Własna nakładka na serializację
 *
 */
class Mao_Serializer {

	const CHAR_0x00 = '\\$0x00$/';

	/**
	 * Serializuje obiekt jak serialize() z tym że zastępuje znak 0x00
	 * aby nie sprawiał problemu przy zapisie do bazy danych
	 *
	 *
	 * @param mixed $obj
	 *
	 * @return string
	 */
	static function serialize( $obj ) {
		return str_replace( chr(0x00), self::CHAR_0x00, serialize( $obj ) );
	}

	/**
	 *
	 * Deserializuje obiekt jak unserialize() z tym że przywraca
	 * zastąpiony znak 0x00
	 *
	 * @param string $string
	 *
	 * @return mixed
	 */
	static function unserialize( $string ) {
		return unserialize( str_replace( self::CHAR_0x00, chr(0x00), $string ) );
	}

}

Użycie jest banalne:

<?php
$text = 'to jest test znaku [' . chr(0) . '] - czy sie dobrze zapisuje do bazy';
$serialized = Mao_Serializer::serialize($text);
$unserialized = Mao_Serializer::unserialize($serialized);
?>

Wiem że nie jest to idealne rozwiązanie ale na razie nie mam czasu aby przysiąść i dorobić jakąś konwersję w locie na poziomie Zend_Db_Adapter

Autor wpisu: sokzzuka, dodany: 29.06.2011 11:24, tagi: php

Po długich bólach porodowych dostaliśmy do rąk PHP 5.4 w wersji alpha 1. Szczegóły można znaleźć na oficjalnej stronie php. Jest to pierwsze wydanie wg nowego cyklu wydawniczego, który został niedawno zaakceptowany – po szczegóły odsyłam do RFC. Głębszy komentarz wkrótce (muszę się odkopać z „tasków” ;P)

Autor wpisu: Tomasz Kowalczyk, dodany: 29.06.2011 02:19, tagi: php

Szukałem ostatnio szybkiego sposobu na podzielenie stringa według jednoznakowego separatora, aczkolwiek w taki sposób, by omijał jego "escape'owaną" formę. W ten sposób mógłbym np. parsować pewne dane tekstowe równocześnie umożliwiając wykorzystanie separatora w samym tekście. Zadanie teoretycznie nie wydawało się trudne, aczkolwiek faktyczne rozwiązanie okazało się co najmniej "nietrywialne". W dzisiejszym bardzo krótkim i treściwym [...]
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.