X

Geertjan's Blog

  • February 2, 2007

JavaMail Client on the NetBeans Platform (Step 3)

Geertjan Wielenga
Product Manager
At the end of part 2 of this series (here), we ended up with a JavaMail client integrated in a NetBeans TopComponent. This was a major achievement (at least, for me). As a result, we had in fact ported our Swing application to the NetBeans Platform. However, that was but a start. After all, as argued at length in that blog entry, porting a Swing application to a platform means that one, ultimately, wants the user experience of the platform to match that of the integrated application. In the case of our JavaMail client, the TopComponent contained everything, in terms of user interface components, that the original application provided. That is not how one would want it. Ideally, you'd smear out your original application all over the platform, leveraging those platform features that are useful to the maximum, and generally behaving like a good citizen within one's new home. For an application with an explorer window, for example (as in the case of the JavaMail client), you'd want to use an explorer window provided by the platform, instead of being stuck within the TopComponent. (Ultimately, one would want a TreeTableView, in this case, but that will come later.)

So, here you see an explorer window, containing the folders of my mailbox:

It may seem like only a little bit of work, and not very impressive at that, but consider this—these are the actual folders in my mailbox and I didn't hardcode them into the module. Therefore, via the JavaMail API, this module accesses my mailbox (which is on an SSL-secured IMAP server, somewhere in the realm of Sun Microsystems), retrieves my folders, and displays them via the Nodes API in my new explorer window. Complete integration is a long way away, and the e-mails are quite far from being integrated in my new JavMail client module, but it's been interesting exploring the Nodes API within the context of my porting exercise.

One further thought about the Nodes API in light of what I wrote in my blog entry yesterday—since the Nodes API is a design pattern, you need to approach it in a different way to standard APIs in the world out there. In the same way as you cannot expect to understand (to the point of being productive) any other design pattern very quickly (e.g., the Model-View-Controller design pattern), it takes a while to really 'get' the Nodes API (and I am quite far from 'getting' all or even most of it). Of this learning aspect in relation to the Nodes API, Tom Wheeler wrote me this today: "I would not call the process 'intuitive'. Rather, it was a long, cold walk down a hall of despair until I finally met enlightenment." Secondly, though, as with any other design pattern—once you do understand it properly, you have a very powerful coding friend. After all, that's what a design pattern is for, to give you guidance and to organize your code in a logical and maintainable way. That's what I've found to be true so far for the Nodes API too, despite the inherent learning curve of the design pattern. Maybe we should not call it "Nodes API", but "Swing Node Design Pattern", because that's closer to what it is and sets the expectation more correctly.

Join the discussion

Comments ( 2 )
  • Craig Ziesman Saturday, March 3, 2007
    Any chance that you could post/provide the code you developed to manage your mailboxes using the Nodes API?


    I am having trouble figuring out how to create dynamic nodes using the API. All of the tutorials/examples on netbeans.org only show static nodes with children. I need to listen for changes to my data model and add nodes on the fly without user intervention. There are no examples (that I can find) of how to add children to existing nodes without requiring some sort of user action.
    Thanks!
  • guest Thursday, March 29, 2007
    gffhfdghdfghdf
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.