[JAVA] Sfoltimento/Ricerca tramite Jtextfield

[lotus1989]

Buonasera,
ecco un dubbiettino sulla possibilità di implementare una Jtextfield che ricerchi in un DB
una determinata parola.
Il problemi sono i seguenti:

- esistono delle componenti che possano comportarsi come una searchbar del browser? se no,
che ne dite di un implementazione ad hoc di una Jtextfield che possa, mentre l'utente digita una parola,
carattere per carattere, un controllo su una lista o altra struttura che effettua un
semiautocompletamento?

es: ho una lista con dentro cane, mucca, casa , patata, gatto.
nella mia Jtextfield voglio cercare "casa".
Inizio digito 'c' e la Jtextfield mette una 'c' e poi, visto che è la prima parola che compare con la 'c',
mette in maniera che il carattere sia selezionato ''ane"....e così così fino a che non si trova la parola
desiderata. Se è quella desiderata, si preme invio e si attiva il metodo ActionPerformed() che avrò
implementato per far una determinata cosa..

- la struttura di cui ho chiesto delucidazioni mi serve per fare una ricerca in un DB, e vorrei sapere se la
mia idea (di seguito presentata) è una soluzione prestante, intelligente, stupida, o quanto altro si voglia..
1. caricamento dei dati dal db in modo da non effettuare continue richieste
in una lista che verrà ordinata secondo un determinato criterio
2. estensione Jtextfield che mano mano che acquisisce caratteri fa ciò che ho detto sopra sfoltendo la
lista che ho creato dall'import dei dati
3. azione immediatamente seguente al fatto di aver trovato o non trovato la parola cercata (stringa)
nella lista

Ps: si lo so, sono prolisso, però molto disposto a critiche e insegnamenti

[valia]

Ci sono pro e contro di una situazione del genere e la scelta finale dipende da come vorrai usare un componente.
Creare un componente personalizzato è la soluzione per me migliore (visto che una roba simile alla tua l'ho fatta), però ti faccio alcune domande

1. quanto è grande la tabella che devi interrogare? quante info per ogni record devi mantenere? quanto cambia la tabella?
mi spiego, se la tua tabella è di piccole medie dimensioni, con pochi campi (che hanno grandezza minima)e che cambia raramente, la soluzione più indicata è mantenere il tuo valore e la chiave in un hashmap sempre in memoria e la ricerca come dici tu diventa ottimale.
Devi inoltre implementare eventuali meccanismi di update della tabella (se qualcuno modifica i dati devi mantenere la consistenza degli stessi)
Se la tabella inizia a crescere come campi, puoi comunque mantenere solo pochi dati in memoria ed eventualmente fare interrogazioni ad hoc (soluzione che ho adottato io)
Inoltre se la tabella è grande anche come numero di record, non diventa subito un problema mantenerla in memoria, ma diciamo che non devi programmare pensando che hai risorse infinite (cosa che si tende a fare oggi).
2. con quale frequenza usi il componente e la struttura in memoria? Pensi di avere un campo che usi tanto (quindi continui accessi creano problemi), magari per riferirti a campi della tabella differenti? se la risposta alla seconda domanda è no, conviene un'interrogazione al db che non mantenere dati che usi poco o niente.
3. pensato meccanismi di temporizzazione prima di attivare la ricerca (es. non ricercare ogni tasto, magari appena ti fermi ogni 2/3 sec)?
4. pensato a meccanismi di astrazione per generalizzare e riutilizzare il componente (e si può fare te l'assicuro)?

Inizia a valutare queste cose, già dovrebbero darti un'idea dei vantaggi e svantaggi di una scelta

[lotus1989]

Originariamente inviato da valia
1. quanto è grande la tabella che devi interrogare? quante info per ogni record devi mantenere? quanto cambia la tabella?

In realtà ho un pannello che contiene 42 Jlabel, 34 Jtextfield, 8 Jcombobox e 1 bottone(diventeranno 2 o 3 i bottoni perchè intanto ho messo solo quello salva).
La ricerca mi servirebbe per consentire all'utente di cercare un articolo tramite l'inserimento di una parola in una delle 4 Jtextfield che ho deciso di lasciare editabili quando istanzio il pannello e lo visualizzo
(codiceArticolo - Descrizione Ita - Descrizione Deu - Descrizione Eng).
Si effettua la ricerca e se nulla soddisfa ciò che l'utente ha inserito si sta inserendo un nuovo articolo,
altrimenti visto che si è trovato un articolo che ha quella proprietà si compilano tutti i campi che ha compilati quello salvato e si da la possibilità di modifica.

2. con quale frequenza usi il componente e la struttura in memoria? Pensi di avere un campo che usi tanto (quindi continui accessi creano problemi), magari per riferirti a campi della tabella differenti? se la risposta alla seconda domanda è no, conviene un'interrogazione al db che non mantenere dati che usi poco o niente.

Oddio, viene usato solo nella fase iniziale questa ricerca proprio per garantire all'utente di trovare un articolo oppure di inserirlo. Di per sè una volta capito ciò, la Jtextfield modificata diventa pressochè inutile per quell'articolo, qualunque esso sia..

3. pensato meccanismi di temporizzazione prima di attivare la ricerca (es. non ricercare ogni tasto, magari appena ti fermi ogni 2/3 sec)?

Hehe spero i mod mi passino la parola, ma questo sarebbe davvero figo! (saperlo fare )
Questo si darebbe modo di controllare senza sprecare risorse o meglio usarne troppe inutilmente..

4. pensato a meccanismi di astrazione per generalizzare e riutilizzare il componente (e si può fare te l'assicuro)?

Hehe per il mio stile di programmazione, anche se non posso dire di esser un espertone, ma solo uno studente che si è appassionato a java, tanto da riscrivere il programma del padre di 1/2 di mezzo secolo fa, posso dire che tutto ciò che è riciclabile, metodizzabile, ripetitivo o simile cerco sempre di riutilizzarlo.. :P

[valia]

in genere quello che fai tu è fatto per riempire in automatico campi.
Che so, inizi a mettere il nome e se l'articolo c'è vai a riempire già gli altri campi (che spesso poi a quel punto fissi non editabili). Visto che già mi parli di codice articolo io inizialmente opterei per una situazione in cui se premi invio o tab oppure ti sposti verso un altro textfield fai la ricerca per quel codice inserito, se trovato riempi tutto altrimenti consenti l'inserimento di altri dati.
Farei questa semplificazione perché ti concentri inizialmente su come fare la ricerca e bene e poi implementi le altre finezze.
A quanto ho capito è una roba locale, quindi che te frega di tenere la roba in memoria? quando ti serve fai una query e via. Tenere la roba in memoria crea problemi come ti dicevo di consistenza (se un altro utente modifica un campo devi agire di conseguenza) e problemi di spreco ( non è detto che usi l'intera tabella).

Senza fare riferimento a bean questa è la soluzione migliore (per me) per "esercitarti" con swing, ereditarietà e astrazione.

[lotus1989]

Originariamente inviato da valia
in genere quello che fai tu è fatto per riempire in automatico campi.
Che so, inizi a mettere il nome e se l'articolo c'è vai a riempire già gli altri campi (che spesso poi a quel punto fissi non editabili).

Si si l'idea è proprio in base a quella ricerca di rivisualizzare l'articolo con tutti i suoi dettagli.
Però voglio assolutamente lasciare la modificabilità di certi campi perchè l'import e visualizzazione viene
fatta proprio per dare, oltre la possibilità di vedere le caratteristiche dell'articolo, la possibilità
anche di modifcarne certe (ad esempio uno vuole cambiare la descrizione o la data di scadenza)

Visto che già mi parli di codice articolo io inizialmente opterei per una situazione in cui se premi invio o tab oppure ti sposti verso un altro textfield fai la ricerca per quel codice inserito, se trovato riempi tutto altrimenti consenti l'inserimento di altri dati.
Farei questa semplificazione perché ti concentri inizialmente su come fare la ricerca e bene e poi implementi le altre finezze.
A quanto ho capito è una roba locale, quindi che te frega di tenere la roba in memoria? quando ti serve fai una query e via. Tenere la roba in memoria crea problemi come ti dicevo di consistenza (se un altro utente modifica un campo devi agire di conseguenza) e problemi di spreco ( non è detto che usi l'intera tabella).
Senza fare riferimento a bean questa è la soluzione migliore (per me) per "esercitarti" con swing, ereditarietà e astrazione.

Si hai ragionissima: infatti il problema di consistenza dei dati verrà valutato attentamente quando avviene la modifica dell'articolo, perchè quando uno lo inserisce nuovo ha un record vergine e non c'è nessun problema di inserimento.. mentre con la modifica intanto i dati posson subire variazioni e vanno riassestati.