Let's create a new page. Since the design will be made by the designer, I only invest on the essential tags. But, even before creating my HTML, I can create the tests. From the requirement, I will have two screens: one list of all cities grouped by state, and a page with a list of vCards for that city. First, the tests (after all, it's TDD!):

@Test
public void testRendering() {
  WicketTester t = new WicketTester(CitiesPage.class);
  t.startPage(CitiesPage.class);
  t.assertRenderedPage(CitiesPage.class);
}
@Test
public void testStateBinding() {
  WicketTester t = new WicketTester(CitiesPage.class);
  t.startPage(CitiesPage.class);
  t.assertComponent("states", ListView.class);
  t.assertListView("states", getStates());
  t.assertComponent("states:0:name", "name-of-first-state");
}
@Test
public void testCityBinding() {
  // new tester, start, assertList...
  t.assertBookmarkablePageLink("states:0:cities:0:link",
                               NextPage.class, "city=0");
}

I put all tests here for simplicity, but, in TDD, I create only the first test, then correct, go for the second and so on. This will fail. I solve by creating the stub page and the bindings:

<div wicket:id="states">
  List of State <span wicket:id="name">Lorem ipsum</span>
  <div wicket:id="cities">
    <span wicket:id="name">City's name</span>
    <a href="#" wicket:id="link">Go for it</a>
  </div>
</div>

And, the Wicket's WebPage constructor:

public MyPage() {
  add(new ListView("states", getStates()) {
    protected void populateItem(ListItem item) {
    }
  });
}

And, the best part of TDD is I can make my code step-by-step: I implement the list binding, then I implement the list iteration, then, the cities binding inside "populateItem", until I finish the page. Much easier than implementing then testing. And it's a lot error-proof, too. When we make the code before the test, it's common to make a test that "just works" and having a lot of small glitches. Thinking about the test first, we develop code that needs to pass the requirements.

I finally fulfilled my dream of doing real TDD, from UI to persistence! Thanks wicket team! Now, I only hope it does not have any performance (or security) problems.

The last step (that usually takes huge time from me) is making a design that fits the code. But this part will be darn easy: I make a free (as in "freedom") design with a WYSIWYG editor and add the wicket markups, testing it direct on Safari/Firefox/IE/Opera, without the need of a slow "edit-deploy-run-test" cycle (mandatory for JSF or similar). ]]> http://extremejava.tpk.com.br/2011/07/08/tdd-with-wicket/feed/ 0 http://extremejava.tpk.com.br/2011/07/07/vhost-capabilities-with-wicket/ http://extremejava.tpk.com.br/2011/07/07/vhost-capabilities-with-wicket/#comments Thu, 07 Jul 2011 23:01:49 +0000 Eduardo Costa http://extremejava.tpk.com.br/?p=230 I started using Wicket because I liked how easy is to create SEO URLs and design-centric applications. One crazy feature I got working was customizing an application based on the vhost. The example I asked on StackOverflow used a fictional "abc.com" hosting with "abc.com.br" and "abc.com.pl" aliases.

The example works as this: all three vhosts are on the same codebase (i.e. the same "host" on Tomcat, with three aliases) and shows the same data. The difference between ".com", ".com.br" and ".com.pl" relies on how the data is shown to the user. There are two major country-related materials:

1. Page design - ".com" must see an American tribute (USA is #1, American Flag, etc); ".com.br" must show Brazilian stuff (Samba, Soccer teams, etc); ".com.pl" shows Polish material. This was really easy, using a ResourceStreamLocator in my Wicket Application:

   getResourceSettings().addResourceFolder("");
   getResourceSettings().setResourceStreamLocator(
       new ResourceStreamLocator() {
     @Override
     public IResourceStream locate(Class clz, String path) {
       String host = ((WebRequest) RequestCycle.get().getRequest())
           .getHttpServletRequest().getServerName();
       String basePath = trimFolders(path);
       IResourceStream res = super.locate(clz, host + "/" + basePath);
       return (res != null) ? res : super.locate(clz, basePath);
     }
     private String trimFolders(String path) {
       return path.substring(path.lastIndexOf("/") + 1);
     }
   });

2. Contextual URL mounting - this part was hard. Assume a page named "Page1". It must be accessed using "abc.com/page1", "abc.com.br/pagina1" and "abc.com.pl/strona1", but not with combinations (e.g. "abc.com/strona1"). After asking in SO, I got an answer from "biziclop" that lead me to the solution I wanted. It's a servlet filter mapping vhost to WicketFilter instances, isolating Wicket application instances (as biziclop sugested):

   @WebFilter(urlPatterns = "/*")
   public static class Filter implements IWebApplicationFactory,
                                         javax.servlet.Filter {
     private final Map filters = new HashMap();
     private final ThreadLocal hosts = new ThreadLocal();
     private FilterConfig config;
    
     @Override
     public void init(FilterConfig filterConfig) {
       this.config = filterConfig;
     }
     @Override
     public void destroy() {
       for (WicketFilter w : filters.values()) {
         w.destroy();
       }
       filters.clear();
     }
     @Override
     public void doFilter(ServletRequest request,
         ServletResponse response,
         FilterChain chain) throws IOException, ServletException {
       hosts.set(request.getServerName());
       try {
         getFilterForHost().doFilter(request, response, chain);
       } finally {
         hosts.remove();
       }
     }
     private WicketFilter getFilterForHost() throws ServletException {
       String host = hosts.get();
       if (!filters.containsKey(host)) {
         WicketFilter w = new WicketFilter() {
           @Override
           protected IWebApplicationFactory getApplicationFactory() {
             return Filter.this;
           }
         };
         w.init(config);
         filters.put(host, w);
       }
       return filters.get(host);
     }
     @Override
     public WebApplication createApplication(WicketFilter wf) {
       return new WicketApp(hosts.get());
     }
   }

1. Vector is thread-safe, ArrayList isn't;
2. ArrayList supports null items;
3. Vector's enumerations are not fail-fast; and
4. You can pass the capacity increment to Vector's constructor.

SwingWorker is abstract and needs you to implement a method "doInBackground" that is the equivalent of "Thread.run". So far, no changes. First difference is that SwingWorker implements "Future", this means it will return the result of processing. Second one is you can override methods like "done" and "process", to work with the result in EDT after the task finishes and partial results, respectively.

SwingWorkers can be cancelled with "cancel(boolean)". This changes a "cancelled" flag that can be checked with "isCancelled". BTW, if the parameter is "true", an old-school "interruption" will also be made on the task.

In "doInBackground", you can also call "progress" (running in worker thread) to report partial results to "process" (in EDT).

SwingWorker has bound properties, specially "progress" (int ranging from 1 to 100, perfect for JProgressBar), and "state" (PENDING, STARTED, DONE), and two type parameters: first for the return type, second for the partial result type (if any).

I need to invest some time in my old projects (like GEBORA) to use this incredible leverage.

BTW, if you need a thread pool, pass SwingWorker to an Executor.

1. Hashtable is thread-safe, HashMap isn't - that's something everybody knows;
2. HashMap supports null keys and values - not so obvious, but very important;
3. Enumerators returned from an Hashtable aren't fail-fast. Iterators from both classes are.

That was one of many questions I had to answer in a job interview. I admit I couldn't remember the second and third ones. I think I must study to upgrade my SCJP certification to refresh this kind of detail.

The old MapEditor is a "demigod class" that is the centre of all logic of the editor (I guess that's why they abandoned the project). Everything is there: layer management, tileset choosing, among others. It's over 2000 lines!

The first feature I will refactor is the layer management. Just like the Tileset Manager, I created a TopComponent sensitive to MapEditor selection (available from the main editor). The difference is I'm using the NB's Outline view to reproduce the old table layer style, and the layer node implements CheckableNode's contract (with "checked" meaning "visible").

Another interesting behaviour is the toolbar below the layer table. I used a JToolBar with this recipe to add its buttons:

for (Object obj : Lookups.forPath("...")
    .lookupAll(Object.class)) {
  if (obj instanceof JSeparator) {
    tbrBottom.addSeparator();
  }
  if (obj instanceof Action) {
    tbrBottom.add((Action) obj);
  }
}

Using this snippet with NB's actions registered on layer.xml, it was easy to make an extensible toolbar with buttons synchronized to the Outline's selection.

As a last tip, I associated an InstanceContent to the layer TopComponent's lookup. This IC adds the global selection (i.e. the map shown in the Outline view) to the TC lookup. The resultChanged method is:

Collection<? extends TiledMap> c = result.allInstances();
if (!c.isEmpty()) {
  TiledMap map = c.iterator().next();
  ic.add(map);
  em.setRootContext(new RootNode(map));
} else {
  ic.set(Collections.EMPTY_LIST, null);
  em.setRootContext(Node.EMPTY);
}

Using this snippet retains the global selection when user put the focus on layer TC. Without this workaround, it loses the selection, like this example.

I started with a new "TileSet Manager" module, then moved the TSM dialog to that module and changed it to a JPanel. After adding a TC and putting the TSM Panel on it, half-work was done. Thanks to the Swing skills of Tiled team, the next step was a piece of cake. After tracking the global selection, I only made the right "setEditor" on their manager and voilá! The tileset table changes according to the selected file! God bless the NetBeans Team!

It's already very cool, but I want more. Their version uses JTables and lots of buttons on this dialog. What about using NBP's ExplorerManager? Easy as 1-2-3. I replaced the TSM Panel with a BeanTreeView plus some Nodes and the ExplorerManager (just like FeedReader tutorial). I could use OutlineView to keep the table look, but I plan to add some depth on this tree later. And, instead of a table with two columns, I use a nice tree view with HTML display name:

Migration of actions started by the most complex one: Delete. Adding the action to the ExplorerManager and their JButton's actionPerformed to Node.canDestroy and Node.destroy did the trick.

There were other actions, like "Save As" and "Embed". All of them were easy to convert. I cut the code on "actionPerformed", pasting it on new actions. I put them on NB layer and used this snippet to convert them to Node.getActions:

@Override
public Action[] getActions(boolean context) {
  List<Action> list = new ArrayList<Action>();
  for (Object obj : Lookups.forPath("...")
      .lookupAll(Object.class)) {
    if (obj instanceof JSeparator) {
      list.add(null);
    }
    if (obj instanceof Action) {
      list.add((Action) obj);
    }
  }
  return list.toArray(new Action[list.size()]);
}

Nonetheless, their screenshot made me think: "this MUST be refactored to be a NetBeans Platform App". There's a lot of dialogs, splitpanes, toolbars, etc. It is an waste of time doing that on Swing.

Let's see the situation of the source code:

• Almost abandoned - only a couple of commits this year. Check.
• No plans to keep it up-to-date - blame the QT version. Check.
• GPL licensed. Check.

That's the recipe that allows me to play with this cool application, refactoring it from Swing to NBP.

I started by cloning their Mercurial repository (cool, I can keep their SCM history). Then, I run it with NetBeans. Now that I know it works, I deleted the project metadata (build.xml and nbproject) and created a new NBP-based Application. Their old source on "src" I moved to a new "src" inside a "Legacy Integration" module.

Now, the fun part: remove the junk. There's a lot of cool features on the original project, but almost all of them NBP does too:

• Plugin support, with custom classloader and other stuff. Deleted
• Multiple filetype support. Imploded to support only native formats
• Command line parsing. Split in a new module, using NB own support

Up to this point I have: nothing! After all, that application was SDI with JFrame. To make the editor working again, I created a "TMX File Support". The first version of TMXDataObject contained only an OpenCookie that opens a TopComponent. In this TC, I embedded the Tiled JFrame components (editor, menubar, statusbar, etc). This ugly workaround worked pretty nice! And the Application is now MDI!

After some cleanup, it was pretty easy to migrate their NewMapAction to NB layer.xml, the SaveAction to a SaveCookie and SaveAsAction to SaveAsCapable. In a matter of minutes, their editor was fully integrated with NB file support, including the conditionally enabled "Save" button.

Next step is the Tileset Manager. Currently it is a JDialog, and I will migrate it to a TopComponent (like Navigator).

Stay tuned!

Test your configuration with "hostname -i". It must show server's IP. If it shows 127.0.0.1, change your /etc/hosts file according to this example:

192.168.2.200  myserver     myserver.mydomain
127.0.0.1      localhost    localhost.localdomain
::1            localhost6   localhost6.localdomain6