Behavior on the Grid

Today, the good people of Runtime Revolution Ltd. presented an impressive webinar, showcasing the brand new Data Grid control that is a salivating new feature of Revolution 3.5 - in fact, this new control has given us a lot more than what most people would want from a table control. You can setup everything from a straightforward table with multiple alignments, to a spectacular form with dynamically resizing rows containing arbitrary controls with judicious use of template groups.

This crown jewel was developed using the other new big technological addition to Revolution: behaviors. This allows you to write a script once and apply it to several other controls at once - and when you update the original behavior script, all those controls adopt the change in behavior automatically.
Of course, if you're used to object-oriented programming, this sounds like simple inheritance. The xCard paradigm, pioneered over 20 years ago by Apple's HyperCard is traditionally object-based but not fully object-oriented; there's a limited set of built-in controls and you can 'specialize' these by adding a script.
Another typical OO design pattern, Chain of Responsibility, was the basis of the xCard message path, which allows developers to place handlers for events, command and function calls in a central place - if you needed to know where the event originated, you could use 'the target' property to work your magic from there.

Strictly speaking this was enough to build something like the Data Grid in the past, but the new 'behavior' feature makes it a lot easier. The 'me' object points to the 'target' rather than the button that contains the 'behavior' script - so we no longer have to subject ourselves to 'long id' shenanigans to make sure we're modifiying the right controls.
Experiments with the new 'behavior' scripting methods have me pondering how I can adopt this for all my Revolution projects and which controls I can rebuild and put together in a single library for reuse - and perhaps for others to use. Ah, if only there was a function to conjure a Time-Turner so I could do everything I want to do but fail to find the time for...

Service-Orientation vs. Object-Orientation

What better way to fill an hour-long lunch-break than by reading up on various websites? Some people like to play cards and others take a stroll around the village. Lots of people leave breadcrumbs in their keybpoard as they read their private emails, but my daily ritual includes trips to MacWorld, MacUser, OreillyNet, Java.Net, JavaWorld and JavaLobby.

Today I bumped into this fresh post by Masoud Kalali on JavaLobby: Service-Orientation vs. Object-Orientation: Understanding the Impedance Mismatch. Even if your language of choice is Revolution and therefore not object-oriented (even if it's object-based, but we'll leave that for some other time) you'll still want to head over to the site and read the article. After all, a smart programmer keeps his horizons broad so he knows which is the right tool for a particular job, right?

Object-oriented programming has long established itself as a solid software development paradigm, improving on procedural programming by offering encaspulation, inheritance and polymorphism. Service-oriented architecture may still be surrounded by a lot of buzzwords,(often referred to as the SOA ALphabet Soup) but has clearly shown the way to seamless interoperability, regardless of development platform or operating system.

Both OOP and SOA promote reuse. And as more and more business models, developed using an object-oriented language like Java, need to expose their logic as services, it naturally becomes important to do it correctly: rather than just exposing all individually available procedures and functions as web services, you should take a step back and think very hard about exactly what services you seek to offer the outside world.

The innards of your system may be as tightly- or loosely-coupled as you prefer, the truth is that there's a lot of methods in your classes that you're only going to use internally. Services are better defined in terms of business processes, anyway: your 'order entry' service would be wise to offer both a high-level 'do it all in one go' service where an entire order can be created using a single XML structure that includes master and detail information, and a fine-grained 'do just one thing at a time' API to create/read/update/delete one part at a time.

So setting up your services becomes a matter of defining the sensible parts of a workflow, starting with a small area of your application and expanding as it makes sense, based on the feedback of the users of your services - which can be colleagues in the IT-department or external partners. In such an approach, services unsurprisingly have a lot in common with 'task oriented' user interfaces, where the user is guided through the different steps of the process - not in the sometimes belittling way of wizards, but as part of a way to empower the user by concentrating on his or her job.

Information Technology in general and software development in particular are in so many ways still in their infancy. And as we're growing up, we're relearning things from the past, re-inventing how combining existing and sometimes considered-obsolete technologies delivers new value and makes our applications more powerful while easier to use. It feels great to take part in all this...