Hi,
For some reason this feature doesn't seem that usable to me... Maybe other
devs and users will like it...
See some comments from me inline:
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sun, Jul 13, 2014 at 3:21 AM, Garret Wilson <gar...@globalmentor.com>
wrote:
On 7/12/2014 3:14 PM, Garret Wilson wrote:
... The approach I am proposing allows one to encapsulate a whole series
of behaviors and component associations within one "bundle".
Another benefit of "behavior bundles" is that in Wicket 7.x, legacy
behavior (such as wrapping disabled links in <em><span>) could easily be
included in a Wicket6BehaviorBundle. This would obviate the need for
one-off backwards-compatibility classes <https://issues.apache.org/
jira/browse/WICKET-4904?focusedCommentId=14059918&page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel#comment-14059918> such as
DisabledLinkBehavior.LinkInstantiationListener to be included in the main
framework.
But without further ado, here is the class itself. Please tell me what you
think about it. I'd like to contribute it. (I couldn't help but use a few
Google Guava classes---they are so useful, and I've grown accustomed to
having them handy, but if it's not possible to use them I can rip them out
before submitting a patch.) Note the documentation around multiple
registration of behaviors---I didn't know what Wicket allows in the way of
a behavior added multiple times, so I took a simple implementation and
documented it.
As a reminder, the bundle is used like this (but preferably someone would
create bundle subclasses to distribute separately):
final BehaviorBundle pureCSSBehaviorBundle = new BehaviorBundle();
pureCSSBehaviorBundle.registerBehavior(AbstractLink.class, new
DisabledClassAttributeAppender("pure-button-disabled"));
getComponentInstantiationListeners().add(pureCSSBehaviorBundle);
After some discussion on the list, would it be appropriate for me to go
ahead and create a JIRA and then submit a patch? (I guess I'll be forced to
touch Git, now. ;) )
Code below. Cheers!
Garret
/**
* A collection of behaviors associated with component classes. When added
to the application's collection of component
* instantiation listeners, the designated behaviors will be registered
with the associated components and their subclasses. This
* facilities grouping behaviors based upon functionality or library.
* <p>
* For example, the <a href="http://purecss.io/";>Yahoo! Pure CSS</a>
library requires that <a
* href="http://purecss.io/buttons/";>disabled buttons</a> have the
<code>pure-button-disabled</code> class. A behavior bundle may
* be created supporting this feature maybe be added as follows:
* </p>
*
* <pre>
* <code>BehaviorBundle pureCSSBehaviorBundle = new BehaviorBundle();
* pureCSSBehaviorBundle.registerBehavior(AbstractLink.class, new
DisabledClassAttributeAppender("pure-button-disabled"));
* getComponentInstantiationListeners().add(pureCSSBehaviorBundle);</code>
* </pre>
* <p>
* Note that a production behavior bundle would likely create a {@link
BehaviorBundle} subclass containing the appropriate
* behaviors to be distributed as a unit.
* </p>
* @author Garret Wilson
* @see Application#getComponentInstantiationListeners()
*/
public class BehaviorBundle implements IComponentInstantiationListener {
/** The lock governing multithreaded access to the registered component
behaviors. */
final ReadWriteLock lock = new ReentrantReadWriteLock();
Usually Wicket apps add the IXyzListeners in Application#init(). So there
is no really need to use locking.
It is possible to add/remove listeners (and in your case register
behaviors) in the "business logic" (e.g. after clicking some link or
similar) but usually people don't do it. Or at least I haven't seen such
code.
/** The map of behaviors, accessed under {@link #lock}. */
private final ListMultimap<Class<? extends Component>, Behavior>
behaviorMap = ArrayListMultimap.create();
/**
* Registers a behavior with a component class for adding to each
component when it is instantiated.
* <p>
* Behaviors registered with a given class will be added to instances of
any child classes as well. For example, registering a
* behavior for {@link AbstractLink} will result in the behavior being
added to instances of e.g. {@link BookmarkablePageLink}
* as well.
* </p>
* <p>
* Behaviors registered twice for one class, or at multiple places in
the hierarchy of a class, will consequently be added
* multiple times to the same component.
* </p>
* @param componentClass The class and subclasses of which the behavior
should be registered.
* @param behaviors The behavior to register for addition upon component
instantiation..
* @return The bundle itself, to allow method call chaining.
*/
public BehaviorBundle registerBehavior(final Class<? extends Component>
componentClass, final Behavior behavior) {
since you use Guava anyway I think it would be better to use Precondition
that accepts the Class instead of the Class itself. It will be much more
flexible in the future.
lock.writeLock().lock();
try {
behaviorMap.put(checkNotNull(componentClass),
checkNotNull(behavior));
} finally {
lock.writeLock().unlock();
}
return this;
}
/**
* {@inheritDoc} This implementation adds all behaviors registered with
the component's class and all parent classes up to and
* including {@link Component}. Behaviors will be added in order from
the most general (close to {@link Component} to the most
* specific (the component's actual class).
*/
@Override
public void onInstantiation(final Component component) {
lock.readLock().lock();
try {
addBehaviors(component, component.getClass());
} finally {
lock.readLock().unlock();
}
}
/**
* Adds all registered behaviors to the given component based upon the
given component class and the parent classes, stopping at
* {@link Component}.
* <p>
* Parent class behaviors are added first in order to allow general
behaviors to take effect earlier.
* </p>
* <p>
* This method should only be called under a read lock.
* </p>
* @param component The component to which the behaviors should be added.
* @param componentClass
*/
//we ensure manually that the parent classes are subclasses of Component
@SuppressWarnings("unchecked")
protected void addBehaviors(final Component component, final Class<?
extends Component> componentClass) {
//do a depth-first traversal to add general (super-class) behaviors
first
//no need to look higher up the hierarchy than Component
if (!componentClass.equals(Component.class)) {
final Class<?> parentComponentClass = componentClass.getSuperclass()
;
//the class is a subclass of Component; because we stop when we find
Component,
//we expect never to run out of parents
assert parentComponentClass != null;
In Wicket we don't use JDK's assert anywhere so far.
In my experience these should be used only in the application code. A
library/framework should not change its behavior depending on JVM argument.
addBehaviors(component, (Class<? extends Component>)
parentComponentClass);
}
//add behaviors (if any) registered for this class
for (final Behavior behavior : behaviorMap.get(componentClass)) {
component.add(behavior);
}
}
}
