try/catch vs class_exist ....

[whisher]

Ciao.
Secondo voi è meglio fare in questo modo

if(class_exists($controllerName)){
        $reflectionClass = new ReflectionClass($controllerName);
        $parent= $reflectionClass->getParentClass();
        if(!$reflectionClass->isSubclassOf(new ReflectionClass($parent->getName()))){
                $controller= new $this->defaultController();    
    } 

o

try{
            $reflectionClass = new ReflectionClass($controllerName);
            $parent= $reflectionClass->getParentClass();
            if(!$reflectionClass->isSubclassOf(new ReflectionClass($parent->getName()))){
                $controller= 'defaultController';   
            }
            
        }
        catch(ReflectionException $e){
            //exit($e->getMessage());
            $controller= 'defaultController';
        } 

Utilizzando un autoloder penso che
sia + veloce il secondo (anche se + sporco
come metodo)

ma mi piacerebbe conoscere il vs
parere

[LeaderGL]

beh secondo me il fatto che una classe esista non significa che andrà tutto a buon fine...

l'errore non è detto che capiti eslusivamente nel "$reflectionClass = new ReflectionClass($controllerName);" ma può capitare in uno dei punti successivi....

quindi opterei per il secondo metodo

[whisher]

Originariamente inviato da LeaderGL
beh secondo me il fatto che una classe esista non significa che andrà tutto a buon fine...

l'errore non è detto che capiti eslusivamente nel "$reflectionClass = new ReflectionClass($controllerName);" ma può capitare in uno dei punti successivi....

quindi opterei per il secondo metodo

Già già
It seems a good way ma si I get excited




http://www.sitepoint.com/forums/show...73#post4082373

[LeaderGL]

beh si il tizio che ti ha risposto ha articolato meglio la sua risposta, xò in sostanza il concetto è lo stesso; il try/catch controlla non solo che la classe esista ma ti mette "a riparo" (ti da la possibilità di gestire più facilmente) i vari errori che si possono presentare nelle varie istruzioni.


P.S. a che serve il codice che stai creando? :P

[whisher]

Originariamente inviato da LeaderGL
beh si il tizio che ti ha risposto ha articolato meglio la sua risposta, xò in sostanza il concetto è lo stesso; il try/catch controlla non solo che la classe esista ma ti mette "a riparo" (ti da la possibilità di gestire più facilmente) i vari errori che si possono presentare nelle varie istruzioni.


P.S. a che serve il codice che stai creando? :P

si si non volevo sminuire

sto facendo i primi esperimenti per costruire
un piccolo framework veloce poco complicato
e facile da utilizzare ............

altro problema se il controller ha almeno
un command ................. ti faccio sapere

[whisher]

 var_dump($reflectionClass->getStaticPropertyValue('my_static')); 

[LeaderGL]

L'argomento mi interessa molto, avevo aperto un thread dove invogliamo a condividere tecniche e strategie applicative nella creazione dei nostri siti/applicazioni web...ma nessuno ha risposto.

Questo può essere un qualcosa che va nella stessa direzione.

Che struttura stai dando al tuo framework? Stai implementando qualche pattern particolare?

[whisher]

Guarda per adesso sono venuti
alla luce i seguenti pattern
i soliti singleton, factory e registry
poi strategy per l'url
frontcontroller
MVC

ma ho iniziato da poco lo sviluppo
prtaicamente voglio sviluppare
qualcosa di + articolato di cosa
ho combinato nel mio progetto personale

http://code.google.com/p/phptroubleticket/


quando mi sono chiarito
un po le idee ti faccio sapere.


L'idea di fondo è creare un wrapper
che ti dia la possibilita di sviluppare solamente
(quello che deve istanziare lo sa per adesso il frontController)
i vari controllers (ie index(default),posts, comments etc)
i vari commands o actions (read(default),create,update,delete etc )
sia per GET che per POST
riconoscere se è una chiamata normale o ajax
o poi un sistema di views
la mia fonte di ispirazione
http://konstrukt.dk/

in caso contattami in pm.

[LeaderGL]

hai scritto percaso anche un piccolo diagramma delle classi che faccia capire la struttura di fondo?

L'argomento è bello. Io sto pian piano evolvendo ad una struttura full oop per quel che riguarda il mio php. Al momento faccio uso di classi e di oggetti ma non ho una vera strutturazione oop.

Mi sto chiarendo le idee su come vorrei gestire le cose in php, perchè ad esempio il normale pattern MVC secondo me non si adatta bene alle esigenze del php.

In una applicazione con interfaccia grafica interattiva "sempre pronta" (nel senso che non deve ad ogni operazione ricaricare la pagina daccapo come con il web) la struttura MVC si adatta bene; ad ogni evento puoi associare immediatamente una reazione e la divisione dei compiti mi sta bene sia fatta nelle tre parti: modelli, viste e controller.
Ma secondo me sul web questa divisione prevede una cosa di troppo, ma devo ancora ragionarci bene su.

Una volta che avrò chiare le idee cercherò di passare alla mia strutturazione; ma le esigenze di base che voglio sono:
[list=1][*]Gestione Template[*]Gestione Eventi[*]Gestione Errori (e Debug)[*]Utilizzo di plugin (sopratutto per le funzionalità del template engine)[/list=1]

[whisher]

Gestione Template
Gestione Eventi
Gestione Errori (e Debug)
Utilizzo di plugin (sopratutto per le funzionalità del template engine)

Gestione Template
imho è inutile partire dal Template
prima devi sviluppare
request, response registry ......
hai pensato all'autoloader

Gestione Eventi
tipo http://www.xisc.com/
questa sarebbe un idea che piacerebbe approffondire
insieme a http://sourceforge.net/projects/phemto/

Gestione Errori (e Debug)
si risolve con 2 funzioni
e due handler


Utilizzo di plugin (sopratutto per le funzionalità del template engine)

questo per me ha poco senso parlando
di un framework.

Da un framework mi aspetto
solo alcune chiamiamole agevolazioni
quei dei plugin è una storia che viene
dopo ancora non capisco perchè
tutta sta mania del template engine
Puoi farti dei widgets per le forms
e con una classe o ancora meglio
integrata nella logica del framework
per capirci una cosa del genere

http://massassi.com/php/articles/template_engines/

hai scritto percaso anche un piccolo diagramma delle classi che faccia capire la struttura di fondo?

ne ho fatto solamente uno schizzo a penna

sono dietro a riordinare le idee
per adesso la vera logica
dell'applicazione è proprio
nell'applicazione stessa è stato
qui l'errore nello sviluppare
il mio framework
mentre invece funziona molto bene
nella divisione dei tasks e cartelle

applicazione
-user
--controllers
--mappers
--models
--views
-admin
--controllers
--mappers
--models
--views
framework
www

gestione errori e eccezioni
e autoload insomma sbagliando
si impara è per questo che mi sto
spaccando la testa e non uso
un framework già fatto