Building a client-side application requires you to model data, of course. This client-side data model may be different from any server-side data model you may have. On the client-side you can mix data from different server-side data models, for instance.

For our Twitter-search application we'll define a quick & dirty model with the following entities:

Figure 1. Entities and DAOs

(Click to enlarge)

The relationships between these entities are as follows: a Query has a list of Tweets (the results of the query) and each Tweet has a TweetAuthor. Figure Entities and DAOs explains graphically these relationships.

We'll keep all these entities in a Java package called, say, "net.antonioshome.nbtweeting.entities". The entities will be plain old Java objects, this is, "Java Beans" with an empty constructor and getters and setters. Something like this:

package net.antonioshome.nbtweeting.entities;

public class Query
{
  private String keyword;
  private List<Tweet> tweets;

  public Query() 
  {
    tweets = new ArrayList<Tweet>();
  }

  public List<Tweet> getTweets()
  {
    return tweets;
  }

  public void setKeyword( String keyword )
  {
    this.keyword = keyword;
  }

  public String getKeyword()
  {
    return this.keyword;
  }
  

Note that if you're building a database application, these entities may or may not reflect the internals of your database model. In my experience is better not to bring the database structure to the client-side model. You'll be suffering if you do: it is better to have a separate model, even though you have to rewrite some plain Java objects. Anyway this discussion does not belong to these notes, so let's keep going quickly. Next section, please!

We will also need some basic Data Access Objects which will be responsible for searching using the Twitter Search API.

The "TwitterSearchDAO", for instance, will receive a "Query" object and will talk to Twitter to receive some, say, XML. It will then parse this XML and build some "Tweet" and "TweetAuthor" entities, and will update the list of Tweets in the Query entity. The source code could look something like this:

package net.antonioshome.nbtweeting.dao;

public class TwitterSearchDAO
{
  public List<Tweet> search( String keyword ) throws Exception
  {
    // Talk to Twitter, parse XML
    // Create a list of Tweet and return it
    ...
    

If you're building a two-tier database application then this "dao" package will usually have SQL or JPA related queries. If you're building a three-tier web-service based application then these "DAOs" will be responsible for fetching stuff from remote web services. Note that, as I explained above, these DAOs return client-side entities, and not database entities.

If you're building a database application you may want to add a light transaction-aware layer in between the rest of your client-side application and the DAOs. This "transaction-aware" layer may combine different DAOs in a single client-side transaction. If you build a 3-tiered application then this layer belongs to the server side, of course. Oh, well, I'm talking off-topic again. Let's keep going!

One of the most imporant and powerful idioms in the NetBeans Platform is that you can add capabilities to existing objects dynamically. You do this by using the NetBeans Lookup Library.

You can, for instance, add the "Saveable" capability to an object at runtime, to indicate that the object can be saved. Once the object is saved you can remove that ability from the object.

Some other capabilities could be, for instance: the "Closeable" capability (for objects that can be closed, such as forms, projects or files). The "Openable" capability (for objects that can be opened by the user). Or the "Reloadable" capability (for objects that can be reloaded by the user).

Let's see briefly what we need to make our entities "capability enabled".

/**
  * Reloadable is an ability contained in objects that can be reloaded.
  */
public interface Reloadable
{
  /**
    * Invoke this method to reload the entity.
    * @throws Exception if the entity cannot be reloaded.
    */
  public void reload() throws Exception;
}
      

public final class Query 
implements Lookup.Provider 
{
  private String keyword;
  private List<Tweet> tweets;
  private Lookup lookup; 
  private InstanceContent instanceContent; 
  public Query()
  {
    this.tweets = new ArrayList<Tweet>();
    this.instanceContent = new InstanceContent(); 
    this.lookup = new AbstractLookup( instanceContent ); 
    this.instanceContent.add( new Reloadable() { 

      public void reload() throws Exception {
        TwitterSearchDAO dao = new TwitterSearchDAO();
        tweets.clear();
        tweets.addAll( dao.search( keyword ) );
      }
    } );
  }
  public Lookup getLookup() 
  {
    return lookup;
  }
  ... // Rest of getters and setters
      

Query query = ... // any object implementing the Lookup.Provider interface

// Get the "lookup" of the object, and lookup for the "Reloadable" ability...
Reloadable reloadable = query.getLookup().lookup( Reloadable.class );

// If the reloadable ability exists then reload the object...
if ( reloadable != null ) 
{
  try
  {
    reloadable.reload();
  }
  catch( Exception e )
  {
    ...
  }
}

We've defined a set of entities such as Tweet, TweetAuthor and Query, that we'll be using in our client-side application. These are our own entities, and have nothing to do with whatever entities Twitter is using internally. We don't mind that.

We've also encapsulated all business logic (in our case a simple query to the Twitter Search API) inside a DAO.

Finally we've quickly seen how to add abilities to our entities by using the NetBeans Lookup Library. We know how to add an ability to an object, and how to search the abilities of any object.