Te lo riscrivo qui visto che probabilmente non sei riuscito a leggere il commento nel video precedente... "Molto bello il progetto, scusami sono un po ignorante in materia...lavoro come ux designer quindi nella parte di codice ne so poco o nulla. Voglio chiederti...non sarebbe più semplice lavorare, sulla struttura UI e logistica su FlutterFlow mentre la parte di identificazione e gestione dei database su Supabase? Magari nel caso il progetto cresca potresti integrare un ERP e un CRM tipo Bitrix 24 o Odoo? Così facendo il processo di realizzazione si semplificherebbe tantissimo o sbaglio?"
@@vittodal Esatto...ma anche no visto che i servizi no code attuali ti permettono di fare il giusto...ma per approfondire e rendere il lavoro migliore devi comunque mettere mano al codice.
Se vuoi un consiglio sopratutto per i like, commenti, o star usa il polimorfismo nelle tabelle cosi nel caso servissero like, commenti ecc passi il modello invece che creare un altra tabella correlata, anche per un sistema multilingua e uno dei migliori sistemi di gestione, io però lavoro con uno stack backend in base al progetto che è Python o PHP(django, flask, symfony, laravel) quindi parliamo di oop e programmazione a oggetti...per la questione del gender puoi creare un componente dove l utente selezione il gender o nelle impostazioni o con un menu apposito a comparsa e da li filtri quello che ti serve con le query, il componente deve avere uno stato quindi deve essere statefull.
@@vittodal Il polimorfismo è un approccio di design estremamente utile per rappresentare relazioni di tipo "molti-a-molti" o "uno-a-molti" tra entità di diversi tipi, permettendo di gestire le relazioni in modo uniforme senza la necessità di creare tabelle separate per ogni tipo di entità. Facciamo un esempio per chiarire il concetto. Immagina di avere un sistema di gestione dei contenuti (CMS) che gestisce post, tag e categorie, e per ciascuno di questi elementi vuoi aggiungere delle immagini. Senza l'uso di tabelle polimorfiche, dovresti creare una tabella dedicata per le immagini di ogni entità: una per le immagini dei post, una per le immagini dei tag, e così via. Man mano che aggiungi nuove funzionalità che richiedono immagini (o altri tipi di media), il numero di tabelle cresce, aumentando la complessità del database e del codice. Con una tabella polimorfica, invece, puoi creare una singola tabella chiamata media, che può essere utilizzata per salvare tutte le immagini, indipendentemente dall'entità a cui appartengono. La tabella media può essere strutturata in questo modo: id mediaable_type mediaable_id file_name file_type file_size created_at 1 Post 5 img1.jpg image 2048 2024-08-20 10:00:00 2 Tag 3 img2.png image 1024 2024-08-20 10:05:00 3 Category 1 img3.jpg image 512 2024-08-20 10:10:00 mediaable_type: Questo campo memorizza il tipo di entità a cui è associato il media, come Post, Tag, Category, ecc. mediaable_id: Questo campo memorizza l'ID dell'entità specifica a cui il media è associato. file_name, file_type, file_size, created_at: Questi campi memorizzano informazioni specifiche relative al file, come il nome, il tipo, la dimensione e la data di creazione. Utilizzando questa tabella polimorfica, ogni entità (post, tag, categorie, ecc.) può facilmente collegarsi ai media senza dover creare nuove tabelle per ogni tipo di relazione. Ora, immagina di voler implementare un sistema di "like" o di "votazioni" per diverse entità, come post, commenti, foto, ecc. Seguendo lo stesso principio, puoi creare una tabella polimorfica per i "like": id likeable_type likeable_id user_id created_at 1 Post 5 1 2024-08-20 11:00:00 2 Comment 12 2 2024-08-20 11:05:00 3 Photo 3 1 2024-08-20 11:10:00 Qui, likeable_type e likeable_id funzionano allo stesso modo di mediaable_type e mediaable_id, consentendo a un "like" di essere associato a qualsiasi entità del sistema. In sintesi, utilizzando solo tre tabelle polimorfiche (media, likes, votes), puoi gestire una vasta gamma di relazioni nel tuo database, risparmiando tempo e riducendo la complessità rispetto all'approccio tradizionale di creare tabelle separate per ogni entità. Questo non solo semplifica il design del database, ma rende anche il codice più manutenibile e flessibile a cambiamenti futuri. Le app grandi usano questo approccio se no immagina cosa diverrebbe il database. Per il gender molto piu semplice, un componente statefull che salva e tieno lo stato del gender e poi ti crei le query di filtraggio apposito, quando cambia lo stato si aggiorna e l applicativo.
Te lo riscrivo qui visto che probabilmente non sei riuscito a leggere il commento nel video precedente...
"Molto bello il progetto, scusami sono un po ignorante in materia...lavoro come ux designer quindi nella parte di codice ne so poco o nulla. Voglio chiederti...non sarebbe più semplice lavorare, sulla struttura UI e logistica su FlutterFlow mentre la parte di identificazione e gestione dei database su Supabase? Magari nel caso il progetto cresca potresti integrare un ERP e un CRM tipo Bitrix 24 o Odoo? Così facendo il processo di realizzazione si semplificherebbe tantissimo o sbaglio?"
Ciao tu quindi ti indirizzeresti verso un No Code giusto ?
@@vittodal Esatto...ma anche no visto che i servizi no code attuali ti permettono di fare il giusto...ma per approfondire e rendere il lavoro migliore devi comunque mettere mano al codice.
Se vuoi un consiglio sopratutto per i like, commenti, o star usa il polimorfismo nelle tabelle cosi nel caso servissero like, commenti ecc passi il modello invece che creare un altra tabella correlata, anche per un sistema multilingua e uno dei migliori sistemi di gestione, io però lavoro con uno stack backend in base al progetto che è Python o PHP(django, flask, symfony, laravel) quindi parliamo di oop e programmazione a oggetti...per la questione del gender puoi creare un componente dove l utente selezione il gender o nelle impostazioni o con un menu apposito a comparsa e da li filtri quello che ti serve con le query, il componente deve avere uno stato quindi deve essere statefull.
Ciao quindi tu includeresti tutte le informazioni in una singola riga dedicata al "post" ?
@@vittodal Il polimorfismo è un approccio di design estremamente utile per rappresentare relazioni di tipo "molti-a-molti" o "uno-a-molti" tra entità di diversi tipi, permettendo di gestire le relazioni in modo uniforme senza la necessità di creare tabelle separate per ogni tipo di entità.
Facciamo un esempio per chiarire il concetto. Immagina di avere un sistema di gestione dei contenuti (CMS) che gestisce post, tag e categorie, e per ciascuno di questi elementi vuoi aggiungere delle immagini. Senza l'uso di tabelle polimorfiche, dovresti creare una tabella dedicata per le immagini di ogni entità: una per le immagini dei post, una per le immagini dei tag, e così via. Man mano che aggiungi nuove funzionalità che richiedono immagini (o altri tipi di media), il numero di tabelle cresce, aumentando la complessità del database e del codice.
Con una tabella polimorfica, invece, puoi creare una singola tabella chiamata media, che può essere utilizzata per salvare tutte le immagini, indipendentemente dall'entità a cui appartengono. La tabella media può essere strutturata in questo modo:
id mediaable_type mediaable_id file_name file_type file_size created_at
1 Post 5 img1.jpg image 2048 2024-08-20 10:00:00
2 Tag 3 img2.png image 1024 2024-08-20 10:05:00
3 Category 1 img3.jpg image 512 2024-08-20 10:10:00
mediaable_type: Questo campo memorizza il tipo di entità a cui è associato il media, come Post, Tag, Category, ecc.
mediaable_id: Questo campo memorizza l'ID dell'entità specifica a cui il media è associato.
file_name, file_type, file_size, created_at: Questi campi memorizzano informazioni specifiche relative al file, come il nome, il tipo, la dimensione e la data di creazione.
Utilizzando questa tabella polimorfica, ogni entità (post, tag, categorie, ecc.) può facilmente collegarsi ai media senza dover creare nuove tabelle per ogni tipo di relazione.
Ora, immagina di voler implementare un sistema di "like" o di "votazioni" per diverse entità, come post, commenti, foto, ecc. Seguendo lo stesso principio, puoi creare una tabella polimorfica per i "like":
id likeable_type likeable_id user_id created_at
1 Post 5 1 2024-08-20 11:00:00
2 Comment 12 2 2024-08-20 11:05:00
3 Photo 3 1 2024-08-20 11:10:00
Qui, likeable_type e likeable_id funzionano allo stesso modo di mediaable_type e mediaable_id, consentendo a un "like" di essere associato a qualsiasi entità del sistema.
In sintesi, utilizzando solo tre tabelle polimorfiche (media, likes, votes), puoi gestire una vasta gamma di relazioni nel tuo database, risparmiando tempo e riducendo la complessità rispetto all'approccio tradizionale di creare tabelle separate per ogni entità. Questo non solo semplifica il design del database, ma rende anche il codice più manutenibile e flessibile a cambiamenti futuri.
Le app grandi usano questo approccio se no immagina cosa diverrebbe il database.
Per il gender molto piu semplice, un componente statefull che salva e tieno lo stato del gender e poi ti crei le query di filtraggio apposito, quando cambia lo stato si aggiorna e l applicativo.
Che IDE usi ?
Ciao uso Cursor 👋
A cosa serve l' App?
Ciao l'idea è di realizzare un app che permetta agli utenti di poter digitalizzare il proprio Guardaroba e trovare nuove ispirazioni