Eelco Hillenius wrote:
It's good to know that when you reach the same conclusion it is a deliberate
one.
BTW, interfaces are useful for this, but not a necessity. Or am I the only
one thinking that
No, I agree with you mostly. However, I was trying (back then) to
define separate dimensions of components (the fact that they can be
rendered is one, and for form components for instance, the fact that
they can validate is another). If you have a bunch of useful
distinctions like that, you can just decorate them for specific
purposes. Maybe.
Yeah. Some problem domains are better suited for this kind of
interfacing than others. In one project we work on we have interfaces
like PropertyHolder and TemplateHolder, but other projects keep to a
stricter OO hierarchy with only one or two interfaces at the base (or top?)
I can see merit in interfaces like IRenderable and IValidatable. An
interface for lifecycle could be useful too. One problem could be that
when only Component (or somesuch) implements all the useful interfaces,
people are never going to implement one of the interfaces themselves. An
interesting framework could be Qi4J, to be able to independently
implement the interfaces. They gave a presentation at the wicket meetup
in amsterdam (I wasn't there, but heard about it and looked it up).
(I seem to be... hmm...). More interfaces mean even more
scrolling through the I's in the javadoc, nooooo, lol.
Indeed, it gets ugly pretty fast. Mixins and interfaces with
implementations like scala has would be wonderful here, but alas,
we'll have to work with Java.
Java is not so bad. We'll just have to wait until someone writes a
java2scala conversion app :)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
