Questa cosa di avere un dispatcher che smista tutte le richieste mi è sempre sembrata una cosa poco utile, e anzi controproducente: in pratica, significa che qualsiasi modifica che io debba fare anche ad una parte ridottissima di un sito, implichi potenziali problemi all'intero sito, visto che se devo mettere mano al dispatcher rischio di piantare anche qualcosa che non c'entra nulla...
scusami, ma mi permetto di dirti che stai sbagliando perché anche se c'è questo remotissimo (*) problema in compenso hai tutta la gestione centralizzata ed un cambiamento strutturale si traduce nel cambiamento di un singolo blocco di codice con l'aggiunta che eviti ripetizione di codice
(*) remotissimo perché una volta sviluppata un'interfaccia che si occupa di richiamare i componenti cambiarla significa avere in programma di ristrutturare tutto il motore interno e quindi tutti i moduli
In più, a parte il discorso SEO, non vedo nessun'altra motivazione che mi spinga a spendere tempo su questa cosa e non invece in altre aree molto più interessanti per il cliente, come per esempio una ergonomia molto migliore, o altre migliorie prestazionali o redazionali...
un dispatcher centralizzato permette una gestione più flessibile perché internamente può controllare il funzionamento di ogni singola parte del processo, senza la necessità di duplicare il codice
Se, ad esempio, il dispatcher supporta il caching dell'output i componenti richiamati dal dispatcher automaticamente la supportano senza necessità di duplicare il codice. Il supporto della cache è gestito tramite un'apposito componente richiamato dal dispatcher che associa l'output alle informazioni correnti (tema, utente, sessione, variabili in get/post e via dicendo).
Ovviamente è solo un esempio, non molto flessibile per altro, un'altro esempio è proprio lo smistamento delle richieste non solo per il rewrite urls ma anche lo "spostamento" dei percorsi negli url con una certa facilità (nel mio CMS ho un elenco di path che possono essere associate ai componenti specificando eventuali parametri ad hoc cosi con un solo componente che genericamente gestisce i contenuti con categorie e tags puoi gestire tutti i tipi di contenuti testuali che vuoi [news, pagine statiche, pagine di categorie, pagine di tags e via dicendo]
Nello specifico, per le rewrite urls, non utilizzare un sistema del genere vorrebbe dire cambiare l'elenco delle rewrite urls per adattarle alle pagine mentre con un dispatcher basta 1 sola rewrite url tipo
codice:
<IfModule mod_rewrite.c>
# Attiva i link simbolici, usati per il ridirezionamento delle rewrite rules
Options +FollowSymLinks
# Attiva il rewrite engine
RewriteEngine on
# Disattiva l'eventuale esecuzione della regola se il file o la directory
# richiesta esiste sul disco
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Tramite questa regola, tutte le path passate le passa all'index tramite
# il parametro p aggiungendo alla fine della path anche la query string senza
# sovrascrivere quella presente
RewriteRule ^(.*)$ index.php?p=$1 [L,QSA]
</IfModule>
fai tutto quello che ti serve
Di nuovo, mi paiono motivazioni molto deboli: quello che SEMBRA (l'articolo che hai linkato è pieno di condizionali e "may") è che la presenza di KEYWORD nella url migliori un po' il ranking, ma se la url contiene un titolo che è poco significativo perchè non contiene keyword, il risultato è nullo...
non per volerti andare contro, ma google non rilascia dettagli approfonditi sul funzionamento dei suoi algorittimi di indicizzazione, di conseguenza credo più ad un articolo che usa dei condizionali piuttosto che ad un articolo che non ne usa ... ma sorvolando su questo ... generalmente il titolo è inerente al contenuto
Ad esempio
http://php.html.it/guide/lezione/413...l-costruttore/
che è linkato da
http://php.html.it/guide/leggi/167/g...tti-con-php-5/
contengono entrambe keyword relative al contenuto della pagina
Non so, continua a sembrarmi una cosa molto di moda ma poco utile sul lungo termine, soprattutto per tutti quei siti che hanno già una loro presenza consolidata in rete da tempo, e nei quali quindi passare a questo tipo di url significa CAMBIARE la url di quasi tutti i contenuti: in questi casi, rimango convinto che sia più importante NON cambiare la url, piuttosto che averla semantica...
beh, mentre questo è un pò vero, mi riferisco alla moda, non è la sola cosa che è nata più perché è "trendy": è moda implementare le interfacce web dinamiche e fluide (leggasi web 2.0), ancora ruby con ruby on rails è moda ed ancora ne spunteranno a tonnellate
Ma è anche vero che queste cose "trendy" portano il loro (piccolo o grande) contributo all'usabilità, alla performance, alla semplicità di scrittura del codice, all'indicizzazione e via dicendo.
Ora, non dico che è la soluzione definitiva ma danno il loro contributo
PS: riguardo ad i grandi portali che si ritrovano a dover fare le conversioni, beh, anche li il problema dei vecchi link è al quanto relativo perché basta costruirsi una mappa dei vecchi link (tramite un crawler, usando una sitemap e via dicendo) per mapparli a quelli nuovi o tramite molte rewrite urls
Rispondi quotando
