www.scriptcasecommunity.it

Ciao ,
sto tentando di capire come ragiona SC ma non ci arrivo...
Ho un flusso da fare per un processo tipo spedizioni .
Per esemplificare ho usato le immagini di una nave con i containers etc . Il problema comunque è molto simile.
Form 1 - Info generali
Form 2 - Info spedizione (i.e. nave cargo da usare)
Form 3 - Info Containers (definizione di un container da caricare [one ship]->[many containers])
Form 4 - Info Casse (ogni containere contiene diverse casse all'interno [one container]->[many boxes])
Form 5 - Prodotti (ogni cassa contiene più prodotti [one box]->[many items])

Form 1 è master del Form 2 e in cascata gli altri annidati.
Son riuscito a far vedere i primi 2 ma poi SC non è in grado di aggangiare i details di livello inferiore. Spero sia sufficientemente chiaro.
In teoria dovrei , per ragionare come lui, fare form separati senza il master/detail interno ma non ho la minima idea di come poterli fare.

Se avete suggerimenti sono tutti welcome !

hai provato a vedere le fasi nelle pagine/schede?

Come ha detto Rino, c'è una funzione "step" nelle form, proprio per queste situazioni.
https://www.youtube.com/watch?v=rXEMhfr_5Q4

Mi par di capire che in ballo ci sono diverse tabelle e diverse pagine, tempo fa per fare un wizard, ho sviluppato N app, step_1, step_2 etc, ed erano un misto di form, control e grid, passavo alcuni dati via variabili di sessione, altri su tabelle sul DB con chiave l'ID della sessione.
Modificando le etichette di alcuni bottoni o aggiungendone simulavo il percorso AVANTI , INDIETRO, per esempio sulle control, potevo fare il validate per non far procedere l'utente se qualcosa non andava bene, e nel onvalidatesuccess mettevo la sc_redir al passo successivo.

Io non avevo bisogno del percorso da visualizzare in altro, tu potresti creare un header custom dove metti una variabile PERCORSO dove metterai poi la variabile [PERCORSOUTENTE] da riempire , nella scriptinit, con il codice HTML per visualizzare il percorso ed evidenziare dove si trova l'utente.

Vincenzo ha scritto: ↑05 gen 2024, 15:13 Mi par di capire che in ballo ci sono diverse tabelle e diverse pagine, tempo fa per fare un wizard, ho sviluppato N app, step_1, step_2 etc, ed erano un misto di form, control e grid, passavo alcuni dati via variabili di sessione, altri su tabelle sul DB con chiave l'ID della sessione.
Modificando le etichette di alcuni bottoni o aggiungendone simulavo il percorso AVANTI , INDIETRO, per esempio sulle control, potevo fare il validate per non far procedere l'utente se qualcosa non andava bene, e nel onvalidatesuccess mettevo la sc_redir al passo successivo.

Io non avevo bisogno del percorso da visualizzare in altro, tu potresti creare un header custom dove metti una variabile PERCORSO dove metterai poi la variabile [PERCORSOUTENTE] da riempire , nella scriptinit, con il codice HTML per visualizzare il percorso ed evidenziare dove si trova l'utente.

una soluzione interessante che oggi è ampiamente superata dalla gestione in sequenza delle pagine. ci sono due modi , quello obbigatorio/sequanziale e quello libero. il sostema prevede anche la segnalazine di fatto/non fatto e un supporto descrittivo delle pagine.
ovviamente tutto è legato ad un file/tabella principale ,come ogni form d altronde. nulla vieta di usare form diverse dentro la pagine come anche griglie .
SC a volte mi fa arrabnare, perdi ore a trovare una soluzone e poi zak eccotela serviza sun un piatto .

rino ha scritto: ↑05 gen 2024, 16:17 una soluzione interessante che oggi è ampiamente superata dalla gestione in sequenza delle pagine.

mah, nel caso specifico , non credo che con un form a pagine risolva, sarà che ho dovuto fare una cosa simile, il cliente voleva tutto in una sola pagina, sono mezzo impazzito, e alla fine il progetto non è mai andato in produzione, perché c'erano troppe informazioni da mettere in una sola pagina .

Il wizard va bene per "creare una nuova spedizione", così chiedi poche informazioni alla volta, e ti assicuri che ci siano quelle necessarie, ma poi passerei ad una modalità di EDIT, più facile per l'utente, non so i vincoli dell'autore del post ma ad occhio io mi fermerei ai container.
Ed anche l'interfaccia di EDIT non è banale, avendo nave -> containers-> casse -> scatole, assumendo almeno 1 item obbligatorio per ogni voce.

Vincenzo ha scritto: ↑08 gen 2024, 10:19

rino ha scritto: ↑05 gen 2024, 16:17 una soluzione interessante che oggi è ampiamente superata dalla gestione in sequenza delle pagine.

mah, nel caso specifico , non credo che con un form a pagine risolva, sarà che ho dovuto fare una cosa simile, il cliente voleva tutto in una sola pagina, sono mezzo impazzito, e alla fine il progetto non è mai andato in produzione, perché c'erano troppe informazioni da mettere in una sola pagina .

Il wizard va bene per "creare una nuova spedizione", così chiedi poche informazioni alla volta, e ti assicuri che ci siano quelle necessarie, ma poi passerei ad una modalità di EDIT, più facile per l'utente, non so i vincoli dell'autore del post ma ad occhio io mi fermerei ai container.
Ed anche l'interfaccia di EDIT non è banale, avendo nave -> containers-> casse -> scatole, assumendo almeno 1 item obbligatorio per ogni voce.

Il concetto di "pagina" è estremamente volubile, quali dimensioni? per la larghezza pssiamo fare riferimento alel dimensioni standard dei monitor, ma con che risoluzione/ ingrandimeto del browser? per la lunghezza .... non vi è limite allo scorrimento
Una valida soluzioen si può basare sull'uso del 'master' e degli aggiornamenti possibili tra figli e padre. Lo sviluppo in verticale risolve l uso con terminali di ridotte dimensioni .
Un ainteressante questione di accessibilità , per altro oggi necessaria in forza di legge .