Modali multipli, ridimensionabili e trascinabili

11/04/2020 00:21:43

e' interessante leggere discussioni come questa.
Pare di capire che javascript sia visto come il male, un po' come il php e' visto come il male tra i vari linguaggi di programmazione.
Se stai sviluppando un codice proprietario il mio consiglio e' usare php 7.2 o superiore solo questo rendere' il codice 40 volte più' sicuro e 10 volte più' veloce.
Poi per come e' strutturata una land secondo me il consiglio e' sfruttare interamente javascript non cercare di abolirlo. Quindi sviluppare una land come se fosse una SPA (Single Page Application), puoi sfruttare uno qualsiasi dei framework che ci sono per i livelli di richieste che ci sono in una land non si notano differenza tra uno e l'altro. Sono framework che reggono carichi di lavori di migliaia di richieste al secondo senza problemi figuriamoci di applicazioni con punte sui 100 utenti connessi.
Perché conviene usare React, AngularJS, VueJS o altro? Perché in questo modo gli utenti non dovranno più aggiornare la pagina. Qualsiasi richiesta e' asincrona. Sono stati abituati per anni a vedere l'animazione del refresh, poi abituati ai vari giochi in real time. Secondo me e' il primo passo per uscire da un tipo di codice che viene riciclato da troppi anni. Parliamo di un ambiente dove in 6 mesi quello che sai e' già datato. Se riusciamo a convogliare le poche forze nel migliorare magari tutto il settore di nicchia ne trae beneficio altrimenti rimane una nicchia per i nostalgici come accade a chi piacciono i siti anni 2000.
Con questo intervengo non voglio dire che sia sbagliato eliminare javascript, semplicemente che non e' javascript il male, ma l'uso che se ne fa. Come php non e' il male, quindi quando si leggono discussioni come non usare php, usiamo Python, non usare jQuery, usiamo AngularJS, MySql no, NoSql si etc etc. Bisogna capire se non esiste una verità assoluta dipende dal nostro caso specifico e più in generale dalle conoscenze di chi deve sviluppare, se uno conosce php non ha senso imparare Phyton solo perché e' più in voga o altre cose del genere.

11/04/2020 11:22:08

breaker ha scritto:
non voglio dire che sia sbagliato eliminare javascript, semplicemente che non e' javascript il male, ma l'uso che se ne fa. Come php non e' il male, quindi quando si leggono discussioni come non usare php, usiamo Python, non usare jQuery, usiamo AngularJS, MySql no, NoSql si etc etc. Bisogna capire se non esiste una verità assoluta dipende dal nostro caso specifico e più in generale dalle conoscenze di chi deve sviluppare, se uno conosce php non ha senso imparare Phyton solo perché e' più in voga o altre cose del genere.

Beh, sono d'accordo... anche perchè stiamo parlando di linguaggi diversi che assolvono funzioni diverse. Php gira sul server (e serve a generare dinamicamente l'html), javascript gira sul client (e serve a rispondere al client in modo asincrono). È sbagliato anche concettualmente dire che "uno è meglio dell'altro", fanno semplicemente cose diverse.

Quello che intendevo dire nel mio intervento precedente non è che javascript è il male, è che va usato quando serve una richiesta asincrona che non potresti gestire in altro modo. Esempio stupido, se vuoi un bottone che si illumina quando ci passi sopra il mouse, al giorno d'oggi non ti metti più a pasticciare con onMouseOver ma usi semplicemente il selettore :hover nel CSS.

Tornando al fulcro della discussione, magari il punto della questione non è neanche tanto la finestra modale multipla trascinabile (che effettivamente non credo si possa fare senza js), ma è: a cosa servono quelle finestre? A poter aprire contemporaneamente scheda e negozio? Visto su un pc probabilmente avrà una buona resa, ma non so quanto bene funzioni su uno smartphone/tablet (poi magari l'assunto di base è che alla vostra land si gioca solo da pc, ma ormai credo che almeno la documentazione e il mercato vengano abbondantemente consultate anche da altri dispositivi).

11/04/2020 13:57:25

quod ha scritto: Tornando al fulcro della discussione, magari il punto della questione non è neanche tanto la finestra modale multipla trascinabile (che effettivamente non credo si possa fare senza js), ma è: a cosa servono quelle finestre? A poter aprire contemporaneamente scheda e negozio? Visto su un pc probabilmente avrà una buona resa, ma non so quanto bene funzioni su uno smartphone/tablet (poi magari l'assunto di base è che alla vostra land si gioca solo da pc, ma ormai credo che almeno la documentazione e il mercato vengano abbondantemente consultate anche da altri dispositivi).

Sul fatto che una Land debba essere consultabile/giocabile da più dispositivi, mi trovi completamente concorde con te. Stiamo cercando al momento di sviluppare le basi per poi trovare, in parallelo, una soluzione anche per le versioni tablet/mobile. Fortunatamente abbiamo già qualche idea e delle future implementazioni che andranno a risolvere completamente il "problema".

breaker ha scritto: e' interessante leggere discussioni come questa.
Pare di capire che javascript sia visto come il male, un po' come il php e' visto come il male tra i vari linguaggi di programmazione.

Ho notato in diverse occasioni che il php viene messo alla gogna. Personalmente lo utilizzo senza troppi problemi, visto che ha tantissimi applicativi e, come dicevi anche tu, è sicuro e più veloce (in base anche alla versione di utilizzo).

breaker ha scritto: Per come e' strutturata una land secondo me il consiglio e' sfruttare interamente javascript non cercare di abolirlo. Quindi sviluppare una land come se fosse una SPA (Single Page Application), puoi sfruttare uno qualsiasi dei framework che ci sono per i livelli di richieste che ci sono in una land non si notano differenza tra uno e l'altro. Sono framework che reggono carichi di lavori di migliaia di richieste al secondo senza problemi figuriamoci di applicazioni con punte sui 100 utenti connessi.

Fortunatamente ho un programmatore esperto che mi affianca e mi fa da tutor, altrimenti non sarei in grado di costruire una Land da solo con un codice proprietario, almeno al momento.
La discussione è partita più come una mia mera curiosità per cercare di alleggerire il carico di lavoro a chi è già abbastanza oberato, quindi ogni consiglio/parere è sempre ben accetto.
Detto questo, cercheremo di sfruttare il php e javascript per quanto più possibile, eliminando tutta quella parte di "refresh obbligatorio della pagina intera", anzichè di una singola parte.
Sicuramente creeremo un progetto SPA e mi coordinerò con il programmatore per ottimizzare il tutto!

11/04/2020 18:26:15

Per fare quello che vuoi fare con le modali secondo me ti conviene utilizzare Javascript per renderla ridimensionabile e movibile; per poterne aprire più di una puoi gestire la parte di chiusura sempre con javascript e andare di css per il resto. Come detto da altri però prendere spunto da altri codici potrebbe non essere sufficiente. Un minimo di padronanza ce la vuole in questo caso altrimenti rischi di perderci tanto tempo e di ottenere risultati scarsi (ed incasinare le performance client-side è un attimo se il javascript non lo implementi più che bene).
A mio avviso utilizzare jQuery o un altro framework può esserti utile (anche in termini di manutenibilità del codice). Ovvio però questa deve essere una scelta progettuale e non solamente situazionale; vale a dire che non vai a impiantarti jQuery solo per fare sta roba qua, quando poi lo lasci inutilizzato per tutto il resto.

Se vuoi un consiglio extra che nella programmazione (e in particolar modo con javascript dove le cose sembrano facili ma in realtà non lo sono) ti consiglio di tenere sempre a mente è il seguente: se intraprendendo una strada ti appare tortuosa e più vai avanti, più lo diventa, allora quella strada va abbandonata per trovarne una migliore. Ergo: se la soluzione che vuoi ottenere è troppo difficile da ottenere, prova a trovare un'altra soluzione 😉
Alla fine potrai essere stupito del fatto che quello che hai ottenuto è anche meglio dell'idea da cui eri partito.

PS: riguardo le considerazioni sulla programmazione quoto breaker

11/04/2020 20:57:31

Sono tutti consigli d'oro, assolutamente da farne tesoro!
Grazie a tutti voi per le risposte. Stasera vedo di confrontarmi anche con l'altro programmatore e di sbrogliare questa matassa.
Grazie ancora a tutti!

12/04/2020 00:51:49

quod ha scritto:
Quello che intendevo dire nel mio intervento precedente non è che javascript è il male, è che va usato quando serve una richiesta asincrona che non potresti gestire in altro modo. Esempio stupido, se vuoi un bottone che si illumina quando ci passi sopra il mouse, al giorno d'oggi non ti metti più a pasticciare con onMouseOver ma usi semplicemente il selettore :hover nel CSS.

Anche qui dipende, ti faccio un esempio:
se usi un javascript puro o css per fare un effetto di mouseover a livello di codice cambia poco nulla, quello che cambia e' l'effetto che vuoi dargli. Ad esempio potresti semplicemente mettere 2 immagini poi col codice fai comparire la seconda quando il mouse ci va sopra. Perfetto, il problema e' che la seconda immagine di default non viene caricata dalla pagina e quindi il browser la carica solo quando viene richiesta e l'utente si ritrova per una frazione di secondo (varia in base alla connessione, server, etc) il vuoto e poi la seconda immagine. Solitamente la funzione seconda immagine si usa per i menu, diventa brutto se uno si muove velocemente sul menu per la prima vedere sparire le immagini. Come si ovvia a questo? Infiniti modi, uno potrebbe essere mettere la seconda immagine insieme alla prima e poi tramite il css background-position decidere se far vedere una o l'altra. Il rovescio della medaglia e' che carichi immagini pesanti il doppio durante la fase di rendering iniziale in pratica ci mette di più' a caricare la land. Un'altra e' usare javascript per fare una richiesta dopo che tutta la pagina e' stata caricata per caricare le immagini che ti servono. Anche questo ovviamente ha i suoi lati negativi, ad esempio in fase di revisione devi ricordarti che le immagini vanno modificate tramite js e non css. Esistono tanti modi per fare la stessa cosa il mio consiglio e' prendere un metodo ed usare sempre quello perché il problema grosso del codice non e' sviluppare, ma mantenere un codice. Il problema di GDRCD o qualsiasi altro codice proprietario sta in questo, troppa confusione perché vi e' troppa libertà e quindi quando anche la stessa persona ci mette mano dopo pochi mesi o si mette a studiare il codice per capire quali ragionamenti aveva fatto per far funzionare le cose oppure semplicemente riscrive tutto.