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.
Here’s some news about the Netzke framework: netzke-core v0.3.0 and netzke-basepack v0.4.0 gems are about to be released. In this post I’m putting a screencast (my first one, some things may not seem very smooth), that shows off a feature that I consider to be “a must have” before I come to my client and seriously suggest him to completely rewrite his old web-based app with Netzke. I call it “masquerading” - it’s all about intuitive application configuration, and I know that my client will love it.
UPDATE (2009-09-07): This tutorial is outdated with the release of netzke-basepack v0.5.0. Please, refer to part 3 which is an up-to-date and extended version of this tutorial.
This tutorial will show you how to build a composite reusable Netzke component which consists of 2 grids (glued together by Ext’s border layout) that display data from Rails models connected by one-to-many relationship. We’ll build it in the context of the already existing netzke-demo project (this demo runs live on http://netzke-demo.writelesscode.com/), so that we can spare some time reusing its models and infrastructure. The resulting widget will contain a grid with bosses and a grid with clerks. Selecting a boss will update the clerks grid with the clerks working under that boss. Adding a clerk will automatically bind him to the selected boss. You’ll learn how to create a custom Netzke widget using GridPanel and BorderLayoutPanel widgets from netzke-basepack (a gem that contains several pre-built, extendible Netzke widgets). If you prefer to quickly see the results rather than to follow this tutorial step-by-step (an added value of which would be to see several functional iterations of our widget), you can go straight to its live demo. For those that want to be led through the process of creating a Netzke widget and get a deeper understanding of how Netzke works - read on, and don’t let the volume of the post scare you too much, as you can easily skip over some details and have a coffee between the sections :)
UPDATE (2009-09-07): This tutorial is outdated with the release of netzke-basepack v0.5.0. Please, refer to the project's wiki for updated articles. After releasing the next version of the Netzke gems, I also updated the live demo (http://netzke-demo.writelesscode.com/). Along with some minor fixes (like preventing the user to trigger sorting on virtual columns in the GridPanel), and providing a FormPanel-based widget in the “General” pane of a widget’s configuration window, the BasicApp demo has been updated in a way that it no longer requires the user to log in. However the access to the User management is only granted to an authenticated user. Further I describe those simple steps that were needed to achieve that.
If you had a look into the Netzke code, you’d see that for constructing JavaScript classes, a lot of the JavaScript code gets dynamically generated by Ruby. JavaScript code is mixed right into the Ruby functions. I adore the power of generating one dynamic language code with another dynamic language, however I didn’t feel comfortable typing JavaScript inside Ruby due the following reason: TextMate would neither highlight the JavaScript fragments, nor allow you to use the JavaScript-bundle goodies (like snippets) in it, as it “sees” the JavaScript code as simple Ruby strings. If you’d like to know how to reclaim that comfort - read on.
I wanted it from the very beginning: nesting widgets easily. Say, I need a widget which has a border layout and 2 grids in it. I need each grid to communicate to its own instance on the server, e.g. getting the data from the respective models. I also want the layout to do its own thing - e.g., communicate to its own server-side instance that the user has changed the region sizes (to store them in the preferences for this user). But I also want it all to behave like one widget: e.g. one grid displaying the one-to-many association data for the other (say, one grid shows bosses, and the other - the clerks working under the selected boss). How is this achieved in Netzke? By using the double underscore convention to address nested widgets, and the blessing of Ruby's method\_missing method.
