Progettazione del flusso di lavoro per modifiche multi-step su una webapp

4

Ho un'app Web (ASP MVC2) in cui è possibile accedere a alcuni moduli tramite più percorsi, inizialmente una volta completato il modulo, un utente è stato reindirizzato a una pagina predefinita per tale modulo anziché alla pagina da cui è stato inserito.

Ora sto riprogettando un'area considerevole che voglio affrontare, voglio una soluzione che sia facile da aggiungere. Ho un paio di idee ma non sono sicuro su quale debba andare, so che vuoi che sia "invisibile" (cioè non toccare i miei URL).

Quindi sto pensando sia:

Potrei avere campi nascosti per la pagina dei referrer sui moduli.

In alternativa, potrei usare TempData e avere un attributo che gestisca il controllo e l'aggiunta dell'URL del referrer (probabilmente includerebbe una stringa per ciascuno dei diversi percorsi in modo che un utente possa avere 2 diverse forme aperte e che i referrer non interferiscano) .

Il problema con il valore del modulo è che richiederebbe campi non correlati ai modelli in ciascuna delle viste e si interromperà se nel flusso di lavoro sono presenti richieste GET. richiederebbe anche la gestione manuale di questa proprietà in ogni vista e azione.

L'approccio agli attributi TempData + sarebbe un modo molto più efficace per applicarlo, ma è possibile che i poweruser che stanno facendo molte cose contemporaneamente abbiano referrer in conflitto per le stesse forme.

Mi sto appoggiando a quest'ultimo approccio in quanto è più elegante e più facile da tenere traccia di come non vedo ci siano molti casi limite in cui viene sovrascritto, ma sono preoccupato per l'esperienza utente se succede Ne vale la pena?

    
posta Chao 29.09.2011 - 15:08
fonte

1 risposta

1

Non mi è chiaro quale tecnologia stai usando per questo, quindi cercherò di rispondere genericamente.

Sembra che gli utenti possano avere il modulo aperto più di una volta (nuova finestra o più schede) lanciato da diversi contesti o più di una volta dallo stesso contesto. Ciò renderebbe l'utilizzo delle variabili di sessione un problema, in particolare per quanto riguarda la rimozione delle variabili del modulo dalla pagina.

Puoi invece guardare alla creazione del modulo come modello (User Control in .NET) e includerlo in una pagina per ciascuno dei contesti in cui viene utilizzato. La pagina padre potrebbe avere una singola variabile statica che contiene il valore per il contesto. Durante l'elaborazione, ottenere i valori per il modulo e il contesto dalla pagina padre, il modulo è in e in caso di successo reindirizzare nuovamente alla posizione appropriata per il contesto. Questo ovviamente presuppone che la rotta e il reindirizzamento di cui si parla possano essere tracciati con una variabile. Quella variabile più informazioni sul modulo potrebbe essere utilizzata anche per varie posizioni di ritorno.

    
risposta data 04.10.2011 - 21:20
fonte

Leggi altre domande sui tag