> I don't know. That would bound behaviors to one component (which is
> the common case now, but not something the interface enforces are -
> imo - should enfore). And besides that, what do you think would be the
> advantage to that?
Hmm... I thought that there were some methods in IBehavior
that implied that there was a single component attached to
it, but probably not then.
The reason why most methods get the component passed in is because
that way behaviors can be decoupled from single components and are not
forced to keep a reference to one.
Are ajax behaviors more strictly for one component per
behavior instance?
Typically I would say. Behaviors are pinned down to one component from
AbstractAjaxBehavior on. And that makes sense as ajax requests are
routed through the coupled component.
I ran into this with Ajax behaviors that have the public
Component getComponent() method, and sometimes with a deep
component hierarchy it would be clearer to have a more
specific return type than Component. I don't know if there
would be real advantage beyond that (and avoiding casting).
Maybe it is something to consider for AbstractAjaxBehavior then. Did
you try out yet?
Eelco
