Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
esempio controllo se data compresa fra 2 date in php
1,321 views
Skip to first unread message
tmtube
Nov 22, 2012, 7:16:51 PM11/22/12
to
avrei necessità di uno script del tipo:
se data maggiore uguale di data1 e minore uguale di data2 allora carica
pagina1 altrimenti carica pagina2
per voi semplicissimo ma per me che non conosco bene la sintassi è un
problema
qualcuno a un esempio?
grazie.
se data maggiore uguale di data1 e minore uguale di data2 allora carica
pagina1 altrimenti carica pagina2
per voi semplicissimo ma per me che non conosco bene la sintassi è un
problema
qualcuno a un esempio?
grazie.
RedWiz
Nov 23, 2012, 4:00:07 AM11/23/12
to
On Fri, 23 Nov 2012 01:16:51 +0100, tmtube wrote:
> avrei necessità di uno script del tipo:
>
> se data maggiore uguale di data1 e minore uguale di data2 allora carica
> pagina1 altrimenti carica pagina2
if($data >=$data1 && $data <=$data2 ){
> avrei necessità di uno script del tipo:
>
> se data maggiore uguale di data1 e minore uguale di data2 allora carica
> pagina1 altrimenti carica pagina2
include('pagina1.php');
} else {
include('pagina2.php');
}
> qualcuno a un esempio?
^^^
Marco Albarelli (fu Motosauro) @fisso
Nov 23, 2012, 5:20:42 AM11/23/12
to
:D
@OP
ti dò una dritta che non è così ovvia
Per confrontare date la cosa più semplice è trasformarle in Unix
Timestamp, ossia il numero di secondi passati dalle 00:00 del 1/1/1970
Tutti i sistemi e linguaggi hanno metodi semplici per trasformare una
data in quell'intero, ovviamente anche PHP
Ciao
--
I fatti mi cosano
tmtube
Nov 24, 2012, 9:00:48 PM11/24/12
to
Qualcosa in questo script non quadra, qualcuno sa dirmi dove sbaglio in
questo controllo di date? Grazie.
***** Code *******
<?php
$data =(date("d-m-y"));
$data1="24/12/12";
$data2="26/12/12";
if($data >=$data1 && $data <=$data2 ){
include('pagina1.php');
} else {
include('pagina2.php');
}
***** END Code *******
questo controllo di date? Grazie.
***** Code *******
<?php
$data =(date("d-m-y"));
$data1="24/12/12";
$data2="26/12/12";
if($data >=$data1 && $data <=$data2 ){
include('pagina1.php');
} else {
include('pagina2.php');
}
Andrea D'Amore
Nov 25, 2012, 3:28:21 AM11/25/12
to
In article <50b17bd0$0$13270$4faf...@reader2.news.tin.it>,
ottieni e cosa ti aspettavi invece.
> $data =(date("d-m-y"));
> $data1="24/12/12";
> $data2="26/12/12";
Chiedi una formattazione con il trattino e poi usi la barra diagonale
per le stringhe che assegni, il '/' sarà sempre minore di '-' puoi
divertirti a cercare il problema nei giorni 24 e 26.
> if($data >=$data1 && $data <=$data2 ){
Se vuoi individuare un giorno può anche andare, se vuoi controllare se
una data è tra un intervallo usa un formato che sia ordinato
alfabeticamente, come 'Y-m-d'.
> include('pagina1.php');
> } else {
> include('pagina2.php');
> }
Non hai il tag di chiusura.
"tmtube" <tmt...@email.it> wrote:
> Qualcosa in questo script non quadra, qualcuno sa dirmi dove sbaglio in
> questo controllo di date?
Dipende da quello che intendi fare, avresti dovuto indicare che errore
> Qualcosa in questo script non quadra, qualcuno sa dirmi dove sbaglio in
> questo controllo di date?
ottieni e cosa ti aspettavi invece.
> $data =(date("d-m-y"));
> $data1="24/12/12";
> $data2="26/12/12";
per le stringhe che assegni, il '/' sarà sempre minore di '-' puoi
divertirti a cercare il problema nei giorni 24 e 26.
> if($data >=$data1 && $data <=$data2 ){
una data è tra un intervallo usa un formato che sia ordinato
alfabeticamente, come 'Y-m-d'.
> include('pagina1.php');
> } else {
> include('pagina2.php');
> }
Alessandro Pellizzari
Nov 25, 2012, 3:42:33 AM11/25/12
to
Il Sun, 25 Nov 2012 03:00:48 +0100, tmtube ha scritto:
> Qualcosa in questo script non quadra, qualcuno sa dirmi dove sbaglio in
> questo controllo di date?
Che stai confrontando stringhe, non date.
> Qualcosa in questo script non quadra, qualcuno sa dirmi dove sbaglio in
> questo controllo di date?
Devi usare mktime per creare una rappresentazione numerica delle date
oppure la classe DateTime (che poi non fa altro che trasformare le date
nella stessa rappresentazione per i confronti)
$data = time();
$data1 = mktime(0,0,0,12,24,2012);
$data2 = mktime(0,0,0,12,26,2012);
if ($data >= $data1 && $data <= $data2 ){
Bye.
Marco Albarelli (fu Motosauro) @fisso
Nov 25, 2012, 11:56:43 AM11/25/12
to
Io se non sono obbligato no, così se c'è testo spurio salta subito
all'occhio fra le altre cose
Mi pare fosse anche una best-practice, ma non riesco a ritrovare dove
l'avevo letto
Marco Albarelli (fu Motosauro) @fisso
Nov 25, 2012, 11:57:51 AM11/25/12
to
pulce nell'orecchio
L'operazione <= >= col testo non funzionano come con gli interi
il timestamp identifica un momento preciso nel tempo (la data che ti
interessa) e la trasforma in un intero, ossia il numero di secondi
passati da una certa data definita per standard (l'1/1/1970)
Essendo numeri interi è molto più semplice confrontarli e a quel punto
gli operatori <= e >= tornano a comportarsi come credo tu ti aspetti
Andrea D'Amore
Nov 25, 2012, 1:49:06 PM11/25/12
to
In article <k8tik8$1fv$1...@speranza.aioe.org>,
"Marco Albarelli (fu Motosauro) @fisso " <moto...@gmail.com> wrote:
> Tu lo usi?
No, ma non uso molto PHP.
> Io se non sono obbligato no, così se c'è testo spurio salta subito
> all'occhio fra le altre cose
In che senso testo spurio? Anche se hai del testo spurio prima del tag
di chiusura te ne accorgi perché avrai un errore.
> Mi pare fosse anche una best-practice,
Certo che creare i delimitatori e poi invitare a non usare quello finale
è una bella prova di coerenza.
"Marco Albarelli (fu Motosauro) @fisso " <moto...@gmail.com> wrote:
> Tu lo usi?
No, ma non uso molto PHP.
> Io se non sono obbligato no, così se c'è testo spurio salta subito
> all'occhio fra le altre cose
di chiusura te ne accorgi perché avrai un errore.
> Mi pare fosse anche una best-practice,
è una bella prova di coerenza.
Andrea D'Amore
Nov 25, 2012, 1:49:46 PM11/25/12
to
In article
<anddam+groupsNOALPASTICCIOD...@news.cu.mi.it>,
Errore: intendo dire che sì, uso il tag di chiusura.
<anddam+groupsNOALPASTICCIOD...@news.cu.mi.it>,
Errore: intendo dire che sì, uso il tag di chiusura.
Marco Albarelli (fu Motosauro) @laptop
Nov 26, 2012, 3:46:06 AM11/26/12
to
pensata, ragionata. È andato avanti un po' come capitava e in base a
cosa serviva agli sviluppatori
Di fatto il tag di chiusura nasce storicamente per permettere di fare
embed del codice dentro l'HTML
Con testo "spurio" intendo come caso tipico caratteri dopo il tag di
chiusura in file inclusi da qualche parte che finiscono per emettere
testo, portando al famoso problema dell'impossibilità di emettere gli
header perché del contenuto è già stato trasferito (giusto un esempio)
Se non metti il tag di chiusura e lasci testo in giro come giustamente
sottolinei hai un errore a runtime che ti indica il posto dove andare a
correggere
Questioni sostanzialmente stilistiche, niente di che
Ciao
M
--
I cosi mi fattano
Andrea D'Amore
Nov 26, 2012, 8:33:30 AM11/26/12
to
In article <k8va8d$1jd$1...@speranza.aioe.org>,
tipico è proprio con il codice embedded, secondo me ci vorrebbe uno
stacco nella compatibilità e questo non dovrebbe essere proprio
permesso, i file PHP usano il linguaggio PHP e basta.
"Marco Albarelli (fu Motosauro) @laptop" <moto...@gmail.com> wrote:
> Eh, purtroppo PHP ha avuto una genesi tutt'altro che pulita, coerente,
> pensata, ragionata. È andato avanti un po' come capitava e in base a
> cosa serviva agli sviluppatori
Lo so, ed è un aspetto che non mi piace. Oltre al fatto che l'approccio
> Eh, purtroppo PHP ha avuto una genesi tutt'altro che pulita, coerente,
> pensata, ragionata. È andato avanti un po' come capitava e in base a
> cosa serviva agli sviluppatori
tipico è proprio con il codice embedded, secondo me ci vorrebbe uno
stacco nella compatibilità e questo non dovrebbe essere proprio
permesso, i file PHP usano il linguaggio PHP e basta.
Alessandro Pellizzari
Nov 26, 2012, 9:46:42 AM11/26/12
to
Il Mon, 26 Nov 2012 14:33:30 +0100, Andrea D'Amore ha scritto:
> Lo so, ed è un aspetto che non mi piace. Oltre al fatto che l'approccio
> tipico è proprio con il codice embedded, secondo me ci vorrebbe uno
> stacco nella compatibilità e questo non dovrebbe essere proprio
> permesso, i file PHP usano il linguaggio PHP e basta.
Se hanno intenzione di togliere l'embed di PHP dai template, fammelo
> Lo so, ed è un aspetto che non mi piace. Oltre al fatto che l'approccio
> tipico è proprio con il codice embedded, secondo me ci vorrebbe uno
> stacco nella compatibilità e questo non dovrebbe essere proprio
> permesso, i file PHP usano il linguaggio PHP e basta.
sapere che cerco un altro linguaggio di programmazione web. :P
Bye.
Marco Albarelli (fu Motosauro) @fisso
Nov 26, 2012, 2:09:58 PM11/26/12
to
metterei a piangere
Se poi fosse twig sarei pure contento
Uso un bel po' wordpress perché è diffusissimo e per i clienti piccoli
va bene, ma che sia bello andare avanti di
<?=$qualcosa;?>
no
Quantomeno non per i miei gusti
M
Andrea D'Amore
Nov 26, 2012, 2:37:14 PM11/26/12
to
In article <k90eq3$ujf$1...@speranza.aioe.org>,
Secondo me bene separare i contesti renderebbe migliore la comprensione
del meccanismo di funzionamento di una applicazione web, cioè il file
passato all'interprete PHP dovrebbe permettere solo codice al suo
interno e i file di template invece dovrebbero essere interpretato se
passato ad un motore, integrato nel linguaggio o disponibile libreria
esterna che si voglia. E addio ai tag di apertura e chiusura nella
logica.
"Marco Albarelli (fu Motosauro) @fisso " <moto...@gmail.com> wrote:
> Beh, se obbligassero ad usare un sistema di templating io non è che mi
> metterei a piangere
> Se poi fosse twig sarei pure contento
Il punto è che con PHP hai un templating implicito.
> Beh, se obbligassero ad usare un sistema di templating io non è che mi
> metterei a piangere
> Se poi fosse twig sarei pure contento
Secondo me bene separare i contesti renderebbe migliore la comprensione
del meccanismo di funzionamento di una applicazione web, cioè il file
passato all'interprete PHP dovrebbe permettere solo codice al suo
interno e i file di template invece dovrebbero essere interpretato se
passato ad un motore, integrato nel linguaggio o disponibile libreria
esterna che si voglia. E addio ai tag di apertura e chiusura nella
logica.
Alessandro Pellizzari
Nov 27, 2012, 4:42:11 AM11/27/12
to
Il Mon, 26 Nov 2012 20:09:58 +0100, Marco Albarelli (fu Motosauro) @fisso
ha scritto:
> Uso un bel po' wordpress perché è diffusissimo e per i clienti piccoli
> va bene, ma che sia bello andare avanti di <?=$qualcosa;?>
> no
Perché no?
Cosa ha di diverso da <% qualcosa %> o da {qualcosa}?
Le prestazioni. Se usi PHP e` un missile. Se usi un sistema di templating
appena cresce un po' il traffico devi mettere una cache, e arrivi a un
punto in cui puoi mettere una cache a un template PHP ma per usare un
motore esterno non ti basta più e devi passare a un secondo server.
E il dover imparare un linguaggio nuovo solo per i template.
Sto pensando non solo ai placeholder, ma anche a condizioni e cicli.
In più hai la possibilità (e la responsabilità, naturalmente) di usare
qualcosa di più complesso nel caso ti serva.
Se poi i tramaccioni ne abusano, sono cavoli loro. Nessuno sano di mente
metterà mano al loro codice, e quando si troveranno a modificarlo saranno
comunque cavoli loro (o del poveraccio che viene assunto e pagato per
sistemare i casini, ma vuol dire che verrà pagato più a lungo. :)
Bye.
ha scritto:
> Uso un bel po' wordpress perché è diffusissimo e per i clienti piccoli
> va bene, ma che sia bello andare avanti di <?=$qualcosa;?>
> no
Cosa ha di diverso da <% qualcosa %> o da {qualcosa}?
Le prestazioni. Se usi PHP e` un missile. Se usi un sistema di templating
appena cresce un po' il traffico devi mettere una cache, e arrivi a un
punto in cui puoi mettere una cache a un template PHP ma per usare un
motore esterno non ti basta più e devi passare a un secondo server.
E il dover imparare un linguaggio nuovo solo per i template.
Sto pensando non solo ai placeholder, ma anche a condizioni e cicli.
In più hai la possibilità (e la responsabilità, naturalmente) di usare
qualcosa di più complesso nel caso ti serva.
Se poi i tramaccioni ne abusano, sono cavoli loro. Nessuno sano di mente
metterà mano al loro codice, e quando si troveranno a modificarlo saranno
comunque cavoli loro (o del poveraccio che viene assunto e pagato per
sistemare i casini, ma vuol dire che verrà pagato più a lungo. :)
Bye.
Marco Albarelli (fu Motosauro) @fisso
Nov 27, 2012, 4:54:28 AM11/27/12
to
Il 27/11/2012 10:42, Alessandro Pellizzari ha scritto:
> Il Mon, 26 Nov 2012 20:09:58 +0100, Marco Albarelli (fu Motosauro) @fisso
> ha scritto:
>
>> Uso un bel po' wordpress perché è diffusissimo e per i clienti piccoli
>> va bene, ma che sia bello andare avanti di <?=$qualcosa;?>
>> no
>
> Perché no?
> Cosa ha di diverso da <% qualcosa %> o da {qualcosa}?
>
da <%qualcosa%> siamo d'accordo, ma da {{qualcosa}} direi di sì, non
> Il Mon, 26 Nov 2012 20:09:58 +0100, Marco Albarelli (fu Motosauro) @fisso
> ha scritto:
>
>> Uso un bel po' wordpress perché è diffusissimo e per i clienti piccoli
>> va bene, ma che sia bello andare avanti di <?=$qualcosa;?>
>> no
>
> Perché no?
> Cosa ha di diverso da <% qualcosa %> o da {qualcosa}?
>
parlo in termini di prestazione, parlo in termini di manutenibilità del
codice
Dato che sono un freelance per me è molto importante lasciare il cliente
con un codice che sia mantenibile anche da uno che non si sia smazzato
sei mesi di lettura di spaghetti code
Che i template engine pesino siamo d'accordo, ma secondo me non pesano
quanto dici tu e comunque sia rendono il codice più mantenibile
Del resto anche l'OOP è orientata solo ad una maggiore manutenibilità da
parte degli esseri umani
Una macchina col procedurale ci sguazza
> Le prestazioni. Se usi PHP e` un missile. Se usi un sistema di templating
> appena cresce un po' il traffico devi mettere una cache, e arrivi a un
> punto in cui puoi mettere una cache a un template PHP ma per usare un
> motore esterno non ti basta più e devi passare a un secondo server.
>
> E il dover imparare un linguaggio nuovo solo per i template.
>
> Sto pensando non solo ai placeholder, ma anche a condizioni e cicli.
>
> In più hai la possibilità (e la responsabilità, naturalmente) di usare
> qualcosa di più complesso nel caso ti serva.
>
templating si usi
Twig è molto rapido e ha un suo sistema di caching
Il peggio credo sia il vecchio sistema di ezPublish che sommava il
peggio di entrambi gli approcci, tant'è che l'hanno buttato a mare e con
la 5.x si passa a twig
> Se poi i tramaccioni ne abusano, sono cavoli loro. Nessuno sano di mente
> metterà mano al loro codice, e quando si troveranno a modificarlo saranno
> comunque cavoli loro (o del poveraccio che viene assunto e pagato per
> sistemare i casini, ma vuol dire che verrà pagato più a lungo. :)
Non infierire ti prego
>
> Bye.
Andrea D'Amore
Nov 27, 2012, 6:26:38 AM11/27/12
to
In article <ahjg7j...@mid.individual.net>,
Ma il fatto di poter integrare codice del linguaggio con il codice HTML
mi sembra una soluzione "sporca". Il fatto di lasciare tanta libertà
all'utente è come dargli tanta corda e poi se si impicca dire "sono
fatti suoi".
> E il dover imparare un linguaggio nuovo solo per i template.
> Sto pensando non solo ai placeholder, ma anche a condizioni e cicli.
Per questo suggerivo un motore che usasse la stessa sintassi del
linguaggio che lo usa.
Tir [1], che è scritto in Lua, usa una soluzione simile usando proprio
Lua nel motore di templating.
[1] http://tir.mongrel2.org
Alessandro Pellizzari <shur...@amiran.it> wrote:
> Cosa ha di diverso da <% qualcosa %> o da {qualcosa}?
Niente.
> Cosa ha di diverso da <% qualcosa %> o da {qualcosa}?
Ma il fatto di poter integrare codice del linguaggio con il codice HTML
mi sembra una soluzione "sporca". Il fatto di lasciare tanta libertà
all'utente è come dargli tanta corda e poi se si impicca dire "sono
fatti suoi".
> E il dover imparare un linguaggio nuovo solo per i template.
> Sto pensando non solo ai placeholder, ma anche a condizioni e cicli.
linguaggio che lo usa.
Tir [1], che è scritto in Lua, usa una soluzione simile usando proprio
Lua nel motore di templating.
[1] http://tir.mongrel2.org
Alessandro Pellizzari
Nov 27, 2012, 8:17:47 AM11/27/12
to
Il Tue, 27 Nov 2012 10:54:28 +0100, Marco Albarelli (fu Motosauro) @fisso
ha scritto:
> non
> parlo in termini di prestazione, parlo in termini di manutenibilità del
> codice
Penso sarai d'accordo che la manutenibilità del codice dipende da
altro. :)
OK che una stringa {{var}} è gestita meglio da sistemi come Dreamweaver,
ma per mia esperienza difficilmente riesci a dare in mano a un cliente i
template da modificare.
Non tanto per la difficoltà dell'HTML, ma perché ormai non mi succede da
oltre 4 anni di avere tutto in un singolo file.
E` tutto sparso in diverse partial view, che vengono montate dai
controller a seconda di cosa deve apparire. E sempre più spesso l'HTML è
talmente generico che fanno tutto i CSS.
La "vecchia" figura del webmaster (o come lo chiamavano) che sapeva un
po' di grafica, un po' di Dreamweaver e un po' di HTML non saprebbe
nemmeno dove iniziare a metterci mano.
> Dato che sono un freelance per me è molto importante lasciare il
> cliente con un codice che sia mantenibile anche da uno che non si sia
> smazzato sei mesi di lettura di spaghetti code
Io ho fatto solo un paio di siti da freelance, ma in entrambi i casi non
ho lasciato il codice al cliente. Gli ho dato la disponibilità di un dump
del DB e delle immagini, ma il codice rimane comunque mio, perché
utilizza componenti che ho costruito nel tempo, e che uso per tutti i
miei progetti.
Se dovessi dargli anche la disponibilità del sorgente dovrei farlo pagare
almeno il triplo. Una volta per il lavoro, una volta per il codice che
diventa suo, e una terza perché dovrei fargli tutti i template "stupid
proof". :)
> Che i template engine pesino siamo d'accordo, ma secondo me non pesano
> quanto dici tu e comunque sia rendono il codice più mantenibile
> Del
> resto anche l'OOP è orientata solo ad una maggiore manutenibilità da
> parte degli esseri umani Una macchina col procedurale ci sguazza
OK, ma la differenza, secondo me, non giustifica il peso.
Programmare OOP fornisce un'astrazione e una possibilità di
"componentizzazione" che è impossibile raggiungere con la programmazione
procedurale, a meno di non avere funzioni con nomi lunghissimi (qualcuno
ha detto ObjectiveC? :P)
Usare un template engine invece di semplici view con PHP embedded (e
autolimitandosi sui tag) non offre nessun vantaggio, ma solo svantaggi.
Naturalmente non parlo di infilare connessioni al DB o richiami alla cache
nelle view. Parlo di un motore di view alla Zend_View.
>> Se poi i tramaccioni ne abusano, sono cavoli loro. Nessuno sano di
>> mente metterà mano al loro codice, e quando si troveranno a modificarlo
>> saranno comunque cavoli loro (o del poveraccio che viene assunto e
>> pagato per sistemare i casini, ma vuol dire che verrà pagato più a
>> lungo. :)
> Mi viene da piangere .... :'(
> Non infierire ti prego
OK, spero di non aver già infierito troppo qui sopra. :D
Ma permettimi di aggiungere che se uno è incapace (sia nel senso "non è
ancora capace" che nel senso "non sarà mai capace") inizierà dritto
mettendo l'html dentro i print/echo.
Un motore di templating come twig o smarty sarà solo uno scoglio in più
che non farà altro che rallentare il suo apprendimento.
Lo so perché è successo a me! :)
Ai tempi in cui tutti usavano smarty continuavo a scaricare ogni nuova
versione e ripromettermi di leggere il manuale, ma poi non lo facevo mai,
perché non avevo tempo di imparare quello che in effetti era un nuovo
linguaggio. Avevo già abbastanza difficoltà a stare dietro alle novità di
PHP, HTML, CSS, per non parlare di Javascript e SQL.
Ancora oggi PEAR e PECL quasi non li uso perché non ho voglia di
sbattermi a capire come impostare gli include path o di andare a cercarmi
i componenti e capire se mi vanno bene.
Uso un framework perché mi facilita enormemente il lavoro, ma se (come
sta facendo ZF2) mi serve più tempo a imbastire il progetto che a farlo,
passo ad altro.
Idem coi template, IMHO. :)
Bye.
ha scritto:
> non
> parlo in termini di prestazione, parlo in termini di manutenibilità del
> codice
altro. :)
OK che una stringa {{var}} è gestita meglio da sistemi come Dreamweaver,
ma per mia esperienza difficilmente riesci a dare in mano a un cliente i
template da modificare.
Non tanto per la difficoltà dell'HTML, ma perché ormai non mi succede da
oltre 4 anni di avere tutto in un singolo file.
E` tutto sparso in diverse partial view, che vengono montate dai
controller a seconda di cosa deve apparire. E sempre più spesso l'HTML è
talmente generico che fanno tutto i CSS.
La "vecchia" figura del webmaster (o come lo chiamavano) che sapeva un
po' di grafica, un po' di Dreamweaver e un po' di HTML non saprebbe
nemmeno dove iniziare a metterci mano.
> Dato che sono un freelance per me è molto importante lasciare il
> cliente con un codice che sia mantenibile anche da uno che non si sia
> smazzato sei mesi di lettura di spaghetti code
ho lasciato il codice al cliente. Gli ho dato la disponibilità di un dump
del DB e delle immagini, ma il codice rimane comunque mio, perché
utilizza componenti che ho costruito nel tempo, e che uso per tutti i
miei progetti.
Se dovessi dargli anche la disponibilità del sorgente dovrei farlo pagare
almeno il triplo. Una volta per il lavoro, una volta per il codice che
diventa suo, e una terza perché dovrei fargli tutti i template "stupid
proof". :)
> Che i template engine pesino siamo d'accordo, ma secondo me non pesano
> quanto dici tu e comunque sia rendono il codice più mantenibile
> Del
> resto anche l'OOP è orientata solo ad una maggiore manutenibilità da
> parte degli esseri umani Una macchina col procedurale ci sguazza
Programmare OOP fornisce un'astrazione e una possibilità di
"componentizzazione" che è impossibile raggiungere con la programmazione
procedurale, a meno di non avere funzioni con nomi lunghissimi (qualcuno
ha detto ObjectiveC? :P)
Usare un template engine invece di semplici view con PHP embedded (e
autolimitandosi sui tag) non offre nessun vantaggio, ma solo svantaggi.
Naturalmente non parlo di infilare connessioni al DB o richiami alla cache
nelle view. Parlo di un motore di view alla Zend_View.
>> Se poi i tramaccioni ne abusano, sono cavoli loro. Nessuno sano di
>> mente metterà mano al loro codice, e quando si troveranno a modificarlo
>> saranno comunque cavoli loro (o del poveraccio che viene assunto e
>> pagato per sistemare i casini, ma vuol dire che verrà pagato più a
>> lungo. :)
> Mi viene da piangere .... :'(
> Non infierire ti prego
Ma permettimi di aggiungere che se uno è incapace (sia nel senso "non è
ancora capace" che nel senso "non sarà mai capace") inizierà dritto
mettendo l'html dentro i print/echo.
Un motore di templating come twig o smarty sarà solo uno scoglio in più
che non farà altro che rallentare il suo apprendimento.
Lo so perché è successo a me! :)
Ai tempi in cui tutti usavano smarty continuavo a scaricare ogni nuova
versione e ripromettermi di leggere il manuale, ma poi non lo facevo mai,
perché non avevo tempo di imparare quello che in effetti era un nuovo
linguaggio. Avevo già abbastanza difficoltà a stare dietro alle novità di
PHP, HTML, CSS, per non parlare di Javascript e SQL.
Ancora oggi PEAR e PECL quasi non li uso perché non ho voglia di
sbattermi a capire come impostare gli include path o di andare a cercarmi
i componenti e capire se mi vanno bene.
Uso un framework perché mi facilita enormemente il lavoro, ma se (come
sta facendo ZF2) mi serve più tempo a imbastire il progetto che a farlo,
passo ad altro.
Idem coi template, IMHO. :)
Bye.
0 new messages