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
> >
>
