Hey Kito -

Thanks again for looking at this.  So regarding the BehaviorHolder/ClientBehaviorHolder, the reason why I moved this over to ClientBehaviorHolder is because the two methods that actually deal with Behaviors really do want ClientBehaviors, not just any Behaviors.  These methods are:

  public void addClientBehavior(String eventName, ClientBehavior behavior);

Note that this method is "event" specific - ie. it is implied that you are attaching a behavior to a specific client-side event for the purpose of providing a script for that event, so this really expects ClientBehavior, not just any Behavior.

Ah, I see.


And:

  public Map<String, List<ClientBehavior>> getClientBehaviors();

This method returns the mappings between event names and ClientBehaviors.  So again, this is very event/client-specific.  As such, I prefer not go with ClientBehaviorHolder rather than parameterize this type.

Ok. Fair enough. Sounds good, then.


BTW - the current status on the refactoring, after discussing this with Ed and Roger - I am planning to merge at 6PM EST.  So if anyone objects to this last minute refactoring, please speak up.

Martin -

I would still like to hear confirmation from you that this addresses your concerns.  I'll definitely sleep better knowing this. :-)

Andy

Kito Mann wrote On 3/12/2009 3:42 PM ET:

Andy,

In general, +1. I wonder, however, if ClienyBehaviorHolder shouldn't be BehaviorHolder<? extends Behavior>.
Sent from my iPhone

http://www.jsfcentral.com
http://www.Virtua.com