writelesscodeblog

Let’s say we have a grid listing clerks, and we want to be able to assign a boss to a clerk (yes, my favorite setup). A traditional way to do this is by using a combobox listing available bosses as options. Netzke does it for you automatically when it detects a foreign key between the model’s attributes. However, sometimes we want to be in more control over how one-to-many associations are handled in Netzke grids and panels. This tutorial will show you how to configure the following:

• How each boss should be represented in the drop-down list. Will it be her first name or last name? Or maybe an arbitrary string that combines them both and eventually includes some extra info (such as the boss’ salary)?
• Scoping out bosses in the drop-down list. We may not want to list all the bosses in the drop-down list. How could we limit those to a specific department, for instance?

Update 1: This tutorial assumes Rails 2.3.x and Ruby 1.8.7.
Update 2: Added a remark in the 3rd section about the changed columns configuration not being reflected in the grid (thanks Noel!).
This post will lead you through simple steps of creating a task manager web application with Ext JS, Ruby on Rails, and Netzke. It will take you approximately 7 minutes to build (if everything runs as smooth as on my own – quite ordinary – setup), and if you’re beforehand curious whether it’s worth 7 minutes of your time, go straight to the last section but one (by far the biggest in this tutorial), where we discuss what we achieved.

This blogpost will focus on how Netzke lets you specify and configure a model’s (virtual) attributes mapped to columns (in grids) and fields (in forms). The way it was done before passed through several iterations of improvements, and finally I can say that I found an approach I’m currently happy with. It’s very flexible, but at the same time the resulting code is readable, concise, and simply looks very habitual. Which problems is it solving? 1) Imagine, you want to render some HTML code in a grid cell (a link, an icon, etc). You could easily declare a method right in the model and use it as a virtual attribute. But it totally doesn’t feel right to put this into your model, as it’s about presenting the data, not the data itself. 2) Besides, different widgets may need different “representational” attributes for the same model – how would we handle that? Mix them in, in some way, into the model all together? Doesn’t feel right either, especially if there are naming conflicts. 3) Also, different widgets may need to render the same attribute in a different way (e.g., with different formatting). Well, all this is now covered in Netzke. Read on.

Recent update to Netzke (the framework that helps you build ExtJS/Ruby-on-Rails applications) introduces support for FamFamFam Silk icons. All you have to do is download the icons and put them into your public/images/icons folder (so that the icons are accessible via http://yourhost.com/images/icons) – the next time you restart your Rails application, Netzke will detect the icons and start using them. As always, this update is reflected on the Netzke live demo page. And if you want to know how to customize the icons – read on.

The Netzke project is now over a year old, and several developers have since then started using it in their projects, creating their own widgets and using the pre-built widgets from netzke-basepack. Recently, the netzke-core gem has been updated to version 0.5.0, and this update has simplified the way a Netzke widget gets embedded in your Rails application. First of all, no longer is it needed to define widgets in the controller – simply put them straight into your views using the netzke helper. All the AJAX communication between the client and server side of widgets will now be routed through the netzke_controller, which is a part of netzke-core. In this post I’ll provide a couple of examples of embedding Netzke widgets into the Rails views. In case you haven’t yet appreciated the simplicity and flexibility of the Netzke framework, then, hopefully, this post will get you hooked.

Working on my client’s app (the first commercial Netzke-driven application planned to go live on December 1st), I got tired of repetitively writing JavaScript/ExtJS code for different windows that pop up here and there. They were all doing a similar thing: dynamically loading some Netzke widget at the moment of being shown. Besides boring coding, it had another drawback: the windows didn’t remember its dimensions and position. So, finally I asked myself: how long would it take to write an Ext.Window-based Netzke widget that would be able to aggregate other widgets just the same way as BorderLayoutPanel, TabPanel, and others do? Well, it appeared to be so simple, that I’ll dare post the whole source code in this post. For those who have followed my previous tutorials, it’s not going to be difficult to understand what’s going on here.

Today I’m coming up with a light-weight tutorial, which will show how to extend a Netzke widget in order to add a custom Ext.Action into it, and then bind that to a new button in the bottom bar, as well as to a new context menu item. Then you’ll see how we can conditionally disable this action for more consistent end-user’s experience. If ExtJS actions are still something new to you, you’ll find this tutorial especially useful, as I’ll provide a brief introduction unto them. Otherwise you’ll see how easy it is to use Ext.Action with Netzke. As usual, there’s an online demo of this tutorial’s results, and the source code is on GitHub.

While debugging AJAX-reach Rails applications (which is the case when you use ExtJS) with Rails >= 2.3.0, you wish you could get the full backtrace of an exception written to development.log, rather than sent to the browser (where you don’t see it anyway unless you dig into the Firebug log). It cost me some futile searching on the Internet in pursue to figure out how to reclaim the full backtrace in the logs, while the solution appears to be extremely simple – you just have to know where to look.

This post continues the series of the tutorials on building Netzke widgets – reusable pieces of code for a Rails/ExtJS application. It extends the slightly outdated part 2, and demonstrates the power of the new client-server communication concept introduced in netzke-core v0.4.0. We will build (from scratch) a composite widget that will nest 2 GridPanels (linked by a one-to-many relationship) and a FormPanel that will display some details about the record that is selected in one of the grids. I will show how easy it is to update all nested widgets within one single client-server roundtrip – an approach which gives the developer a new level of freedom in building complex widgets. You will also learn about new configuration options introduced into Netzke::GridPanel. The live demo for this tutorial can be found here.

I had to put Netzke aside for a while in order to do some contract job to maintain my traveler’s life. It was a nice change by itself: I was doing “pure Rails”, no Ext, and, among other things, had to put my hands on Cucumber, which was a lot of fun. However, the idea to create a real-world application using Netzke kept on penetrating my mind, and, after preliminary evaluation of the effort with one of my clients, I finally set off for the adventure.