As regards breaking encapsulation, externalising the rules is often the whole point of APIs like the above. People frequently find that they end up scattering the rules for a system all over the different classes, making the system hard to modify and to add and remove rules easily. Separating the rules out of the classes lets you apply and revoke sets of rules at runtime, which is useful.

Sometimes, the best approach to designing a system is to get all the objects to implement the available actions, and put all the decision-making logic in a set of rules. I suppose the closest familiar OO concept for all this would be the mediator pattern, in which all the objects in a system communicate through a centralised resource. JavaScript’s extreme maleability means this pattern does not need a formalised mediator object but can simply involve directly modifying objects and classes.

Have you seen: http://livepipe.net/projects/event_behavior/

It’s a very nice lib for ‘glue’ code… Looks like this:
with(Event.Behavior){
show(’state_field’).when(’country’).is(’United States’);
show(’province_field’).when(’country’).is(’Canada’);
}

We’ll have to see what becomes of it, but Javascript 2 as currently drafted up might make it possible to improve the readability (and it has method missing support).

I’ll give you this much: This is the first time I’ve seen someone doing something like this.