Problem stary jak świat: system wymaga włączenia sporej liczby plików i zarządzanie tym jest upierdliwe. Do tego nie należy włączać więcej kodu niż potrzeba, a najlepiej zrobić jakieś lazy load.

Oczywiście, technik jest wiele:

1) require_once rozsiane po plikach, najlepiej poprzedzone jakąś stałą, np. require_once ROOT_DIR . '/foo/Foo.class.php';

2) Prado: deklarujemy namespacy - np. za pomocą funkcji using(), co dodaje nam ścieżki do include_path, a potem niech php znajdzie klasę.

3) Autoloader + mapa (nazwa klasy => ścieżka do pliku); autoloader wczytuje mapę i na jej podstawie jest w stanie znaleźć każdą klasę

Są jeszcze jakieś inteligentne sposoby? Dobry mechanizm powinien być odporny na "przemeblowanie" struktury plików (np. chcemy połączyć kilka klas w jeden plik).

BTW, włączanie plików bez klas (tylko funkcje i kod) jest gorsze, bo nie ma tego czegoś, czego można szukać po plikach... kolejna zaleta OOP?

Aby sprawę jeszcze bardziej skomplikować - warto pamietać o tym - że require_once i inlude_once jest w rzeczywistości bardzo wolne = każde wywołanie tych funkcji, nawet jeśli tym razem NIE MUSIAŁA ona ładować tego pliku, bo już był załadowany wcześniej, trwa niemal tyle samo, co require()
proste porównanie:
http://www.phpinsider.com/smarty-forum/viewtopic.php?t=4323
I choć, jak ktoś to zauwazył w tym wątku, fizyczny zysk czasu jest niewielki, to jednak procentowo - różnica jest ogromna.

Myślę, że moje rozwiązanie pomoże Ci, jeśli wpadniesz na jakiś dobry pomysł, to daj znać:
(nawiasem mówiąc każda klasa przekłada się na lokalizację w ten sposób:
Projekt_Podgrupa_Costam -> /packages/projekt/podgrupa/projekt_podgrupa_costam.php
zdecydowałem się na to, aby każdy plik miał pełną nazwę klasy, a instalator tworzył pakiety klas.)
Plik poza_drzewkiem/packages/noname/noname_package.php

[PHP] pobierz, plaintext 
<?php
define('NN_SEP', DIRECTORY_SEPARATOR);
define('NN_LIB', dirname(dirname(__FILE__)).NN_SEP);
define('NN_PRIVATE', dirname(NN_LIB).NN_SEP);
 
function __autoload($sName) {
	if (!(CORE :: Import($sName) || CORE :: ImportEx($sName))) {
		echo 'Kaboooom! Reason? '.$sName.' not found!!!';
	}
}
 
class CORE {
	public static function Import($sName, $sFind = null, $bSearch = true) {
		if (!isset($sFind)) {
			$sFind = $sName;
		}
		if ($bSearch && (class_exists($sFind, false) || interface_exists($sFind, false))) {
			return true;
		}
		$sName = strtolower($sName);
		$aArr = explode('_', $sName);
		array_pop($aArr);
		$sPath = NN_LIB.implode(NN_SEP, $aArr).NN_SEP.$sName.'.php';
		if (is_readable($sPath)) {
			include_once ($sPath);
			if ($bSearch && !(class_exists($sFind, false) || interface_exists($sFind, false)) ) {
				return false;
			}
			return true;
		}
		return false;
	}
 
	public static function ImportEx($sName) {
		$aArr = explode('_', $sName);
		array_pop($aArr);
		array_push($aArr, 'package');
		if (CORE :: Import(implode('_', $aArr), $sName) || CORE :: Import($sName)) {
			return true;
		}
		return false;
	}
}
?>
[PHP] pobierz, plaintext 

(zamiast kaboom w __autoload() będzie komunikat o tym, że strona nieczynna i próba poinformowania admina)

Pliki *_package.php zawierają zlepek klas najczęściej wykorzystywanych w danym pakiecie (noname_package.php zawiera noname_(core,timer,exception itp).php . )
ImportEx różni się tym, że najpierw spróbuje władować pakiet (czyli np. jak władowywyję jakąś usługę, dajmy SQL, to automatycznie mam wyjątki, klase do łączenia, klase do zapytań itp.)

Jeśli jestem pewien, że jakaś klasa/interfejs powinna być w systemie to poprostu z niej korzystam - jeśli nie jest władowana, to zrobi to autoload. (Klasa z pakietu nie musi sprawdzać innych z tego samego pakietu, najczęściej stosowana przeze mnie metoda)
Jeśli wgrywam usługę (auth, sql, cache...) to daję CORE::ImportEx, żeby wgrać pakiet.
Jeśli potrzebuję pojedynczą klasę to poprostu CORE::Import.

Obie funkcje Import i ImportEx zwracają true/false, czyli ustrzegają mnie przed wykorzystaniem nieistniejącej klasy, a co za tym idzie przed Fatal Error.
Przed próbą odczytania pliku oczywiście jest sprawdzenie, czy nie jest obecna już dana klasa/interfejs.

@Imperior:

Dwie słabe strony tu widzę:

1) Wszystko musi siedzieć w 2 miejscach: NN_LIB i NN_PRIVATE, co utrudnia model działania typu "user ściąga pakiet, wrzuca gdzie mu się podoba i chce żeby to działało".

2) Nie da się tego połączyć z zewnętrznymi bibliotekami, tzn takimi, gdzie nie ty decydujesz o nazwach klas.

Za to podobają mi się dwie inne rzeczy:

1) Importowanie całych "pakietów".

2) Nazwa_Klasy niejako emuluje pakiety, których php nie ma (nie możesz zrobić $foo = new com.example.Foo).

A mi się coraz bardziej podoba mapa:

[PHP] pobierz, plaintext 
<?php
$map = array(
  'MojaKlasa' => MY_DIR . 'foo/MojaKlasa.class.php',
  'MojaInnaKlasa' => MY_DIR . 'bar/KilkaKlas.inc.php',
  'MojaInnaKlasa2' => MY_DIR . 'bar/KilkaKlas.inc.php',
  'Smarty' => SMARTY_DIR . 'Smarty.class.php',
}
?>
[PHP] pobierz, plaintext 

Autoloader jest w tym momencie banalny. Takie mapy można nawet generować automatycznie przeszukując skryptem katalogi i parsując (tokenizując) pliki php. Można automatycznie łączyć mapy dostarczane z pakietami w jedną wspólną. Można dowolnie łączyć pliki w pakiety, wrzucać do jednego pliku, dzielić itd., a potem przegenerować mapę i dalej wszystko działa. Szczególnie podoba mi się to w kontekście trzymania "normalnej" hierarchii plików u siebie i dystrybuowania wszystkiego w jednym pliku po wycięci komentarzy i whitespaces.

Wada - trzeba ten głupi plik wczytać zanim autoloader cokolwiek zrobi . I ciężko byłoby automatycznie wstawić stałe jak w przykładzie powyżej.

Ja mysle, zeby rozwiazac to na podobnej zasadzie jak w javie. Mianowicie :

Mamy metode import, ta zaś wczytuje plik/pliki jakie chcemy. Czyli robimy:

[PHP] pobierz, plaintext 
<?php
import('pl.bela.foo.bar.Bar');
import('pl.bela.foo.*');
?>
[PHP] pobierz, plaintext 

W pierwszym przypadku wczyta klase Bar ktora jest w katalogu pl/bela/foo/bar/, a w drugim wczyta wszystkie klasy znajdujące się w katalogu pl/bela/foo, z wyjatkiem pl.bela.foo.bar.Bar bo informacja o tym ze taka klasa jest załadowa jest przetrzymywane w tablicy ( 2 posty wyzej jest wyjasnienie czemu ).

Co do położenia katalogow pl/bela, net/php/smarty, nie przejmuje sie tym za bardzo, ponieważ są classpathy

Aha, i nie definiuje package(); no bo po co

ad 1. NN_LIB jest podrzędne do NN_PRIVATE. W NN_LIB są trzymane właśnie pakiety, dla mnie nie do pomyślenia jest coś takiego, że user wrzuca jakiś pakiet gdzie mu się żywnie podoba, zamiast tego jest Instalator, przez którego może ściągnąć pakiet, uploadować, wskazać na serwerze i na podstawie plików konfiguracyjnych w pakiecie wszystko jest pięknie i ładnie instalowane razem z weryfikacją zależności.

ad 2. Z pozoru... Jeśli pliki będą w NN_LIB to zostaną załadowane, jedynie musi być spełniony warunek, żeby nie miały '_' w nazwach... (a jeśli tak, to żeby były prawidłowo umieszczone, ale wtedy probelmu nie ma )

Ciekawe z tymi mapami... a gdyby rozszerzyć je o jakieś wyrażenia regularne?

@bela_666: Takie rozwiązanie na pewno pasuje do javy, ale czy pasuje do php? Wszystko rozbija się o wydajność. Trzeba te importy przeczytać, pozamieniać na slashe, znaleźć katalogi, wczytać pliki... Owszem, mamy classpath (tzn. include_path ), ale w php jest to kosztowna (IMHO, nie robiłem testów) opcja, bo szuka po dysku przy każdym requeście. A przecież nie pozbędziemy się bibliotek, które nie stosują się do naszego standardu (smarty, adodb, ...). Czyli classpath się rozrasta.

Do tego, w php opłaca się wczytywać tylko te pliki, które są niezbędne. W javie nie ma tego problemu, bo wczytujesz raz i masz spokój. W php starasz się zminimalizować ilość operacji dyskowych na jedno żądanie.

W javie importy i w ogóle pakiety są potrzebne, bo 2 klasy w różnych pakietach mogą mieć tą samą nazwę i nie jest to problem. W php taka sytuacja jest niedozwolona, więc i pakiety są niepotrzebne (tak naprawdę jest to zabronione właśnie dlatego, że nie ma pakietów, ale skutek jest ten sam).

W javie z importami jest jeden problem: w pewnym momencie robi się ich zbyt dużo i upraszczamy sobie życie pisząc import java.util.*. W php jest to nie do przyjęcia - za dużo niepotrzebnie włączanego kodu. Więc nie muszę się martwić o unikalność com.example.hawk, bo to i tak nic mi nie daje.

@Imperior: sens regexpów zależy od tego, czy będą one szybsze niż wymienienie wszystkich klas. Czyli od wydajności.

Podsumowując, idealnie chciałbym mieć:
- nie muszę w swoich plikach php pisać require_once, przypominać sobie gdzie są potrzebne klasy, oraz upewniać się że nie pominąłem potrzebnego interfejsu
- mogę obsługiwać zewnętrzne (nie moje) biblioteki tak samo (tzn też bez pamiętania o require_once smarty)
- mogę w trakcie developmentu zmienić strukturę moich plików z klasami, przenieść do innych katalogów, itd. bez poprawiania mojej aplikacji
- mogę zmienić coś w n-tej dystrybucji pakietu bez obawy, że kod użytkowników nie znajdzie mojej klasy
- włączane są tylko te klasy, które są aktualnie potrzebne, i narzut czasy wykonania jest minimalny

@serafin: Możesz napisać więcej? Mi się zawsze wydawało że php nie pozwala na kropki w nazwie klasy. Tak bardzo mi się wydawało, że nigdy nie sprawdziłem. I czy to oznacza, że pełna nazwa klasy rzeczywiście brzmi System.Console.Out? Żeby autoloader mógł znaleźć klasę.

Bo problem z brakiem namespaces jest taki, że jak napiszemy $foo = new System.Console.Out, to php nie wie, że ma szukać klasy Out w System.Console, tylko szuka System.Console.Out.

A ściślej mówiąc to stara się odczytać stałe i połączyć je w jeden string.

Ja to zrozumiałem w ten sposób, że pisze kod, który zawiera błędy z punktu widzenia parsera php, a który jest parsowany, aby poprawić te błędy i dopisać jakieś includy itp.

Alternatywnie poprostu w kodzie jest coś jak:
uses 'System.Console.Out';
i to jest odczytywane, żeby do pliku wynikowego dodać includy.

serafin: czy coś w tym stylu miałeś na myśli?

A co Wam się stanie gdy zamiast System.Out będzie System_Out ?
Czy warto stosować te wszystkie parsery/tokenizery czy co tam jeszcze (opóźniające czas wykonywania) aby wygrać "walke" z kropką ?

Nic się nie stanie, poza utratą estetyki . Chociaż kwestia "kropka czy kreska" nie jest tutaj podstawowa. Problem jest raczej w tym, że autoloader będzie szukał klasy System_Out, a nie klasy Out w pakiecie System. Czyli na braku pakietów. I na tym, że na pewno znajdą się biblioteki, gdzie kreska jest używana do czegoś innego, co może wprowadzić system w błąd.

ale to jest php a nie java

Co do autoloadera... co za problem zrobić jakiś explode po znaku _
i odpowiednio sprawdzić?

Co za problem? Sprawdzanie po zrobieniu explode jest kosztowne. Odwołanie do dysku, przemnożone przez ileś tam włączanych klas. A ja zakładałem sobie idealnie, że autoloader, jako "jądro jądra", musi być super szybki.

Żeby nie było że się czepiam: to nie jest zła metoda, na razie nie zakodowałem samemu nic mądrego (stąd ten wątek). Zawsze są zady i walety, ja tylko wymieniam słabe strony.

Troche to stary kod ale moze sie przyda:

[PHP] pobierz, plaintext 
<?php
define( 'INCLUDE_PATH', 'include/' );
 
/**
 * Use this function to include classes in given namespace pattern
 *
 * @param $nsPattern string
 * @return true if succed, false otherwise
 */
function Import( $nsPattern )
{
  // Filter pattern namespace
  if ( preg_match( '/^[a-z0-9_]+(.[a-z0-9_]+){0,}(.*)?$/i', $nsPattern ) )
  {
	$nsPattern = str_replace( '.', '/', $nsPattern );
 
	if ( preg_match( '/^(.*)/*$/', $nsPattern, $match ) )
	{
	  $patch = INCLUDE_PATH.$match[1];
 
	  if ( $handle = opendir( $patch ) )
	  {
		while ( false !== ( $file = readdir( $handle ) ) )
		{
		  $i = 0;
 
		  if ( $file != '.' && $file != '..' && preg_match( '/^(.*).class.php$/', $file, $match ) )
		  {
			$filePath = $patch.&#092;"/\".$file;
 
			if ( file_exists( $filePath ) && is_file( $filePath ) && !class_exists( $match[1] ) )
			{
			  require_once( $filePath );
 
			  $i++;
			}
		  }
		}
 
		closedir($handle);
	  }
 
	  return ( $i ? 1 : 0 );
	}
	else
	{
	  $className = substr( strrchr( $nsPattern, '/'), 1 );
	  $filePath = INCLUDE_PATH.$nsPattern.&#092;".class.php\";
 
	  if ( file_exists( $filePath ) && is_file( $filePath ) && !class_exists( $className ) )
	  {
		require_once( $filePath );
 
		return 1;
	  }
 
	  return 0;
	}
  }
 
  // Wrong pattern
  return 0;
}
?>
[PHP] pobierz, plaintext 

Wywolania:
Import( 'db.*' );
includuje wszystkie klasy z katalogu include_path.'db/'

Import( 'db.jakas_klasa' );
includuje klasy o nazwie jakas_klasa z katalogu db

Pliki z klasami musza miec w nazwie .class.php

Aha... pisany pod php 4, wiec bez autoloadera :/

Seth, a czy te pregi nie spowalniają bardzo przy dużej ilości plików ?

Jakies spowolnienie napewno jest ale za to mozna latwo zaincludowac kilka klas

No chyba udało mi się to osiągnąć, mianowicie: tokenizer przejezdza po wszystkich katalogach i załączą pliki .php, a przy okazji pomija katalogi .svn ( coś się zawieszało ), wyciąga nazwy klas/interfejsów i to gdzie one się znajdują, wciska to do tablicy i generuje piękny pliczek autoload.php, wraz z funckją __autoload.

No, to by było na tyle

Jeśli mogę wtrącić trzy grosze, ja myślę, że można przejechać po katalogach czymś takim:

[PHP] pobierz, plaintext 
<?php
 
$Dir = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( ROOT_PATH ), true );
	foreach( $Dir as $File ) {
		if( $File->getFilename() === $sFile ) {
			try {
				CORE::loadClass( $File->getPathname() );
			}
			catch( CoreExceptions $Error ) {
				print Debuger::errorDisplay( $Error );
				exit;
			}
			break;
		}
	}
 
?>
[PHP] pobierz, plaintext 

Tylko trzeba zdefiniować stała ROOT_PATH i dodać do nazwy rozszerzenie i zdefiniować klasę CORE.
Warunki:

• nazwy klas musza byc takie same ja nazwy plikow (bez rozszerzenia) lub odwrotnie
• Może przy dużej ilości katalogów spowoli trochę, ale można dodać funkcje ładowania kilku klas i odrzucić katalogi

Za jakiś czas dołącze dokładniejszy kod, może trochę wolnawe, ale samo znajdzie ścieżkę dostępu do plików

@bela_666: pokaż pokaż pokaż

Nievinny: jakbyś zrobił cache jakiś to ok. Teraz uważam, że to jest najgorsze z najgorszych rozwiązań

Heh, ale to dopiero brzydko wyglądający prototyp, ale ok Pisałem, aby w ogóle działało

[PHP] pobierz, plaintext 
<?php
error_reporting(E_ALL|E_STRICT);
function get_microtime() {
	list($usec, $sec) = explode(&#092;" \",microtime());
	return ((float)$usec + (float)$sec);
}
 
global $fileContext;
$fileContext = array();
$start = get_microtime();
iterateDir('.'/*dirname(__FILE__)*/);
 
function iterateDir($path) {
	$di = new DirectoryIterator($path);
	foreach ($di as $k => $v) {
		// get extension
		$ext = end(explode('.', $v->getPathname()));
		// is svn dir
		$name = $v->getFilename();
		$first = substr($name, 0, 1);
		$first == '.' ? $dupa = false : $dupa = true;
 
		// if is dir and not svn dir, iterate this dir;]
		if($v->isDir() && $dupa) {
			iterateDir($v->getPath() . '/' . $v->getFilename());
		}
		// print filename with path, with php extenstion
		if($dupa && $v->isFile() && $ext == 'php' && $v->getFilename() != 'tokenizer.php' && $v->getFilename() != 'test.php' && $v->getFilename() != 'config.php' && $v->getFilename() != 'dupa.php') {
			$GLOBALS['fileContext'][] = array($v->getPathname(), token_get_all(file_get_contents($v->getPathname())));
			//print $v->getPathname() . \"<br />n\";
		}
	}
 
}
 
//dump($fileContext);
$classes = array();
$key = 0;
foreach($fileContext as $file) {
	static $i;
	foreach ($file as $c) {
		if(is_array($c)) {
			$a = false;
			foreach ($c as $k => $v) {
				if(is_array($v)) {
					if($v[0] == T_CLASS || $v[0] == T_INTERFACE) {
						$a = true;
					} elseif ($a && $v[0] == T_STRING) {
						$classes[] = array($v[1], substr($file[0], 2));
						$a = false;
					}
				}
				else
				{
					//print(\"$v<br/>n\");
				}
			}
		}
 
	}
 
}
 
//dump($classes);
 
$phpCode  = '<?php function __autoload($name) {' . &#092;"n\";
$phpCode .= 'static $map = array(' . &#092;"n\";
foreach ($classes as $k => $v) {
	$phpCode .= ''' . $v[0] . '' => '' . $v[1] . '','. &#092;"n\";
}
$phpCode .= ');' . &#092;"n\";
$phpCode .= 'require_once($map[$name]);' . &#092;"n}n\";
$phpCode .= '?>';
file_put_contents('autoload.php', $phpCode);
//dump($fileContext);
function dump($dump) {
	print('<pre>');
	var_dump($dump);
	print('</pre>');
}
print ($end = get_microtime() - $start . '<br />');
?>
[PHP] pobierz, plaintext 

Połączyłem kody: bela_666, Nievinny oraz Imperiora i osiągnołem taki efekt:

[PHP] pobierz, plaintext 
<?php
      public function getClassesMap($sDirName)
      {
         $oRecursiveDirectory = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( $sDirName ), true );
         foreach ($oRecursiveDirectory as $oFile)
         {
            if(!is_file($oFile->getPathname()))
               continue;
            $aTokenAll = token_get_all(file_get_contents($oFile->getPathname()));
            $bIsClass = false;
            foreach ($aTokenAll as $iToken)
            {
               if (!is_string($iToken))
               {
                  list($iTokenID, $sTokenValue) = $iToken;
                  switch ($iTokenID)
                  {
                     case T_CLASS:
                        $bIsClass = true;
                        break;
                     case T_INTERFACE:
                        $bIsClass = true;
                        break;
                     case T_STRING:
                        if ($bIsClass)
                        {
                           $aClassesMap[$sTokenValue] = $oFile->getPathname();
                           $bIsClass = false;
                        }
                        break;
                     case T_WHITESPACE:
                        break;
                     default:
                        $bIsClass = false;
                        break;
                  }
               }
            }
         }
         return $aClassesMap;
      }
?>
[PHP] pobierz, plaintext 

Linia nr 9: zmieniasz ją na:


Powinno zadziałać

@Vengeance -> Czy twoim zdaniem ładowanie z mapy powinno być zaimplementowane od razu w __autoload() czy dać jakąś funkcję pośrednią?

OK, a ja myślę, że można to jeszcze przerobić i jeszcze jedno: kiedy należy a kiedy nie robić mapę plików?

I czy pozwolisz wykorzystam to w swoim CORE?

Zobaczcie coś takiego i oceńcie

[PHP] pobierz, plaintext 
<?php
 
define( 'IN_CORE', true );
 
// ---- Definicja stałych
define( 'ROOT_PATH', './' );
define( 'PHPEX', '.php' );
 
// ---- Załadowanie systemów
include_once( ROOT_PATH . 'lib/debuger/Debuger' . PHPEX );
include_once( ROOT_PATH . 'lib/CORE' . PHPEX );
 
// ---- Mapa plików
$aMap = CORE::getClassesMap( ROOT_PATH );
// ---- Funkcja autoładowania
function __autoload( $sFile ) {
	global $aMap;
	$bLoad = false;
	foreach( $aMap as $sName => $sValue ) {
		if( $sName === $sFile ) {
			try {
				CORE::loadClass( $sValue, $sFile );
			}
			catch( CoreExceptions $Error ) {
				print Debuger::errorDisplay( $Error );
				exit;
			}
			$bLoad = true;
			break;
		}
	}
	if( $bLoad === false ) {
		print Debuger::errorLiteDisplay( 'Nie można odnaleźć podanej klasy' );
		exit;
	}	
}
 
?>
[PHP] pobierz, plaintext 

Mapa jest tworzona tylko raz, a potem porównywana w pentli foreach? Czy lepiej inaczej, np:

[PHP] pobierz, plaintext 
<?php
 
function __autoload( $sFile ) {
	global $aMap;
	if( isset($aMap[$sFile] ) ) {
		try {
			CORE::loadClass( $aMap[$sFile], $sFile );
		}
		catch( CoreExceptions $Error ) {
			print Debuger::errorDisplay( $Error );
			exit;
		}
 
	}
	else {
		print Debuger::errorLiteDisplay( 'Nie można odnaleźć podanej klasy' );
		exit;
	}	
}
 
?>
[PHP] pobierz, plaintext 

Chyba tes sposób lepszy, czy nie?

Nievinny: chodzi oto, aby mape generować tylko RAZ!! Potem jak coś dodasz/zmienisz dopiero robisz ją ponownie. W moim przypadku robienie mapy zabiera 95% czasu wykonywnia skryptu! Dlatego tak ważnym jest aby wynik był objęty jakimś cache. A czy zrobisz w __autoload() czy w czymkolwiek innym to już nie jest takie ważne

Źle mnie zrozumiałeś, to, że mapa powinna być robiona tylko raz to ja doskonale wiem....
Chodzi mi o samą funkcję __autoload() czy lepsza jest z foreach czy ta druga...

A po co foreach? Jeszcze opozniac ? To $map[$className] jest takie zle? W sumie to i tak kazdy robi jak mu wygodniej ;]

@Vengeance et al: No, bardzo ładny kod . Ja bym dodał parametryzację/konfigurację generatora mapy. Coś takiego jak ma phpdocumentor - jakie katalogi ma przeglądać, jakie pliki ma czytać. Wtedy można sobie zignorować .svn i nie trzeba tego zakodowywać na stałe w kodzie.

A potem tylko zrzucić mapę do jakiegoś pliku php i voila!

I na koniec coś takiego:

[PHP] pobierz, plaintext 
<?php
function __autoload($sClass) {
  ClassLoader::load($sClass);
}
 
class ClassLoader {
  private static $aMap;
 
  public static function addMap($aMap) {
	self::$aMap = self::$aMap == null ? $aMap : array_merge(self::$aMap, $aMap);
  }
 
  public static function load($sClass) {
	if (array_key_exists($sClass, self::$aMap)) {
	  require self::$aMap[$sClass];
	}
  }
}
?>
[PHP] pobierz, plaintext 

Ok userzy forum.php.pl "wymyslili" juz idee "routera" (a raczej po prostu to nazwali ladnie). Teraz czas nazwac to co tu razem stworzyliśmy

Nazwa: Autoload Class System...

może być, a klasa niezła, tylko, że robi zrzuty przy każdym wywołaniu skryptu a nie ciągnie z cache

Pozwolę sobie jeszcze dopisać, cos o systemie cache:
1) Jest absolutnie niezbędny:

• Czas gen bez cache: 0.0617 sec
• Z cache: 0.0111 sec
• Czyli o 0.0516 sec szybciej
• Czyli ok 5,5 raza szybciej

Jak ktoś jest zainteresowany klasą cache to na PW

Ja to rozwiązałem podobnie, jak w nowym Mojavi:

[PHP] pobierz, plaintext 
<?php
  function __autoload($class_name)
  {
	  $filename = ConfigManager::getConfig('autoload', 'autoload', $class_name);
	  if (!empty($filename))
	  {
		  /* include a file with the class definition */
		  require_once $filename;
	  }  
	  else 
	  {
		  /* unknown class */
		  throw new Exception(sprintf('Autoloading of class \"%s\" failed', $class_name));
	  }
  }
?>
[PHP] pobierz, plaintext 

Lista plików jest przechowywana w pliku konfiguracyjnym (ini). Bardzo elastyczne rozwiązanie. Trzeba tylko włączyć klasę ConfigManager - reszta jest ładowana automatycznie.

A ja generujesz listę klas? Tu masz od razu generator

Lista klas jest w pliku konfiguracyjnym autoload.ini, który wygląda tak:



Plik ten jest parsowany do tablicy i następnie chache'owany jako plik .php

Muszę przemyśleć Twój sposób ze skanowaniem katalogów... ciekawe

@chmolu:
1) Z tego co pamietam, w __autoload nie mozna rzucac wlasnych wyjatkow, bo i tak nie beda dzialac. Czyzby bug w Mojavi?

2) Pliki ini sa w tym przypadku zdecydowanie gorsze od tablic php. W pliku ini nie mozna zrobic czegos takiego:

[PHP] pobierz, plaintext 
<?php
$map = array(
  'FooClass' => FOO_DIR . '/Foo.class.php',
);
?>
[PHP] pobierz, plaintext 

Kazdy, kto bedzie uzywal systemu z plikiem ini, bedzie musial zmienic wszystkie sciezki w tym pliku, bo domyslne nie beda u niego dzialaly.

3) Jaki jest sens kompilowac plik ini do pliku php? Jezeli pliki php sa zdecydowanie szybsze, to dlaczego nie zaczac wlasnie od nich? Dla mnie to jest komplikowanie sobie zycia.

Wyjątki można wyrzucać, tylko nie mozna ich łapać w catch. Wtedy są uznawane jako fatal error.


Można zrobić coś takiego. Po prostu trzeba dodawać do każdego wpisu pseudo-stałą, np. Action = %APP_DIR%/modules/actions/action.php. ConfigManager automatycznie zamienia takie 'stałe' na właściwą scieżkę.


Wiesz, to jest indywidualna sprawa. Ja przyjąłem, że taka rzecz należy do konfiguracji, a nie do kodu aplikacji. Konfigurację zapisuję w plikach ini. Mogę oczywiście zapisywac od razu w plikach php. Dla mnie jest wygodniej to oddzielić na właściwy kod aplikacji i dane konfiguracji. Wcale nie jest to komplikowanie sobie życia. Całość ogranicza się do funkcji parse_ini_file(), var_export() i fputs().

Zależy, jak kto lubi

W sumie, skrypt po raz pierwszy zaczyna działanie więc generuje mapę, która jest potem cachowana. Gdy odpalimy skrypt po raz drugi odczyta mapę z cache (zserializowany ciąg + <?php die(); ?> ), usunie te ostatnie i przyśpieszenie jest widoczne
to sprowadza się ogólnie do:

[PHP] pobierz, plaintext 
<?php
 
if( !CORE::addMap( $Cache->loadCacheArray( 'aMap' ) ) ) {
	$aMap = CORE::getMap( './' );
	CORE::addMap( $aMap );
	$cache->saveCacheArray( 'aMap', $aMap );
}
// 'aMap' - uchwyt do pliku cache .php w ./cache/arrays/
 
?>
[PHP] pobierz, plaintext 

I wg mnie to najprostszy sposób

Zgadza się, w __autoload nie rzuca się wyjątków, ale mojavi3 nie rzuca go, tylko tworzy (bo tam ma zaimplementowane metody dot. informowania o bledach).

PS. Na początku też myślałem, że mają błąd, ale tam throw nie ma

@chmolu: Faktycznie, obsługa plików ini jest bardzo prosta. Co ciekawe, na początku próbowałem właśnie podejścia z "%APP_DIR%/...". Pliki ini wyglądają lepiej, prościej się je edytuje, trudniej popełnić błąd lub wrzucić niedozwolony kod. Z drugiej strony, trzeba wygenerować z nich pliki php, co samo w sobie jest banalne, ale wymaga sprawdzenia daty modyfikacji, czyli dodatkowego kroku. Wpływ na wydajność jest minimalny i to już chyba kwestia gustu.

Pliki ini są wczytywane szybciej niż php gdyż mają specjalny prostszy parser.
Porównajcie soebie a zobaczycie że czasami nawet cechowanie w php trwa dłużej.

A czy są szybsze od zserializowanej tablicy, zapisanej w pliku ?

Jeśli to nie jest pytanie retoryczne, to: Nie.

@Bora: Pliki ini moze i sa wczytywane szybciej, ale zamiana %APP_DIR% na odpowiednia sciezke niestety zepsuje tutaj wydajnosc.

witam ...

a moze w ini zrobic 2 sekcje ...

i potem parse ini ze znacznikiem true i mamy sklejanie stringow ...

[PHP] pobierz, plaintext 
<?php
$array['path']['app_dir'].$array['path']['class']
?>
[PHP] pobierz, plaintext 

i nie trzeba nic zamieniac ... i da sie latwo konfigurowac w tym samym ini ...

pozdrawiam

A w jaki sposob z gory okreslisz, ktora sciezke masz dokleic do konkretnej klasy? Nie zrobisz tego, chyba ze narzucisz sobie jakies bardzo scisle reguly, a tego wole uniknac.

A ja mam jeszcze pytanie dot. __autoload(). Czy jeśli wywołam w niej statyczną metodę która w razie niepowodzenia wywala wyjątek, to trzeb go obsłużyć w __autoload() czy przejdzie poziom wyżej?
Przykład:

[PHP] pobierz, plaintext 
<?php
 
function __autoload( $sClassName ) {
Application::loadClass( $sClassName );
}
 
//czy
 
function __autoload( $sClassName ) {
try {
Application::loadClass( $sClassName );
}
catch( NotFoundClassException $e ) {
//coscos
}
}
 
?>
[PHP] pobierz, plaintext 

Czy 1 sposób też może być? Czy wyjątek zostanie obsłużony?

witam ..

no przeciez normalnie ...

i potem:

[PHP] pobierz, plaintext 
<?php
 
print $iniFile['path']['mainAppPath'].$iniFile['clases']['dbclass'];
print $iniFile['path']['mainAppPath'].$iniFile['clases']['session'];
//defaultem
print $iniFile['path']['mainAppPath'].$iniFile['path']['default'].$iniFile['clases']['dbclass'];
 
?>
[PHP] pobierz, plaintext 

w sekcji clases tez moga byc sciezki podane, przeciez to lokalizacja pliku a nie nazwa klasy ... czyli dajesz najpierw najbardziej ogolna a potem w poszczegolnych klasach dodajesz, podkatalogi ... mozna na sztywno dodac default do kodu strony a jak cos sie zmieni [ale znowu bez przesady ... tak czesto sie nie zmienia i klasy i tak sa w 1 miejscu] to zmienic albo nawet wyzerowac default

pozdrawiam

@Orson: nie o to mi chodzi. Masz np. (a raczej użytkownik systemu ma) Smarty, kawałek WACT i w ogóle przynajmniej kilka bibliotek, których używa. Przecież nie będzie tak, że jeden super framework robi wszystko najlepiej, więc autoloader nie powinien być ograniczony do tego, co sami sobie wymyślimy, tylko po prostu działać tak jak chce użytkownik.

Nie powiesz teraz użytkownikowi, że ma to wszystko umieścić w innym katalogu. Będzie miał Smarty w jakimś niestandardowym miejscu, będzie chciał użyć razem z super-autoloaderem i będzie oczekiwał, że autoloader załaduje mu Smarty - od tego przecież jest.

I co wtedy? Skąd autoloader ma wiedzieć, że Smarty akurat nie jest pod mainAppPath?

PS

Nie można. Autoloader jest po to, żeby tego kodu w ogóle nie było. Nie ma gdzie dodawać defaulta.

witam ...

hmm ... no to w pliku ini w sekcji clases podajesz

a zeby bylo latwiej mozna np. wprowadzic ifa przy ladowaniu i np. jak nazwa klasy zaczyna sie od 2 // a nie od 1 to laduj bez patha .... czyli jak dopiszemy // przed smarty to oleje sekcje path i biblioteka moze byc gdziekolwiek ...
rozwiazanie z plikiem ini coraz bardziej mi sie podoba ... chyba zaczne go stosowac ...

pozdrawiam

@Nievinny: wyrzuc wyjatek w tej metodzie i sprawdz. Wyjatek wedruje w gore do ekranu (error) dopuki go nie zlapiesz gdzies po drodze.

Owszem wywala wyjątek, ale nie obsługuje go w zwykły sposób, a skrypt wychwytuje wyjątek "po drodze", tylko wywala fatal errora.

@dr_bonzo: To co mówisz byłoby dobre, gdyby funkcję wywoływać w ten sposób:

[PHP] pobierz, plaintext 
<?php
 
__autoload( $zmienna );
 
?>
[PHP] pobierz, plaintext 

A nie jeśli zostaje ona wykonana automatycznie... :/
Zostaje obsługa błędów na poziomie funkcji. Jeśli obsługujemy przez funkcję to pojawiają się problemy:
1) Jeśli klasą którą ładuje system jest klasa obsługi błędów?

[PHP] pobierz, plaintext 
<?php
 
//$zmienna = 'Debug';
function __autoload( $zmienna ) {
try {
CORE::zaladuj( $zmienna )
} catch( Exception $e ) {
print Debug::display( $e );
}
}
 
?>
[PHP] pobierz, plaintext 

Znajdą się też inne problemy... :/
Macie jakieś pomysły jak ładnie obsłużyć ten wyjątek?