I file di visualizzazione di PHP dovrebbero essere chiamati qualcosa di diverso da '.php'?

Question

I file di visualizzazione di PHP dovrebbero essere chiamati qualcosa di diverso da '.php'?

#1 da (5 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (0 voti)
#5 da (0 voti)
#6 da (0 voti)
#7 da (0 voti)
#8 da (0 voti)

1

Per impostazione predefinita, qualsiasi file che tocca PHP viene in genere suffisso con .php . È universalmente riconosciuto da Apache / Nginx come predefinito per i file PHP e la maggior parte delle configurazioni prevede che i file PHP finiscano in questa estensione. In breve, .php è lo standard per tutto PHP.

Tuttavia, mi chiedo se forse i file di visualizzazione dovrebbero avere un'estensione diversa per differenziarli da altri file PHP.

In primo luogo, quando si tratta di visualizzazioni, ho trovato che quasi tutti i framework MVC utilizzano un file di visualizzazione corrispondente chiamato dopo il controller o il metodo. Inoltre, in genere hai anche un modello corrispondente chiamato la stessa cosa. Ciò causa un problema con la maggior parte degli IDE e degli editor.

Ad esempio, potresti avere un controller "utente", una vista "utente" e un modello "utente". Il risultato di avere tre file aperti si chiama "user.php", il che lo rende un fastidio quando ti muovi e fai clic sulle schede sbagliate.

In secondo luogo, separare le viste come un tipo fondamentalmente diverso di file PHP (il tipo di presentazione) è un altro argomento per modificare l'estensione dei file di visualizzazione in qualcosa di diverso da .php . Qualcosa che dice immediatamente al tuo cervello che tipo di contenuto ci appartiene.

In terzo luogo, alcune applicazioni espongono parti (o tutti) dei file PHP nel webroot e nelle sue directory. Piuttosto che aggiungere qualcosa come <?php if(!defined(ABC)) die('not allowed'); sarebbe bello avere un modo semplice per vietare l'accesso alle visualizzazioni mentre autorizzi altri file come il solito index.php .

Ci sono altri buoni / cattivi motivi per ritenere che sia una buona idea cambiare l'estensione del file di visualizzazione?

html php mvc view presentation

posta Xeoncross 08.02.2012 - 19:36

fonte

8 risposte

Leggi altre domande sui tag html php mvc view presentation

Il cliente beneficerà in alcun modo di un DVCS? Il percorso nell'URL Set-Cookie è codificato?

score 5 · Answer 1

Quando parli di convenzioni, ci sono alcuni modi diversi per farlo. Modi che ho visto:

index.tpl.php
index.phtml
templates/index.php
views/index.php

Puoi combinare questi metodi per ottenere delle convenzioni davvero sorprendenti!

views/templates/index.tpl.phtml

Ma se lo fai mai dovresti sentirti male con te stesso.

Il lungo e breve di esso - se si utilizza un framework, utilizzare la convenzione del modello. Se lo fai a modo tuo, sii coerente e, soprattutto, se i tuoi file template sono in web root e non si chiamano *.php assicurati che il tuo webserver non li serva come testo !!!! !

score 2 · Answer 2

Per differenziare le viste dai modelli e dai controller, preferisco usare le directory:

+ /root
+    /controllers
         DefaultController.php
+    /models
+    /views
+        /Default
             Home.php ← Home view of DefaultController.
             About.php ← Another view.

Per quanto riguarda il tuo secondo argomento, le tue visualizzazioni contengono codice PHP? Se sì, allora non sono fondamentalmente di tipo diverso. Sono solo ... diversi. Ecco perché sono in una directory separata.

Un contro-argomento potrebbe essere che in un IDE, non vedi il percorso completo . Se apro fianco a fianco /models/Home.php e /views/Default/Home.php , come faccio a sapere che il primo Home.php è un modello e il secondo Home.php è una vista?

Tuttavia, anche in questo caso, eviterei di modificare le estensioni, ma preferisco usare prefissi / suffissi : HomeModel.php e HomeView.php sono abbastanza chiari in un IDE. Infatti, se modifichi le estensioni solo per l'IDE, un altro sviluppatore dovrebbe riconfigurare il suo IDE per accettare e comprendere quelle estensioni come file di codice sorgente PHP.

score 1 · Answer 3

La convenzione sui nomi dovrebbe aiutare, non ostacolare, la chiarezza. L'impostazione che descrivi chiaramente ostacola la chiarezza e quindi non è utile.

L'estensione del file dovrebbe sempre rappresentare ciò che è nel file. Se è php, dovrebbe essere ".php". Detto questo, mi piace lo standard Zend MVC di usare ".phtml" per i file di visualizzazione. Il che, in sostanza, mi dice che questo è principalmente un file html che puoi anche aspettarti di contenere del php.

Tornando a Zend, il controller è UserController.php, il modello è User.php (o Application_User.php, a seconda di come si esegue il rollback), e la vista per l'azione index è index.phtml, negli script / directory utente.

Se la struttura ti lascia così confuso, vuoi cambiare gli standard, cercherò un altro framework.

score 0 · Answer 4

Lo schema MVC divide / segrega già il codice del tuo progetto in una struttura di cartelle per riflettere Modello, Vista e Controller. A mio avviso, dovrebbe essere sufficiente per identificare i tipi di file.

Il tuo esempio con User controller può variare tra i framework. Ho lavorato principalmente con CodeIgniter e sicuramente non impone la convenzione sui nomi dei file come presentata. Sei libero di chiamare le tue visualizzazioni come vuoi, inserirle in sottodirectory che prendono il nome dal tuo controller, ecc. (Come se fosse fatto in ASP.NET MVC)

score 0 · Answer 5

È non importa quale estensione assegni ai tuoi file. Ma, molto probabilmente, ti piacerebbe vedere i file distinti dagli altri file che hai nell'applicazione. Alcuni tipi di distinzione potrebbero essere più adatti a te, basta sceglierne uno e attenersi ad esso.

score 0 · Answer 6

Versioni precedenti di Apache & PHP supportava estensioni di file aggiuntive, in base alla versione PHP installata:

customers.php3
sales.php3
products.php4
purchases.php4

Penso, si può ancora fare, nella configurazione di Apache o PHP, ma, pensa, sarà complicato e porterà più problemi, che vantaggi.

Tuttavia, a volte, è utile distinguere tra diversi file di codice sorgente correlati.

Un trucco con i trattini ("meno") o punti all'interno del nome del file, non l'estensione del file o il suffisso del file.

Esempio 1:

customers-model.php
customers-view.php
customers-controller.php

Esempio 2:

customers.model.php
customers.view.php
customers.controller.php

Esempio 3 (prefissi o suffissi):

CustomersModel.php
CustomersView.php
CustomersController.php

In questo modo, continui a supportare l'estensione del file e a implementare una "estensione secondaria", per il tuo codice sorgente.

score 0 · Answer 7

Se sei preoccupato di impedire l'accesso per visualizzare i file nel tuo webroot, allora la soluzione è usare .htaccess per reindirizzare le richieste a tali file sulla tua applicazione. Preferisco un file indice di bootstrap che gestisca tutte le richieste.

score 0 · Answer 8

Dipende davvero dal contenuto dei tuoi file di visualizzazione.

Una vista potrebbe essere simile a questa:

<?php

class Home_View {

    public function render($parameters) {
        [...]
    }

    [...]
}

?>

Potrebbe anche essere simile a questo:

<html>
    <head>
        <?php echo $parameters['styles'] ?>
    <title><?php echo $parameters['title'] ?></title>
    </head>
    <body>
        <?php echo $parameters['content'] ?>
    </body>
</html>

Entrambi i casi precedenti, ha senso usare l'estensione .php , perché la tua vista è fondamentalmente semplicemente PHP.

Però una vista non deve essere un semplice PHP. Una vista potrebbe essere uno dei molti altri tipi di file che possono essere capiti dal tuo controller.

Se la tua vista è un modello Smarty valido, considera .tpl .

Se la tua vista è un modello di Twig valido, considera .twig .

Se la tua vista è un modello Latte valido, considera .latte .

Se la tua vista è un modello di baffi valido, considera .mustache .

Se la tua vista è HTML valida, considera .phtml o .html .

Se la tua vista è un file Atom valido, considera .atom .

Se la tua vista è un file JSON valido, considera .json .

Se la tua vista è un file XML valido, considera .xml .

Ovviamente potresti sempre usare la tua estensione personalizzata, ma non la consiglierei perché non potresti sfruttare le funzionalità di formattazione automatica e di evidenziazione del codice del tuo IDE preferito (almeno non fuori dalla scatola ).