Forum: Italian Ruby user group wizard, procedure più o meno guidate e affini

Ciao,

vi scrivo per chiedervi se avete best practice o ne avete mai sentite
riguardo un argomento in particolare:

i wizard, le procedure o processi guidati in cui l'utente deve fare una
serie di operazioni (possibilmente) senza perdersi, eventualmente
ritornando ad un punto di partenza per continuare un task che dipendeva 
da
un altro.

se non c' molto, come credo, si potrebbe pensare qualcosa di framework
agnostic per dare una mano in questi casi. io al momento ci perdo tanto
tempo rispetto al resto...

sante

2013/1/31 Sante Rotondi <saten.r@gmail.com>
>
> se non c' molto, come credo, si potrebbe pensare qualcosa di framework
> agnostic per dare una mano in questi casi. io al momento ci perdo tanto
> tempo rispetto al resto...
>

Ciao Sante, purtroppo  un punto a sfavore dei framework che adottano un
modello stateless (come Rails). Ad esempio Lift ha supporto all'interno 
del
framework per generare wizards di pi pagine.

Il mio consiglio, per dominare la complessit,  di rappresentare il 
wizard
con
un model e utilizzare gemme come state_machine per gestire i cambiamenti
di stato (quindi a ogni pagina del wizard avresti un cambiamento di 
stato).

Hai dato un occhio a Wicked? [1] C'è stato stato anche un Railscast[2] 
su
di lui qualche tempo fa.

[1]: https://www.ruby-toolbox.com/projects/wicked
[2]: http://railscasts.com/episodes/346-wizard-forms-with-wicked

--
Stefano Verna

Società Cooperativa weLaika
Via Salgari 7, 10154 Torino (TO)
http://welaika.com • info@welaika.com • 011-23.86.330
P. IVA e C.F. 10300060018


2013/1/31 Stefano Pigozzi <stefano.pigozzi@gmail.com>

2013/1/31 Stefano Verna <stefano.verna@welaika.com>

> Hai dato un occhio a Wicked? [1] C' stato stato anche un Railscast[2] su
> di lui qualche tempo fa.


Grazie, non la conoscevo! Sembra astrarre quello che potresti fare con
state_machine e un po' di logica custom.

Wicked  interessante, anche se risolve un problema molto pi limitato di
quello che ho in mente. Guarder bene il wiki per capire fin dove pu
arrivare.
grazie!

personalmente non sono un amante delle gemme che vanno a coprire 
contemporaneamente pi di un livello nello stack MVC (vedi Devise, 
ActiveAdmin e anche Wicked :P)

generalmente sono complessi da gestire e/o modificare. in altre parole, 
se non segui il loro modo di funzionare, devi perdere il triplo del 
tempo a capire come adattarli per le tue esigenze.

mi sono trovato a dover affrontare la realizzazione di un wizard, come 
ti hanno gi risposto,  meglio usare una state_machine e gestire i vari 
steps.

di norma uso un codice molto simile a questo (modificato per le varie 
esigenze):

https://gist.github.com/4690486

ciao,
A.


Il giorno 31/gen/2013, alle ore 10:49, Sante Rotondi <saten.r@gmail.com> 
ha scritto:

> Wicked  interessante, anche se risolve un problema molto pi limitato di
> quello che ho in mente. Guarder bene il wiki per capire fin dove pu
> arrivare.
> grazie!

--
http://andreapavoni.com

2013/2/1 Andrea Pavoni <apeacox@gmail.com>

> personalmente non sono un amante delle gemme che vanno a coprire
> contemporaneamente pi di un livello nello stack MVC (vedi Devise,
> ActiveAdmin e anche Wicked :P)
>

Sicuramente una macchina a stati da qualche parte ci vuole.
Non mi trovi d'accordo sulla tua prima affermazione, in quanto io sono 
fan
di tutto quello che mi permette di guadagnare tempo, dove possibile, e 
di
mantenere codice omogeneo in progetti diversi. Ci sono cose su cui 
bello
sperimentare, altre in cui imho vale il principio DRY anche cross 
progetto.

Wicked pu andare bene per dei casi d'uso molto semplici, come quello del
railscast linkato qualche mail fa, ma non  abbastanza evoluto per fare
quello che servirebbe a me.
Io vorrei qualcosa che mi dia una pila di processi a stati, dove posso
saltare da una pila alla successiva quando uno stato di un processo 
dipende
dal completamento di un altro processo.. un po' quello che succede con 
lo
stack quando si invocano funzioni da funzioni, n pi n meno.
Ci sta che si dia qualche helper di navigazione alle view, per skippare
passaggi o costruire facilmente un breadcrumb con gli step ecc, non lo
trovo affatto in contrasto con MVC.

Che ne pensi Andrea?

Il giorno 01/feb/2013, alle ore 11:30, Sante Rotondi <saten.r@gmail.com> 
ha scritto:

> 2013/2/1 Andrea Pavoni <apeacox@gmail.com>
>
>> personalmente non sono un amante delle gemme che vanno a coprire
>> contemporaneamente pi di un livello nello stack MVC (vedi Devise,
>> ActiveAdmin e anche Wicked :P)
>>
>

> Non mi trovi d'accordo sulla tua prima affermazione, in quanto io sono fan
> di tutto quello che mi permette di guadagnare tempo, dove possibile, e di
> mantenere codice omogeneo in progetti diversi. Ci sono cose su cui  bello
> sperimentare, altre in cui imho vale il principio DRY anche cross progetto.

sono completamente daccordo con te, in linea di principio :-]

proprio in relazione al risparmio di tempo,  facilmente dimostrabile che 
molte gemme che coprono troppi aspetti, vanno bene finch le usi "as is", 
cio con il caso d'uso per il quale sono state previste.
Devise e ActiveAdmin sono un caso lampante: finch ti servono "2 cazzate 
standard" sono ottime e in pochi minuti hai la funzionalit pronta. devi 
solo *pregare* di non aver bisogno di qualche comportamento non previsto 
(una validazione, un redirect, un markup html differente...), altrimenti 
perderai ore. nel caso specifico di ActiveAdmin e Devise, sono gemme 
confusionarie e mal documentate. il tipico workflow : follow docs -> 
watch it fail -> write a working solution.

per rimanere DRY e non perdere tempo, solitamente ho un paio di 
approcci:

* cerco una gemma meno invasiva. per esempio Sorcery  un ottimo sistema 
di autenticazione, facilmente customizzabile, e con un po' di snippets 
di codice gi scritto e testato senza perdere tempo ;-)

* scrivo qualcosa che posso riutilizzare (e magari la pacchettizzo in 
una gemma)

sono fedele alla filosofia UNIX: fai una sola cosa *bene* e che si possa 
integrare con altri componenti. IMHO non ha senso fare *un po' di tutto 
benino* (un po' come la differenza tra un webmaster vecchia scuola ed un 
team composto da designer, programmatore, sysop, etc) :-)


> Ci sta che si dia qualche helper di navigazione alle view, per skippare
> passaggi o costruire facilmente un breadcrumb con gli step ecc, non lo
> trovo affatto in contrasto con MVC.


esatto :-) offrire qualche helper/macro/metodo, etc per parti specifiche 
perfetto. ma costruire un sistema trasversale (che coinvolge pi parti 
MVC perch altrimenti non funzia), IMHO  terribile :-)

A.

--
http://andreapavoni.com

2013/2/1 Andrea Pavoni <apeacox@gmail.com>
[cut]

> proprio in relazione al risparmio di tempo, è facilmente dimostrabile che
> molte gemme che coprono troppi aspetti, vanno bene finchè le usi "as is",
> cioè con il caso d'uso per il quale sono state previste.
>
[cut]

> sono fedele alla filosofia UNIX: fai una sola cosa *bene* e che si possa
> integrare con altri componenti.
>

+1