Guys I think the next logical step are to build some annotations and see
how it goes. Discover what great things that could come up:) As we
probally all agree we do not want to put annotations in wicket just
because we can, it has to have a purpose. When we have some material,
then a good constructive discussion can get started:)
So i suggest that we start this as a separate project and if at some
point we decide that it's the best thing for wicket, let it be included
in extensions or so.
I'll be happy to help out. Although no experience with writing
annotations...
-regards Nino
Johan Compagner wrote:
By the way, the mount anotation is in my eyes a nice one
On 1/12/08, Johan Compagner <[EMAIL PROTECTED]> wrote:
The example with a stateless annot for a page is a bad example
All pages are stateless by default as far as i know or does Page or
WebPage really override the isStateless() method to return false by
default? Cant remember at this time. But the components on the page
are the triggers for the page.
So yes the stateless annot could make sense but then more for
components or behaviors. But i dont know how mandy people use that
explictily.
On 1/11/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I think I have shared my part in writing about the pro's and con's I
see for the @Mount annotation, and all I got in return was "I don't
like annotations".
Why does it have to be a HUGE improvement? Annotations *ARE* Java! Not
some foreign, alien construct: pure Java.
than considering whether a plain Java alternative would be
appropriate. We should not make the same mistake with annotations.
I don't buy the "annotations are replacements for XML configuration"
argument. Just because we do something inside class methods doesn't
mean it belongs there! We should not make the mistake to stay inside
the method. Annotations are a first class citizen in Java and should
be considered an equal alternative.
For instance the statelessness of a page. You specify that a page is
stateless. You now have to override a method to provide that logic,
but it is not logic... It is a configuration item that should be
orthogonal to the page. I find it much clearer to see this specified
in an annotation rather than some obscure overridden method 10 pages
down:
@Stateless
public class MyPage extends WebPage {
public MyPage() {
}
}
Don't get me wrong: I also don't want to spray arbitrary annotations
around. Having 10 annotations before a page would make that rather
illegible. However I am not going to ignore the usefulness of
annotations because of "I don't like them" arguments. They have good
uses, and I want to find those parts of our API that could better be
implemented using annotations than by subclassing and overriding.
Martijn
On Jan 11, 2008 9:11 PM, Eelco Hillenius <[EMAIL PROTECTED]>
wrote:
On Jan 11, 2008 11:53 AM, Martijn Dashorst <[EMAIL PROTECTED]>
wrote:
I *still* haven't heard one single technical argument against using
annotations apart from Igor's concern that we would need to scan the
classpath.
You could turn that around just the same. I haven't heard a good
technical argument in favor of it.
Seriously all the "I don't like annotations" arguments are getting
stale.
The main concern vented in this thread by several people is that we
should only introduce annotations if it leads to some big advantage. I
don't see what is wrong with that attitude. In fact, I think it is
very similar to our overall approach to API development.
You could easily go ahead and implement a separate annotations library
though. For those who would prefer that, it could be a nice extra. For
the core project however, we should be conservative. I personally
believe that one of the reasons why JEE ended up with a zillion of XML
heavy projects was because many developers liked this new shiny tool
that XML was a few years ago, and first thought of XML for solving
their problems (even if that meant finding 'problems' first), rather
than considering whether a plain Java alternative would be
appropriate. We should not make the same mistake with annotations.
My 2c,
Eelco
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
