Newsgroup: it.comp.www.php
Titolo: framework: dove mettere i file di log

Sto facendo un mio framework, ma non so dove collocare i file di log, in 
cui vengono registrati: accessi, operazioni di debug, errori, ecc.
 
1. framework/app/logs/*.log ?
2. framework/logs/*·log ?
3. framework/data/logs/*·log ?
 
Forse l'unica soluzione da non considerare è la 1, perchè app/ e lib/ 
dovrebbero essere directory di sola lettura; dovrebbero cioè contenere 
solo i sorgenti (file php), o altri tipi di file modificabili solo 
manualmente (da parte dello sviluppatore).
 
Cosa ne pensate?

 cui vengono registrati: accessi, operazioni di debug, errori, ecc.
 
Framework o CMS?
 
Se è un framework, non sta a te decidere dove salvare i log. Dovresti 
creare un oggetto logger che l'utente può configurare per definire dove e 
come salvare i log. O usare qualcosa già pronto tipo Monolog.
 
Se è un CMS, dipende dalla struttura del resto del CMS.
 
Bye.

 Cosa ne pensate?
Che fare un proprio framework è puerile
Studiane uno già fatto e buono
 
-- 
Lesso e pearà


Certo dopo mesi di lavoro, butto tutto nell'immondizia.


Ma che scherziamo, buttane almeno altrettanti
 
-- 
I fatti mi cosano

 come salvare i log.
 
Certamente, ma come valore predefinito... alla fine app/logs credo che 
dovrebbe andar bene.
 

 Ma che scherziamo, buttane almeno altrettanti
 
L O L

Il 11/07/2013 18:37, one4all ha scritto:

sono curioso di sapere perchè con decine di framework esistenti dal più 
snello al più completo, non sei riuscito a trovare quello che ti si 
adatta e hai dovuto scrivertelo??
 
posso capire per uso didattico, ma per uso professionale reinventare la 
ruota booooo.
soprattutto un FW esistente ti mette sostanzialmente al riparo da 
eventuali buchi del FW stesso dato che ci lavorano aziende e community 
che eventualmente ne sanno più di te/me e tappano le falle in tempi 
rapidi, non contando gli aggiornamenti stessi del FW.
 
Ciao

 dovrebbe andar bene.
 
Come valore predefinito io userei questa:
 
http://php.net/manual/en/function.sys-get-temp-dir.php
 
 
o, ancora meglio, questa:
 
http://php.net/manual/en/function.syslog.php
 
 
Bye.

 
http://php.net/manual/en/function.syslog.php
 
 
Perdonami la domanda forse sciocca, ma i messaggi di log dove vengono 
memorizzati, in quale file?
Da quanto ho capito vengono semplicemente distribuiti al logger di 
sistema, quindi?

 sistema, quindi?
 
Esatto. Poi dipenderà dalla configurazione del logger di sistema dove 
mandarli.
 
Come dicevo, se un framework deve lanciare errori, questi si considerano 
errori di sistema.
Se gli errori derivano da l'uso che viene fatto del framework, sarà 
l'utente del framework (cioè il programmatore che lo usa, non l'utente 
generico con un browser) a decidere dove e come salvare questi errori.
 
Ma concordo con quello che hanno detto gli altri. Butta via tutto, magari 
un po' alla volta, e passa a un framework open source.
 
Scriversi un framework oggi lo si fa per due motivi:
 
- imparare come scrivere un framework. E poi buttare via tutto.
 
- casi molto particolari (devi gestire un tipo particolare di 
connessioni, magari con header non standard. O devi massimizzare le 
prestazioni in un contesto molto ristretto (embedded o simili)) che non 
mi pare sia il tuo caso.
 
Bye.

 rapidi, non contando gli aggiornamenti stessi del FW.
 
Sono curioso di sapere perchè con tanti programmi di fotoritocco, dal 
più  snello al più completo, google ha deciso di crearsi da se i suoi 
software per creare le mappe geografiche...


E permettimi di farti notare che se paragoni un framework a un programma 
non hai capito molto di programmazione



La prima ok, la seconda proprio no
I framework HMVC permettono di fare override di qualsiasi componente
La risposta per la velocità è cachare il possibile, magari usare ESI o 
proprio un reverse proxy, cambiare layer di persistenza ....
Sono compiti dove serve lavorare talmente di fino che dover pensare 
anche a tutta la struttura sotto per farla bene diventa una perdita di 
tempo folle
In casi davvero estremi più che un framework ha senso scrivere codice 
procedurale IMHO


 layer di persistenza ....
 
Stai sempre parlando di siti classici.
 
Ti faccio un esempio pratico che mi è capitato di recente (ma poi non è 
andato in porto). Dovevo fare un servizio REST con diverse decine di 
chiamate che dovevano fare ognuna ben poco su un certo numero di tabelle 
in DB.
 
Symfony2 e ZendFramework2 hanno un overhead assurdo per ogni chiamata, 
quindi li ho scartati.
 
Silex e Slim vogliono che definisca come callback ogni route, che mi dà 
veramente fastidio perché se le ricarica tutte a ogni request anche se 
poi ne usa una sola.
 
Allora sono partito a fare un mio microframework che parsa la request, 
solo i campi che mi servono, splitta il path, istanzia il controller, lo 
richiama e si fa dare l'output in una response che poi stampa in json.
 
Totale di 5 oggetti istanziati (il frontcontroller, la request, la 
response, il controller "vero" e la sua classe abstract con i metodi 
"helper"). Più il model, il suo abstract e PDO/Mongo, che fanno 8 (10 per 
Mongo), quando devo accedere al DB.
 
Tutto modulare, tutto sostituibile al bootstrap, tutto iniettato e 
isolato.
 
Certo, funziona solo su Linux, solo su Apache con mod-php e senza reverse 
proxy, solo con postgres, ecc. ecc., ma è voluto. Voglio supportare MySQL? 
Cambio l'abstract del model. Voglio nginx? Cambio la request. Voglio 
supportare IIS su Windows? No. :P
 
Ma il codice è piccolo, snello, non deve gestire casi che non capiteranno 
mai, non ha complesse regexp per parsare le request. E` poco più che 
procedurale, ma rispettando le interface (anche se non dichiarate per 
risparmiare include) è completamente modulare.
 
In casi come questi non puoi cachare (REST è per definizione stateless, e 
fai un webservice per dare dati sempre aggiornati) e, a meno di non 
tornare a pgsql_connect, più di così non puoi ottimizzare la persistenza.
 
Non ci sono (per definizione) framework più veloci o più adatti, in 
questo caso.
 
Ma è un caso molto particolare, come dicevo.
 
Bye.

 mi pare sia il tuo caso.
 
Oppure avere una visione onniscente del FW che hai sotto mano: le cose 
che si fanno da se, si conoscono al 100% e anche oltre :-b
 

 non hai capito molto di programmazione
 
E permettimi di rispondere che anche google avrà il suo/suoi framework 
realizzato autonomamente; eppure di FW c'è ne sono parecchi già fatti...
Forse questo paragone ti piace di più?
 
Ad ogni modo, come più o meno ho detto poco fa in un altro post, ognuno 
è libero di realizzare i suoi progetti, come meglio crede.


 
 



Assolutamente vero
Guarda, tu sollevi il problema che sembriamo essere dei gerarchi
Stai fraintendendo la questione.
Qui ci sono molti che come me hanno qualche anno di carriera sulle 
spalle e se scrivi in questo NG è perché ti vuoi confrontare con chi 
questo linguaggio lo usa, possibilmente a livello professionale
 
Ai _bei_ tempi di php4 ogni $sagaceProgrammatore faceva il proprio CMS, 
poi è arrivata l'ora di fare il proprio 
$frameworkCheFaMoltoPiuFigoCheChiamarloCMS
Quello che stai facendo tu non è né nuovo, né groundbreaking. L'abbiamo 
fatto tutti più e più volte e siamo sempre (o quasi) arrivati a buttare 
quel codice nel cestino o ad andare avanti con codice ridicolo, 
obsoleto, insicuro (il mercato ne è ancora pieno)
 
Può essere che tu trovi un cliente che con un framework fanciullesco ti 
permette di fatturare bene per una vita, questo vuol dire che hai 
trovato un gonzo, non che sei bravo o che hai fatto bene
 
Se lo stai facendo per scopi didattici ti consiglio comunque di evitare 
di fartene uno tuo e invece di studiare approfonditamente Symfony2: è la 
scopiazzatura di spring e implementa alcuni dei migliori approcci 
architetturali
Se guardi bene Symfony2 sta diventando uno standard de facto
ezPublish viene riscritto in Symfony2 in questi mesi, Joomla pure, 
Drupal ne userà (male come sempre) alcuni componenti ....
 
Se la ezSystems ha pensato di buttare letteralmente a mare la codebase 
che tiene su siti come quelli di tutto il gruppo Mondadori (per fare un 
esempio) e di migrare su Symfony2 ci sarà un motivo
Per inciso anche loro hanno valutato la possibilità di scriversi un 
proprio framework, scartando la possibilità (e loro sono quelli che 
hanno fatto gli
In ezSystems lavora gente bravina, e non uno solo. Per capirdci sono 
quelli che oltre ad ezpublish hanno fatto gli 
http://ezcomponents.org/
 
che ormai sembrano preistoria, ma ai tempi erano buone librerie
 
Ora, se tu pensi di essere lo Sheldon Cooper di turno vai avanti e 
mostraci che il tuo framework fa impallidire qualsiasi altra cosa ci sia 
sul mercato
Se è migliore, ma non vuoi mostrarcelo vai avanti a benedire i tuoi 
clienti con un codice così stupendo
In ogni caso puoi fare quello che più ti aggrada, siamo ansiosi di 
osannare il tuo codice se avrai voglia di mostrarcelo
Siamo ansiosi di osannare anche il codice di altri 1000 che son venuti 
prima di te, ma finora ...


 che si fanno da se, si conoscono al 100% e anche oltre :-b
 
Sì, è vero. Il problema è che tu hai solo due occhi e un tot numero di 
visitatori, magari poco stronzi, sul tuo server, mentre un fw, 
soprattutto quelli opensource, ha qualche centinaio di migliaia di occhi 
che guardano sia il sorgente che i log dei propri server, da cui arrivano 
miliardi di connessioni con migliaia di stronzi che cercano di sfondarli.
 
E` una semplice questione di numeri: i framework pubblici sono più 
"audited" di quelli fatti in casa.
 
Se dalla tua hai il vantaggio (illusorio) che non vedendo il codice non 
possono sfruttarne i bug, dall'altra hai che magari non hai considerato 
tutte le possibilità di abuso del normale protocollo HTTP.
 
Per esempio: hai mai letto, da cima a fondo, le RFC 1945 e 2616?
 
Bye.


 
Dunque il tuo discorso lo condivido appieno, però alla fine tendi sempre 
a snobbare il lavoro altrui...
Ripeto, hai ragione, seguirò magari i tuoi consigli, ma se si potrebbero 
contenere certi atteggiamenti snobistici, specialmente nei confronti di 
chi ha meno esperienza, farebbe un po' più piacere IHMO.


Mi sa che ancora faccio fatica a farmi capire pienamente
Non è snobismo: io fra l'altro sono un autodidatta laureato in materie 
umanistiche. Non avrei veramente motivo di essere snob
Inoltre io sono uno di quelli che "Cut the crap, show the code" e lì finisce
 
Il fatto è che davvero ci siamo passati tutti per il CMS/Framework de 
noantri e sappiamo che ci si sbatte la faccia. Prendilo come un 
consiglio alle nuove leve (almeno in ambito php)
 
Non so se per inesperienza o altro, ma hai toccato uno di quei tasti che 
ormai sono logori per il troppo uso (il nuovo framework) e alcune 
domande che hai fatto qui nel NG erano al limite della trollata, o 
almeno lo sembravano
Se hai ricevuto risposte un pelo più accese penso sia a causa di questi 
motivi. Se ti sei offeso scusa, non era mia intenzione


Il 12/07/2013 11:19, one4all ha scritto:

posso assicurarti che la mia non voleva essere un offesa o provocazione, 
se interpretata in questa maniera mi spiace, ero semplicemente curioso.
 
come gia altri ti hanno detto, anche io all'inizio della mia avventura 
in php dopo aver preso un pò di dimestichezza con il linguaggio, ho 
provato a scrivermi il mio piccolo FW, un paio di classi che 
implementassero un embrione di pattern MVC, con l'autoload dei file e 
l'istanziamento automatico delle relativa classi, nulla di più (questo 
mentre scrivevo il mio primo progetto, anzi possiamo dire che il FW e il 
progetto coincidessero).
ma poi mi sono reso conto che era un bagno di sangue e che il mio FW non 
rispondeva alle esigenze successive, a quel punto mi sono orientato su 
FW che si possano definire tale, ho iniziato con cakePHP (all'epoca uno 
dei pochi e forse il più documentato), oggi utilizzo ZendFramework 1 e 2
 
Ciao