2010-07-11 8 views
8

Ho difficoltà a capirlo. Fondamentalmente, questa API di ricerca viene utilizzata per mantenere la natura intermodale liberamente accoppiata. Quindi, fondamentalmente un fornitore di servizi e moduli consumatori possono comunicare tra loro utilizzando l'API di ricerca corretta?Che cos'è la ricerca di netbean?

Ma quello che non capisco è:

è Lookup come una borsa piena di oggetti che per quella Classe? Qualcuno può dare un'analogia più facile?

Quindi le dipendenze vengono create e si implementa LookupListener nel servizio clienti corretto? Ovviamente il consumatore ha dipendenza dal fornitore.

Quindi qual è l'implementazione di LookupListener in ascolto? È proprio Lookup? Quindi se c'è una mappa della classe di un altro modulo, verrà memorizzata come oggetto all'interno della Ricerca dell'implementazione di LookupListener?

Quindi la ricerca è un po 'come una borsa che può memorizzare le classi di un altro modulo ed i suoi metodi?

È questo il processo corretto per determinare una selezione?

  1. in TopComponent (vista) si implementa il listener di ricerca e il listener di azioni.
  2. si crea un nuovo oggetto (dall'altro modulo)
  3. associateLookup(Lookups.singleton(fff)); di nuovo, confusione con questa riga: cosa fa esattamente associateLookup()?
  4. result = Utilities.actionsGlobalContext().lookupResult(Browser1.class); cosa fa questa linea? qual è il risultato? contiene la classe Browser1 (da un altro modulo)?
  5. result.addLookupListener (this); Perché dovresti aggiungere l'ascoltatore al risultato? e cosa stiamo ascoltando e perché su TopComponent?

  6. Fatto?

E infine, per favorire la mia confusione, in che modo viene introdotta l'API del nodo?

+2

È possibile trovare molte informazioni e tutorial video sulla piattaforma NetBeans qui: http://netbeans.org/kb/trails/platform.html – Jesper

risposta

2

Si può pensare a Lookups come uno strumento di base che supporta il principio di coesione libero ad accoppiamento libero.

In pratica si dispone di un'API nel modulo beverage-api:

public interface Beverage { 
    ... 
} 

Poi un altro modulo beers che dipende beverage-api:

@ServiceProvider(service = Beverage.class) 
public class SomeBeer implements Beverage { 
    ... 
} 

in un altro modulo, che dipende anche dalla beverage-api è possibile scrivere una formula magica :

Collection list = Lookup.getDefault().lookupAll(Beverage.class); 

che ti fornirà un elenco di tutti i fornitori di bevande in giro senza dichiarare la dipendenza esatta dalla classe specifica o la dipendenza da quel modulo. Questo è ottimo, il tuo codice non dipende dall'implementazione specifica, è sufficiente avere questi moduli sul percorso della classe e verranno caricati "auto-magicamente" nella tua applicazione.

associateLookup(Lookups.singleton(fff)); di nuovo, confusione con questa riga: cosa fa esattamente associareLookup()?

Sì, questo è confuso. Fondamentalmente stai aggiungendo manualmente alcuni oggetti al sistema di ricerca.

result = Utilities.actionsGlobalContext().lookupResult(Beverage.class);

Utilities.actionsGlobalContext() è relativo a attualmente selezionato (attivo) TopCompoment. Restituirà un'istanza di Beverage.class se esiste nel componente attivo. Se vuoi tutte le istanze di una determinata classe, devi usare lookupAll().

result.addLookupListener(this); Perché aggiungere l'ascoltatore al risultato?

Per ricevere notifiche sui cambiamenti. Quando l'utente seleziona alcuni Beverages oggetti si innesca LookupListener metodo:

void resultChanged(LookupEvent ev); 

e result.allInstances(); tornerà quali casi sono stati selezionati.

Problemi correlati