I’ve come full circle since part 1 in this mini-saga, and am now describing my simple WebEx XML web service with three classes in a WebEx module.

Ruby modules offer the programmer the ability to group classes together into like structures and to control namespaces for methods. They also function as a sort of pseudo-class, in that you can define “module methods” inside the module that feel like class methods. If you have a module Foo and a method self.bar, you can call it with Foo.bar.

That’s what I ended up doing with all the helper methods I’ve got in this new class definition — WebEx.time_from_string, WebEx.filter_by_session_name, etc.

I also abstracted the things I’d need into several classes. Now the XML client has:

• An Attendee class to describe the most common type of API data we need to create and manipulate
• An XMLObject class which describes a generic object containing XML and the recipe necessary to process it into Ruby data structures (implemented as a Proc object), as well as class methods for generating various types of such objects
• A Request class which is responsible for sending an XMLObject to the WebEX API, sending the retrieved data through the object’s processor, and exposing the processed data as well as the processed result strings from the API request.

Here’s how you’d create an attendee (I’m stipulating the existence of an initialized Attendee object — @attendee)

Gist of the new WebEx module

This is necessarily kind of a spare time project. It’s something for work, but it does what it’s meant to just fine right now, so re-factoring it is something I’m doing in spare cycles. However, I’m gratified that continued refactoring has brought me back to the original idea of having a simple class with class methods that mirror the API’s methods. I had to trip through the things that brought me to make the other classes and gather everything together into a module, but it was a helpful (if stumbling) process to go through.