MVC, impaginazione e criteri di ricerca massivi

Question

MVC, impaginazione e criteri di ricerca massivi

#1 da (0 voti)

1

Attualmente sto lavorando a un progetto che ha una forma di ricerca abbastanza ampia - il modulo è 30 o campi o più.

Ora posso ovviamente mapparlo per il routing facendo in modo che la mia applicazione tiri i parametri e la gestisca come al solito - ma come puoi immaginare di avere tanti campi in grado di far crescere l'URL al limite del limite massimo di caratteri e diventa difficile da gestire .

La mia domanda è questa, suppongo, quale meccanismo vengono generalmente utilizzati dalle persone per questo? Devo memorizzare i criteri di ricerca nella sessione e farlo scadere? Questo è l'unico modo in cui posso andare in giro forzando la paginazione a "postare" le variabili (tramite javascript ecc. Per continuare i criteri di ricerca).

Sto cercando di mantenerlo il più gestibile possibile. Questo criterio di ricerca è in un'applicazione privata, quindi ho spazio per la flessibilità.

Questo è in fase di costruzione in PHP, JavaScript, CSS e non utilizza alcun tipo di framework specifico, sebbene stia utilizzando il modello di progettazione MVC tradizionale.

Ogni pensiero, aiuto, esperienze passate a gestire questo è apprezzato.

php mvc search pagination

posta Ryan Rentfro 03.05.2015 - 03:21

fonte

1 risposta

Leggi altre domande sui tag php mvc search pagination

Come registrare i clic per un software Pay-Per-Click? Un diagramma di classe UML può mostrare due relazioni diverse tra due classi?

score 0 · Accepted Answer

Il limite di lunghezza dell'URL pratico è di circa 2000 caratteri. Pensa se potresti ottimizzare i tuoi filtri per adattarli.

Non è possibile, probabilmente lo implementerei come richiesta POST. Svantaggi:

anche se questo è in linea con la semantica HTTP della richiesta POST (può essere usato praticamente per qualsiasi cosa), non è la soluzione migliore - è effettivamente una richiesta nullipotent che potrebbe essere memorizzata nella cache dai proxy, ma ora non può essere memorizzata nella cache perché è POST. In pratica, non penso che questo sia molto importante, specialmente se si tratta di una specie di applicazione interna.
non puoi copiare & incolla l'URL dal browser ad es. invia le impostazioni del filtro a un collega
c'è un comportamento un po 'strano quando si desidera aggiornare la pagina - l'aggiornamento della richiesta POST induce il browser a chiederti se vuoi inviare di nuovo la richiesta POST. Per ovviare a questo problema, la pagina dei risultati è GET che carica i dati dal back-end utilizzando AJAX POST.

L'uso della sessione introduce lo stato nelle interazioni che violano uno dei principi di base di HTTP. Se si utilizza GET per recuperare i dati, i risultati possono essere memorizzati nella cache, ma ciò può effettivamente produrre risultati errati perché dipende da uno stato memorizzato nel back-end. Assicurati che le tue pagine GET con dipendenza dallo stato non possano essere memorizzate nella cache. Anche le interazioni di stato sono più complesse in generale, è necessario pensare sempre in quale stato si è ora e in quale stato si vuole andare, il che non è sempre facile.

In realtà ho implementato il filtraggio utilizzando la sessione alcuni anni fa, ma per un motivo diverso: le impostazioni del filtro non verranno cancellate se vai a pagine diverse e poi torni indietro. Questo è utile per molte applicazioni.

Ma se non hai bisogno di queste impostazioni del filtro "persistenza", ti consiglio di usare POST, perché è più semplice da usare (correttamente).