Hi Andy,
sorry, I was incredibly in stress these last two days. However, I am
very happy with your proposal as it stands now!
regards,
Martin
On 3/12/09, Andy Schwartz <andy.schwartz(a)oracle.com> wrote:
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.
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.
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
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces