2010-07-11 8 views
8

Tengo problemas para entender esto. Básicamente, esta API de búsqueda se utiliza para mantener la naturaleza intermodule ligeramente acoplada. ¿Entonces, básicamente, un proveedor de servicios y los módulos de consumidores pueden comunicarse entre sí utilizando la API de búsqueda correcta?¿Qué es la búsqueda de netbean?

Pero lo que no entiendo es:

es búsqueda, tal como una bolsa llena de objetos, que por esa clase? ¿Alguien puede dar una analogía más fácil?

Entonces, ¿se crean las dependencias, y usted implementa LookupListener en el consumidor del servicio correcto? Obviamente, el consumidor tiene dependencia del proveedor.

Entonces, ¿qué es la implementación de LookupListener escuchando? Es su propia búsqueda? Entonces, si hay un mapa de la clase de otro módulo, se almacenará como un objeto dentro de la Búsqueda de la implementación de LookupListener?

¿Entonces la búsqueda es como una bolsa que puede almacenar las clases de otro módulo y sus métodos?

¿Es este el proceso correcto para determinar una selección?

  1. en el TopComponent (ver) implementa el Listener de búsqueda y el Listener de acción.
  2. usted hace un nuevo objeto (desde el otro módulo)
  3. associateLookup(Lookups.singleton(fff)); de nuevo, confusión con esta línea: ¿qué está haciendo exactamente associateLookup()?
  4. result = Utilities.actionsGlobalContext().lookupResult(Browser1.class); ¿Qué está haciendo esta línea? ¿Qué es el resultado? ¿Contiene la clase Browser1 (de otro módulo)?
  5. result.addLookupListener (this); ¿Por qué agregarías oyente al resultado? y qué estamos escuchando y por qué en TopComponent?

  6. Hecho?

Y finalmente, para aumentar mi confusión, ¿cómo entra en juego la API del nodo?

+2

Puede encontrar mucha información y videos de la plataforma NetBeans aquí: http://netbeans.org/kb/trails/platform.html – Jesper

Respuesta

2

Puede pensar en búsquedas como una herramienta básica que admite alto cohesión flojo principio de cohesión.

Básicamente, usted tiene una API en beverage-api módulo:

public interface Beverage { 
    ... 
} 

Luego otro módulo beers que depende de beverage-api:

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

en otro módulo, que también depende de beverage-api se puede escribir una fórmula mágica :

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

que le proporcionará una lista de todos los proveedores de bebidas sin declarar la dependencia exacta de la clase específica o tener dependencia de ese módulo. Esto es genial, su código no depende de la implementación específica, es suficiente con tener estos módulos en la ruta de la clase y se cargarán "automáticamente" en su aplicación.

associateLookup(Lookups.singleton(fff)); nuevamente, confusión con esta línea: ¿qué está haciendo associateLookup() exactamente?

Sí, eso es confuso. Básicamente está agregando manualmente algún objeto al sistema de búsqueda.

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

Utilities.actionsGlobalContext() se relaciona con seleccionado actualmente (activo) TopCompoment. Devolverá una instancia de Beverage.class si existe en el componente activo. Si desea todas las instancias de clase dada, debe usar lookupAll().

result.addLookupListener(this); ¿Por qué agregaría listener al resultado?

Para recibir avisos sobre los cambios. Cuando el usuario selecciona algunos Beverages objetos se dispara LookupListener método:

void resultChanged(LookupEvent ev); 

y result.allInstances(); volverá qué instancias fueron seleccionados.

Cuestiones relacionadas