On Thu, Jul 17, 2014 at 9:08 AM, Garret Wilson <gar...@globalmentor.com> wrote: > On 7/17/2014 8:25 AM, Martin Grigorov wrote: >> >> ... >> >> For some reason this feature doesn't seem that usable to me... > > > Could you be more specific about why you don't find this feature doesn't > seem useful? None of your comments below were about the feature > itself---they were about ancillary implementation details, such as whether > the "assert" keyword should be used. > > This feature proposal is based upon the following assumptions: > > * Many developers will want to use the Wicket framework with > third-party frameworks that require certain attributes and/or CSS > classes in certain circumstances. > * Adding third-party library support shouldn't require subclasses a > lot of components. (Otherwise, I'd have a PureCSSButton, and I'd > have to instantiate PureCSSButtons throughout the code... until I > changed frameworks, at which point I'd have to change them all to > BootStrapButtons.) > * Third-party library support should be isolated from main UI code and > from business logic. That is, I shouldn't have have to go add > PureCSSAttributeBehaviors to all my buttons throughout the code, > intermingled with my CSS framework-agnostic code. > > > If one of those assumptions are invalid, let me know. Otherwise, do you have > an alternative approach for me to easily add Pure CSS support for all my > buttons (for example) in one locations without going through all my UI code, > and then tomorrow to switch to using the Bootstrap framework (with its > different required attributes for buttons and such) without changing all my > code? If there is an alternative, great. But I don't see how you can say > there is no need for such a feature.
there is no need for the wrapper you provide. everything you want is already possible using IComponentInstantiationListener - which you already use. there are a few issues with the convenience wrapper: * you are forcing developers to share the behavior instance across multiple components this may be undesirable in some cases and inconvenient because it forces the behavior design to be stateless or store data using metadata instead of fields. while ok for simple things like appending a class it makes developing more complex behaviors difficult. * the mapping is not flexible enough suppose you want a link that opts out of this behavior for whatever reason. maybe you do it by implementing some interface on the link. now all methods in the behavior have to check for this interface. much easier to check for the interface and just not add the behavior. * the wrapper doesnt provide any real value its just a convenience and one that doesnt work for the 90% case. how many lines of code does it save? not many. we dont add such wrappers because they blow up the api surface area. -igor > > Garret > >
