Il problema è che gli applicativi o sono fire&forget o tendono a crescere stratificandosi, o partono come F&F e dopo qualche anno te li fanno estendere (meno male che avevo previsto una discreta modularità in partenza :) ). Purtroppo i framework che avevo guardato al tempo mi avrebbero richiesto, per iniziare ad usarli decentemente, più tempo di quello che avevo a disposizione per realizzare l'applicativo...
Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 anni o più), poi regolarmente ci si scontra con incompatibilità (era per PHP5.6, con 8.1 quella versione non funziona più e devi mettere la nuova, che però ha un'API diversa e finisci per dover riscrivere tutto o peggio ti introduce dei bug subdoli), catene di dipendenze infinite (con relativi problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello che "sa programmare il web") non conosce quel framework perché troppo vecchio e fuori moda e quindi comunque deve studiarlo da zero.
Per non parlare di un problema di sicurezza: un bug nel framework ti lascia esposto a molti più attacchi automatici.
Diego Il 16/05/2023 12:56, Giuseppe Naponiello ha scritto:
oddio che bello, non sono solo!!!Nel mio caso, lavorando tanto con i db, ho visto (ma potrei sbagliarmi) che i vari framework sfruttano davvero poco le potenzialità di un db come postgresql o anche solo mysql...ma ripeto, sarà perché non conosco a fondo le potenzialità di un framework come laravelIl 16/05/23 11:47, Diego Zuccato ha scritto:Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi sono ritrovato che era insufficiente o troppo pesante per le mie esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a capire come usarlo sarebbe già stato obsoleto).Visto che lo sviluppo di applicativi web è per me molto secondario, ho finito per crearmi negli ultimi 15 anni il mio carrozzone di classi che alla fine è compatibile con tutto (da 5.6 a 8.1) :) Sarebbe però interessante un confronto dei vari framework maturi in circolazione.Diego Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto:Ciao Lorenzo,Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework)Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da modificare!!!La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome.Passando i dati (e il file) via FormData() non mi sembrava fosse necessario specificare l'enctype del form, comunque molto interessante, approfondisco!Grazie Il 16/05/23 10:44, Lorenzo Breda ha scritto:Il lun 15 mag 2023, 17:04 Giuseppe Naponiello <beppenapo@gmail.com> ha scritto:Il problema è che non trovo una soluzione per caricare un file dainterfaccia web in una cartella del server: con fetch API e formData mando il file da caricare al server, che con un funzione php dovrebbespostarlo da tmp alla destinazione finale con la classica funzione "move_upload_file", l'errore, come previsto, è che php cerca il file da spostare in /tmp/ e non in systemd.... Buongiorno,Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella temporanea invece di quella reale è un effetto ottico di systemd, in realtà legge e scrive correttamente in quella giusta.La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome.Buona giornata! -- Lorenzo Breda
-- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786