Newsgroup: it.comp.www.php
Titolo: MVC handmade o framework?

Ciao
 
una curiosità,solitamente preferite orientarvi nel maremagnum dei
framework PHP disponibili, oppure utilizzate altri approcci? (tipo
strumenti "fatti in casa" su misura)?
 
:)
 
thx
 


Dipende dal progetto, dalle feature che cerchi, da quanto conosci il framework
e naturalmente dal gusto personale.
 
Io, per progetti medi, uso il mio (che tra l'altro ho messo da pochissimo
online sotto BSD-3) 
http://www.pqwe.org/
 
Avrei voluto fare un post a parte qui per chiedere pareri ma vabbè, ormai è
capitata prima l'occasione :)
 
Per cose invece molto piccole o grosse ma con pochissima personalizzazione
richiesta cerco qualcosa di prefatto così da finire in giornata. Per blog-like
Wordpress, per negozi online qui usano Shopware (che è una vera incredibile
cagata tedesca (TM) - ma sai come sono i crucchi, se è tedesco è per forza
migliore di qualsiasi altra cosa).
 
Ciao!


Ci sono talmente tanti framework, dai micro ai mastodonti, che oggi ha 
senso farne uno handmade solo per imparare qualcosa, e poi non usarlo mai 
più.
 
Le beghe di sicurezza, gli edge-corner-case, l'estensibilità, ecc. le 
lascio volentieri ad altri.
 
Se vuoi il controllo quasi totale di quello che succede, usa un 
microframework come Silex o Slim. Ti mette a disposizione le basi 
(routing, request, response, modularizzazione, ecc.), puoi usare 
componenti di Symfony per alcune cose (form, templating, ACL, ecc.), e ti 
scegli gli altri componenti da Packagist.
 
Se vuoi un framework più "magico", che faccia molto per te, pieno di hype 
e fatto per principianti o poco di più, usa Laravel.
 
Una buona via di mezzo tra Silex e Laravel è Yii 2. Poco conosciuto, ma 
ben progettato, configurabile, abbastanza "trasparente" (c'è magia ma la 
configuri tu).
 
Se vuoi un framework solido, testato, molto ben mantenuto, estendibile ma 
un po' più complicato da usare, usa Symfony.
 
Se ti piace l'XML (e configurare tutti gli aspetti della tua applicazione 
in XML invece che in codice) ma non vuoi farlo sapere in giro e quindi fai 
le stesse cose, ma scrivendo array PHP, e vuoi un framework grosso e 
lento, usa Zend Framework 2.
 
Bye.

 
 
Il problema principale che mi spinge ad usare il mio in realtà è molto
semplice. Zend Framework (sia 1 e 2) è l'unico che fa "le cose a modino" (o,
dicendo meglio, è più enterprise-friendly) ma è un grosso baraccone, mentre
tutti gli altri si scimmottano a vicenda, aggiungendo di fatto nulla alle
possibilità che uno ha usandoli. Symfony o CodeIgniter, d'altro canto, sono
principalmente una grossa collezione di snippets e, a meno di non conoscerli a
menadito, si fa prima a cercare su Stackoverflow quello che serve al momento
invece che cercare nel codice di uno dei due.
 
Fondamentalmente se bisogna sviluppare una cosa standard si prende direttamente
un prodotto già pronto, per cui quando si sceglie un framework è per fare
qualcosa un po' fuori dagli schemi, ed avere un grosso set di funzionalità
standard non aiuta molto, visto che non serviranno.
 
IMHO il top era avere una cosa quasi uguale a ZF, ma senza tutta la catena
di eventi, il bootstrapping e l'incredibile complessità delle dipendenze nei
packages. Una cosa così non l'ho trovata, me la son fatta, e ora la uso :)
 
Ciao!

 ha scritto:

Da sempre, utilizzo un motore PHP sviluppato in proprio.
Semplice, veloce, scalabile.
 
 
 

 scegli gli altri componenti da Packagist.
 
Secondo me è proprio il contrario: se uno vuole il controllo non "quasi"
ma totale di quello che succede, l'unica è svilupparsi un motore PHP
in proprio.
 
 
 


 
O prenderne uno e imparare come funziona internamente, che di solito si fa
prima.
Poi oh, se proprio non te ne piace nessuno te ne fai uno, ma è un lavorone.
 
Ciao!


Sicuro?
 
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 


A prescindere da tutto io dico uno disponibile e un minimo diffuso.
Per nessuno dei motivi già trattati, ma sa se domani la mia roba la 
prende in mano un altro, riesce a venirne a capo in modo + o - rapido, 
senza impazzire.
 
Poi qualcuno dirà che sceglie l'opposto proprio per questo motivo ed 
essere indispensabile al cliente, ma non è proprio la mia filosofia di 
vita...
 
-- 
Z.


Il fatto è che deve essere *ben documentato*, indipendentemente dalla
diffusione.
Se oggi è diffusissimo non è detto che tra meno di un anno qualcuno ricordi
neppure il nome. E purtroppo la documentazione dei progetti open è solitamente
assente o decisamente insufficiente..
 
Ciao!

 di uno dei due.
 
Non sono d'accordo, ma mi piacerebbe discuterne.
 
Prima di tutto un po' di bg. Ho sviluppato per anni in ZF1, fin dalla 
0.9, e con la 1.10 ho iniziato a seguire la ml interna di sviluppo, 
perché c'erano voci di una 2.0 che avrebbe rotto col passato, e volevo 
essere pronto (avevo una trentina di siti in produzione con l'1, e penso 
siano ancora lì).
 
L'impressione che ho avuto (e l'ho fatta presente anche in ml) è che 
anche se dichiaravano di non conoscere affatto Java, stessero prendendo 
la stessa strada dei suoi megaframework. ControllerFactoryBuilderInterface 
e compagnia cantante. Quando hanno iniziato a parlare di iniettare 
factories nel componente di configurazione per wrappare ogni opzione ho 
capito l'aria che tirava e ho iniziato a cercare un altro framework. 
Quando ho visto che bisognava editare 4 file diversi, di cui due puri 
"return array()" per definire un controller, ho capito di aver avuto 
ragione.
 
Nel frattempo ho cambiato lavoro e sono finito a usare un framework 
handmade. Per carità, fatto anche abbastanza bene, ma senza 
documentazione, senza un briciolo di estendibilità, con accesso a un solo 
progetto che lo usasse, e in punto di morte visto che usava mysql_connect 
hardcoded ovunque. Complici altri fattori che non mi facevano dormire 
tranquillo la notte, sei mesi dopo mi sono licenziato.
 
Per andare in un posto in cui mi hanno detto "devi fare questo, scegli tu 
cosa usare". Non c'erano ancora le specifiche complete del progetto, 
quindi mi sono preso un paio di settimane per provare diversi fw: ZF2 
(again), Symfony2, Yii, Silex. 
 
Laravel era alla 4 e si parlava di 5, se non ricordo male, con una storia 
di una major version l'anno, quindi l'ho escluso per non trovarmi a 
gestire codebase vecchie prima ancora di iniziare.
 
Una settimana dopo ho scoperto che anche Yii avrebbe presto visto una 
2.0, quindi, a malincuore (perché mi sembrava il migliore) l'ho escluso 
per lo stesso motivo.
 
ZF2, dopo due giorni di prove, non avevo ancora capito come configurare i 
controller. O meglio, mi sembrava stupido che non ci fosse un modo sano 
di mente per farlo. Dando un'occhiata ai componenti che metteva a 
disposizione, poi, mi sono accorto che avevano segato un buon 50% di 
quello che c'era nell'1.x e ho lasciato perdere. E pensare che ho anche 
comprato un manuale apposta...
 
Symfony era quasi alla pari come complicazione (ma più ragionato e 
lineare), ma nel tentativo di farlo funzionare ho trovato il blog di 
Potencier, e mi sono convinto che il tizio sa benissimo di cosa sta 
parlando. Quasi tutto quello che ha messo insieme (router, 
ServiceLocator, YAML, Twig, ecc.) l'ha scritto lui (o ha contribuito 
molto), quindi sì, può sembrare un patchwork, ma è fatto da un sarto coi 
fiocchi. La 1, è vero, era un po' baracca, ma la 2 è un altro pianeta.
 
Ma, come dicevo, era un po' troppo complesso e non sentivo di averne il 
controllo. Faceva troppe cose a modo suo.
 
Silex, di contro, usa i componenti di Symfony, ma è molto più basico. Ha 
un SL/DIC notevole (Pimple), un router molto efficiente, Request e 
Response di Symfony, si integra con Twig o con qualsiasi altro template 
engine (incluso il puro PHP) o con Doctrine (se vuoi appesantirlo 
bene :P). Una documentazione che si legge in due ore. Tre giorni dopo non 
solo avevo un mini-sito di prova funzionante, ma mi ero scritto un 
componente per wrappare PDO e uno per autenticare gli utenti con 
l'ActiveDirectory aziendale (questo è stato il più difficile :P).
 
E prestazioni da paura senza necessità di "pre-cachare le dipendenze".
Sto parlando di richieste AJAX ad API (in rete locale 100Mbit) quasi in 
tempo reale.
 
Possiamo dire che mi sono re-innamorato dei framework. :)
 
Piccola parentesi su Laravel, per dire che sono contento di non averlo 
scelto. Poco più di un anno dopo (oggi) sono uscite un paio di minor per 
la 4, la 5 e ora la 5.1, e si parla di 6 entro fine anno, tutte con 
piccole o grandi incompatibilità con le precedenti. A parte quello, il 
sistema di "Facade" e relativi class_alias() mi ha fatto drizzare i peli 
delle braccia. 
 
Ha qualche idea interessante (l'ORM, per esempio, anche se non l'ho 
approfondito molto, ma l'avevo preso in considerazione come componente 
per Silex), ma credo che i suoi sviluppatori non abbiano capito una cosa 
fondamentale: un framework è come un sistema operativo. Quando esce una 
versione stabile, deve essere stabile per anni, non per mesi.
 
Non puoi rincorrere l'ultima figheria di cui parlano nei forum per dire 
"ecco, io ce l'ho". Devi garantire ai tuoi utenti che tra un anno avranno 
aggiornamenti di sicurezza senza dover riscrivere metà della loro 
applicazione.
 
E ora, se non ti sei ancora stancato, la domanda: perché ritieni ZF2 più 
enterprise-ready di Symfony2?
 
Bye.


 
Come prima cosa scusa se faccio uno <snip> subito ma hai scritto tanto, io
probabilmente scriverò tanto e, tenendo conto di possibili risposte la cosa
diventerebbe ingestibile :) Cerco comunque di dirti quello che penso e di
farti qualche domanda perché il tuo punto di vista m'incuriosce molto.
 
Come seconda parto con una notizia, forse non vera, chissà, l'ho letta ieri sul
loro facebook: a quanto pare Laravel 5.(1/2?) è annunciata com LTS. Forse
si sono resi conto che i problemi che elencavi riguardo al loro framework sono
molto più diffusi di quanto non volessero accettare.
In ogni caso Laravel, come avrai capito, a me non piace per nulla, per una
serie di motivi.. bah, come dire.. non so, non è proprio cosa per me.
 
Passo subito a ZF che conosciamo entrambi meglio. ZF1 l'ho usato un po' anni
e anni fa, e il 2 l'ho cominciato ad usare da qualche tempo.
ZF1 era molto buono, ma era il vero baraccone(TM). ZF2 è, come hai detto te
molto simile alle javerie classiche: gigante e incomprensibile. Ho provato
a capirlo un po' per una settimana e alla fine, in preda alla disperazione,
mi son comprato un libro di uno degli sviluppatori (ho fatto anche un post qui
su icwp a proposito, l'ho appena trovato "Mi devo rimettere in pari.." del
11/07/14) e non solo l'ho capito, sono anche diventato un fan.. fino ad un certo punto, naturalmente: rimane pur sempre una javeria classica.
A dirla tuta, veramente non capisco perché hai trovato tutte queste difficoltà
nel setup di ZF2, visto che Laravel o Symfony sono IMHO più complessi: se
proprio non ci si vuol leggere nulla basta git-clonare lo skeleton della app
del tutorial e partire da lì, con tutto già configurato e settato. Non si
avranno molte cose ma per iniziare un prototipo è più che sufficente.
 
Per quanto riguarda i micro-framework, mi sono dato due rules-of-thumb che di
solito non sbagliano mai: se 1- wrappano le classi d'accesso al DB o 2- in poco
tempo passano alla versione 2 completamente incompatibile con la precendete,
bisogna lasciarli stare; gli sviluppatori sono incompetenti. Per quanto
riguarda il punto uno, tanto per precisare, posso capire un adapter sul PDO
(quello lo faccio anch'io), ma tutta una serie di classi tipo "table" o "row"
assolutamente no: php ha già un layer d'astrazione, scriverne un altro è
follia.
 
Tanto per fare una parentesi, citi Potencier: forse sa quel che dice ma non mi
esprimo sulla sua facciona ammiccante in ogni dove che personalmente a me da
i brividi.
 
Symfony2 è ben strutturato internamente, ma non prevede che il software
costruitovi sopra abbia la stessa caratteristica. Oltretutto spesso complica
oltremodo cose semplici per essere elegante ad ogni costo. PHP prevede di fare
ogni tanto qualche porcheria, a meno di non voler scrivere una tonnellata di
codice, ma Symfony questa cosa sembra non accettarla proprio.
 
Comunque, secondo me non è così enterprise-friendly: non è immediato
organizzarsi per, ad esempio, dividere il lavoro tra vari gruppi, ci
dev'essere sempre qualcuno che da solo tira su una struttura da cui partire.
Con lo ZF2 non si ha proprio scelta (a meno di non aggirare tutto il flow, ma a
quel punto che lo si usa a fare?): le cose si fanno in quel modo e basta, non
ti piace, peggio per te.
 
Per me le caratteristiche di un framework perfetto sono quelle che ho cercato
d'infilare nel mio: un micro framework orientato come lo ZF. Kernel che fa due
scemenze, routing robusto e facile da scrivere, una quantità accettabile di
automagic per fare presto se si struttura bene ma non difficile da ricordare e
sempre aggirabile manualmente, ServiceManager e DI (implicito, naturalmente!)
per gestire e cache-are la creazione d'oggetti in tutta l'applicazione.
Funzioni extra non ne servono: per quelle ci sono migliaia di altri pacchetti
su packagist che uno si sceglie a seconda della situazione.
 
Ciao!

 Sicuro?
 
Per la sicurezza di un applicativo, web o desktop che sia, 
il buon senso di stare attenti nello sviluppo, l'esperienza,
la proattività di applicare tutte le contro misure per i
più comuni attacchi informatici, e altro, bastano e avanzano.
 
 


non ha particolare importanza.
Se è diffuso, a parte che raramente sparisce nel nulla il progetto e 
tutta la knowledge base (come può essere il mare di problemi e soluzioni 
su stack overflow e simili), cmq sarà sempre abbastanza facile trovare 
uno sviluppatore esperto in quel framework.
Il fatto che dopo meno di un anno la gente che lo usava lo abbia 
dimenticato (oltre a smettere tutti assieme di usarlo) è assai poco 
realistico, a meno di attacchi mentali alieni perlomeno ;)
 
Non ho esperienza di progetti non open, quindi magari sarà meglio (a 
sentire i colleghi che lavorano su M$ mi permetto di dubitare, ma non ho 
elementi x giudicare), ma io mi sono sempre trovato + che bene con la 
documentazione e la comunità open.
 
-- 
Z.

 pacchetti su packagist che uno si sceglie a seconda della situazione.
 
Hai mai provato Silex? :D
 
Bye.

 
 
Sì, e lo trovo orribile sotto quasi ogni punto di vista! :D
<IMHO>
- $app. Perché? Cosa mi rappresenta un oggetto che contiene praticamente tutto?
Gli oggetti servono a racchiudere dei concetti, se ne ho uno che devo portarmi
in ogni dove tanto vale usare il namespace globale senza scrivere ogni volta
sei caratteri extra.
- Request/Response sono una boiata. Come forse sai uno dei miei progetti che ho
portato avanti per anni è stato un webserver, chiamato Mojito, scritto
interamente in C. A me Request/Response non danno l'idea di flessibilità o
potenza, danno urto: sono concetti che per il PHP sono e devono rimanere
trasparenti. In uno script, la richiesta ce l'ho avuta, altrimenti non girerei,
GET/POST li prendo con $_GET/$_POST e la risposta è quello che mando in output.
Semplificare una cosa del genere è impossibile. Anche la cosa che rendono più
facile il test per me è un po' 'na cazzata ;)
- Milioni di cose come $app->escape(). Se voglio fare un htmlspecialchars()
faccio htmlspecialchars(). Che bisogno c'è di wrappare funzioni del core?
A pensar bene si può pensare che vogliano solo aumentare i kloc per far vedere
che è tanta roba, a pensar male.. boh!
- function(), function() ->before/after/finish(function()). Un passetto in
più e scrivo direttamente in Javascript.
- tutto il resto è Symfony, per cui c'è un'altra grossa lista di IMHO :)
</IMHO>
 
Ciao!

 - tutto il resto è Symfony, per cui c'è un'altra grossa lista di IMHO :)
 
Basta non usare i pezzi di Symfony oltre a quelli richiesti dal core.
Me ne sono reso conto a mie spese (vedi Form di cui sopra)
 
Il bello, secondo me, è che è quasi il minimo indispensabile, poi i pezzi 
sopra te li scegli (o te li scrivi).
 
Non dico che sia perfetto, ma è il meglio che ho trovato finora.
Prima o poi proverò anche Slim, ma non mi ha colpito particolarmente.
 
Bye.

 
 
Potresti provare il mio, ma già so che abbiamo idee troppo distanti perché
ti possa piacere! ;)
 
Ciao!

 perché ti possa piacere! ;)
 
Mai dire mai. :D
 
Bye.
 

 
 
Anche un parere negativissimo da qualcuno che, come te, ne capisce a mazzi,
sarebbe comunque oro ;)
 
Ciao!

 mazzi, sarebbe comunque oro ;)
 
La mail è valida. :D
Non prometto niente, ma un'occhiata ce la butto volentieri.
 
Bye.

 
 
Beh, è online su: 
http://www.pqwe.org/
 
dove c'è anche un piccolo tutorial, tanto per.
 
Ancora sto cercando di dargli una forma di framework per uso generico, dopo
averlo usato solo io per varie cose, per cui piano piano aggiungo i pezzi che
riesco a staccare e generalizzare dai vecchi progetti ;)
 
Ciao!