GBFoundation: ..per quanto riguarda la risposta n 2, non la "condivido" pienamente...il fatto di spostare la logica di validazione stato sul client certo è una soluzione, ma che trovo poco incapsulata, nel senso che è ben diverso poter dire sul workflow alcuni utenti recuperati che sò da activity directory, possono leggere quel determinato stato, oppure possono scriverci, oppure possono farlo transitare(sarebbe tra gli activity custom che farei ;P), garantisci a mio parere una manutenzione maggiore, sai che tutto ciò che riguarda il flusso si trova sul disegno/activity e non sparso nell'ambiente di hosting(anche se alla fine senza l'ambiente di hosting non si può avere un workflow)...
Parzialmente condivido questa tua perplessità ed infatti, come ho specificato nel mio messaggio, c'è la Policy Activity che potresti usare all'interno del Workflow per gestire la visibilità (o l'esecuzione) di una determinata activity (o stato). Quello che io ci vedo è però un piccolo rischio: se impedisco ad un utente di vedere uno stato, e la macchina si trova proprio in quello, che vede l'utente???
Per quanto riguarda l'abilitazione all'esecuzione dell'evento di cambio stato, ha più senso ma se lo metto nel wf, lo faccio con la policy e mi devo gestire la cosa nell'interfaccia. Personalmente io ragiono sempre così: se un utente non è abilitato a fare una certa cosa, evito di fargli vedere il bottone (o il link) che fa quella specifica operazione. Dato che questa cosa io me la gestirei comunque, tanto vale che me la gestisco in UI.
Ad ogni modo, vedo nella Policy la soluzione più sensata.
GBFoundation: Il punto 3 invece lo reputo molto importante in certe situazione(forse quelle che fino ad adesso ho analizzato io: flussi documentali)....nei flussi documentali quasi sempre c'è questa esigenza...banalmente considera un documento diviso in capitoli, un capitolo deve essere scritto da te e uno da me, non posso aspettare che te finisci di scrivere il tuo per iniziare io, ognuno di noi vede una porzione, quella che gli compete, e porta a termine il suo lavoro ma senza preoccuparsi di cosa stai facendo te, dato che apparteniamo a due uffici diversi, abbiamo ruoli diversi ecc...in questo modo avresti il documento contemporaneamente nello stato "Capitolo Mighel" e "Capitolo Gb"...poi spetterà allo stato che io chiamo "imbuto"(o sarebbe più giusto usare termini come join ecc) cioè quello in cui giungeranno i due stati, avere un certo tipo di logica ma questo è un altro discorso.....spero di aver risposto...
Qui c'è forse un piccolo errore di interpretazione. "Capitolo Mighell" e "Capitolo GB" non sono (e non dovrebbero) essere considerati 2 stati di una State Machine. Essi sono 2 "oggetti" il cui stato di lavorazione viene gestito da una State Machine ma non 2 stati! In sostanza, supponiamo che io, tu e tutti i ragazzi di .netSide stessimo scrivendo un libro e volessimo gestirne il lavoro con una State Machine. Gli stati di questa SM saranno più o meno:
- Start
- Incompleto
- Completo/Non Revisionato
- Revisione in corso
- Revisionato
- Approvato
- In Stampa
- Stampato (Final State)
Non avrebbe senso creare uno stato specifico per ogni capitolo altrimenti, per un altro libro, il WF sarebbe inutilizzabile.
Ora..come gestiamo lo stato dei singoli capitoli? Con delle nostre logiche, magari cablate negli stati della state machine di sopra, che prendono l'elenco dei capitoli da, ad esempio un DataBase e commutano lo stato da incompleto a completo/non revisionato quando tutti i capitoli sono arrivati. In questo modo, per un secondo libro, puoi usare (e dovresti farlo, altrimento addio riusabilità) la stessa State Machine, cambiando semplicemente il DB da cui prendere i dati (autori, capitoli etc.).