You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2008/01/09 23:53:16 UTC
1.4/2.0 annotations support
We've tried annotations for lifecycle methods and that didn't work
out. But I think other parts of our API can benefit from annotations.
I suggest we take a look at annotations for:
* the mount with a page
* ........
Martijn
--
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
Re: 1.4/2.0 annotations support
Posted by Igor Vaynberg <ig...@gmail.com>.
there is no language provided way of doing this afaik - you basically
resort to the hack where you find the classes directory and start
scanning .class and .jar files inside...how does this work when there
are jars outside the classes dir - maybe in tomcat/common?
it is a pretty slow affair
will it work with osgi?
-igor
On Jan 9, 2008 3:19 PM, Martijn Dashorst <ma...@gmail.com> wrote:
> On Jan 10, 2008 12:15 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> > im not a big fan of scanning classpaths
>
> Are you willing to share your concerns?
>
>
> Martijn
>
> --
> 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
>
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
On Jan 10, 2008 12:15 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> im not a big fan of scanning classpaths
Are you willing to share your concerns?
Martijn
--
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
Re: 1.4/2.0 annotations support
Posted by Igor Vaynberg <ig...@gmail.com>.
im not a big fan of scanning classpaths
-igor
On Jan 9, 2008 3:10 PM, Martijn Dashorst <ma...@gmail.com> wrote:
> On Jan 10, 2008 12:06 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> > you mean @Mount("/foo") class MyPage extends WebPage {...}
> >
> > then we have to scan the classpath for all classes that have that
> > annotation.............
>
> Yep, though scanning classpath seems to be the rage currently.
>
>
> Martijn
>
> --
> 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
>
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
> > Yep, though scanning classpath seems to be the rage currently.
>
> Yes, it seems to be:
>
> http://bill.burkecentral.com/2008/01/14/scanning-java-annotations-at-runtime/
Thanks for the tip; looks like a good starting point.
Eelco
Re: 1.4/2.0 annotations support
Posted by Sean Sullivan <se...@seansullivan.com>.
On 1/9/08, Martijn Dashorst <ma...@gmail.com> wrote:
>
> On Jan 10, 2008 12:06 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> > you mean @Mount("/foo") class MyPage extends WebPage {...}
> >
> > then we have to scan the classpath for all classes that have that
> > annotation.............
>
> Yep, though scanning classpath seems to be the rage currently.
Yes, it seems to be:
http://bill.burkecentral.com/2008/01/14/scanning-java-annotations-at-runtime/
Sean
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
On Jan 10, 2008 12:06 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> you mean @Mount("/foo") class MyPage extends WebPage {...}
>
> then we have to scan the classpath for all classes that have that
> annotation.............
Yep, though scanning classpath seems to be the rage currently.
Martijn
--
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
Re: 1.4/2.0 annotations support
Posted by Igor Vaynberg <ig...@gmail.com>.
you mean @Mount("/foo") class MyPage extends WebPage {...}
then we have to scan the classpath for all classes that have that
annotation.............
-igor
On Jan 9, 2008 2:53 PM, Martijn Dashorst <ma...@gmail.com> wrote:
> We've tried annotations for lifecycle methods and that didn't work
> out. But I think other parts of our API can benefit from annotations.
>
> I suggest we take a look at annotations for:
> * the mount with a page
> * ........
>
> Martijn
>
> --
> 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
>
Re: 1.4/2.0 annotations support
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
I find the idea great. The other places where I've usage of this are xml
heavy frameworks like hibernate. You can then replace all the nasty xml
configurations with annotations.
However I don't see how that currently fit wicket? We just dont have a
lot of settings outside our javaclasses. Might just be good design:)
Only place where wicket has an xml setting right now are web.xml.
-my 2 cents
Martijn Dashorst wrote:
> We've tried annotations for lifecycle methods and that didn't work
> out. But I think other parts of our API can benefit from annotations.
>
> I suggest we take a look at annotations for:
> * the mount with a page
> * ........
>
> Martijn
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
On Jan 10, 2008 5:32 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> > Open questions:
> > - annotated page impossible?
> What do you mean?
Was: - annotated page impossible(?) to override/modify
Martijn
--
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
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
> Pro's:
> - a long list of mounts becomes unmanagable
> - easy to add a mount: work on a page, slap on the annotation and you
> have your mount done
> - locality of the configuration
>
> Con's
> - distributed configuration, so hard to see the 'big picture' (though
> a mounts page listing all mounts would help)
> - scanning of classpath at startup (though spring, struts, etc are
> doing that already)
> - multiple mounts at same position harder to detect, though that is
> already possible.
I agree with the pros and cons. The classpath scanning for classes may
be tricky. It should be one of the first things to explore then. If we
can pull this off reliably, we should solve this generically, so that
annotation processors can be layered and possibly plugged in by users.
> Open questions:
> - annotated page impossible?
What do you mean?
> - specifying the URL encoding strategy
That might actually be sweet.
> - multiple mounts for the same page
> - package mounting?
> - can we override the annotated mount?
No way. Such annotations should be 1-1 to a page, and only concrete pages.
> - how do we work with pages contributed using jars, could we disable
> the annotated mounts and provide our own?
Generic libraries should probably never have this. For people who
break up their apps in multiple projects (jars), we should just allow
these annotations.
Eelco
Re: 1.4/2.0 annotations support
Posted by Bruno Borges <br...@gmail.com>.
I don't know actually how this works, but I read a few things about it.
Unfortunately I'm out of time to do some PoC today. But here is the best
article I found:
http://www.onjava.com/pub/a/onjava/2004/04/21/declarative.html?page=3
Maybe tomorrow or someday in this week I get some time to do it.
Regards!
On Jan 15, 2008 5:50 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> On Jan 15, 2008 11:22 AM, Bruno Borges <br...@gmail.com> wrote:
> > The problem about scanning the classpath could be reduced if the
> developer
> > declares in package-info.java the information for that package, like if
> it
> > has Web Pages (annotated web pages) or any other relative information.
> >
> > This way, the framework would just scan for metadata at package level
> and if
> > it finds something, then scans all the classes inside of it.
> >
> > Any thoughts?
>
> Would you be able to create an example/ patch of how that would work?
>
> Cheers,
>
> Eelco
>
--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
On Jan 15, 2008 11:22 AM, Bruno Borges <br...@gmail.com> wrote:
> The problem about scanning the classpath could be reduced if the developer
> declares in package-info.java the information for that package, like if it
> has Web Pages (annotated web pages) or any other relative information.
>
> This way, the framework would just scan for metadata at package level and if
> it finds something, then scans all the classes inside of it.
>
> Any thoughts?
Would you be able to create an example/ patch of how that would work?
Cheers,
Eelco
Re: 1.4/2.0 annotations support
Posted by Bruno Borges <br...@gmail.com>.
The problem about scanning the classpath could be reduced if the developer
declares in package-info.java the information for that package, like if it
has Web Pages (annotated web pages) or any other relative information.
This way, the framework would just scan for metadata at package level and if
it finds something, then scans all the classes inside of it.
Any thoughts?
On Jan 15, 2008 6:57 AM, Mark Derricutt <ma...@talios.com> wrote:
> I like the idea, and for smaller projects it could be good.
>
> As an aside, you can already do the following:
>
> mount("/main", PackageName.forClass(AlohaPage.class));
>
> Whats the harm in extending this:
>
> mount("/main", PackageScanner.forClass(AlohaPage.class, WicketPage.class
> ));
>
> which scans the package (and subpackages maybe) for classes with the
> supplied annotation if we wanted flexibility. Because we're scanning just
> a
> known package, we can speed up the process and not scan -everything-.
>
> How about something like that?
>
>
>
> On 1/11/08, Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>
> wrote:
> > +10 for exploring, you just never know what handy feature turns up:) I
> > meant to say that to in my previous mail.
> >
>
--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
Re: 1.4/2.0 annotations support
Posted by Mark Derricutt <ma...@talios.com>.
I like the idea, and for smaller projects it could be good.
As an aside, you can already do the following:
mount("/main", PackageName.forClass(AlohaPage.class));
Whats the harm in extending this:
mount("/main", PackageScanner.forClass(AlohaPage.class, WicketPage.class));
which scans the package (and subpackages maybe) for classes with the
supplied annotation if we wanted flexibility. Because we're scanning just a
known package, we can speed up the process and not scan -everything-.
How about something like that?
On 1/11/08, Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>
wrote:
> +10 for exploring, you just never know what handy feature turns up:) I
> meant to say that to in my previous mail.
>
Re: 1.4/2.0 annotations support
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
That enables users to freely choose whether or not they want to use it.
+1 (if I get to vote)
-Nino
Eelco Hillenius wrote:
> On Jan 10, 2008 9:32 AM, Martijn Dashorst <ma...@gmail.com> wrote:
>
>> I think especially overriding setHeaders is not intuitive whereas an
>> annotation could really make a difference in readability. But that is
>> a different story.
>>
>> A simple 1 page guide showing the annotations and their uses is easy
>> enough to put on the web, in the distribution etc.
>>
>> Hibernate/EJB3's annotations are just as hard to discover. But somehow
>> folks do like them.
>>
>
> One thing to consider is - like Hibernate does - to package such
> annotation support into a separate project.
>
> Eelco
>
>
>
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
On Jan 10, 2008 9:32 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> I think especially overriding setHeaders is not intuitive whereas an
> annotation could really make a difference in readability. But that is
> a different story.
>
> A simple 1 page guide showing the annotations and their uses is easy
> enough to put on the web, in the distribution etc.
>
> Hibernate/EJB3's annotations are just as hard to discover. But somehow
> folks do like them.
One thing to consider is - like Hibernate does - to package such
annotation support into a separate project.
Eelco
Re: 1.4/2.0 annotations support
Posted by Igor Vaynberg <ig...@gmail.com>.
On Jan 10, 2008 9:32 AM, Martijn Dashorst <ma...@gmail.com> wrote:
>
> Hibernate/EJB3's annotations are just as hard to discover. But somehow
> folks do like them.
they like them because they are better then the alternative...
-igor
>
> Martijn
>
>
> On Jan 10, 2008 6:22 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> > > - @Stateless - instead of overriding isStateless
> > > - @Headers - define headers specific for the page
> >
> > Playing the advocate of the devil: the thing with those is that it
> > doesn't actually solve anything. I mean, you hardly decrease the lines
> > of code you have to write to achieve something, annotations are
> > arguably harder to discover than overridable methods, and we end up
> > with having multiple ways to do the same thing...
> >
> > 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
>
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
I think especially overriding setHeaders is not intuitive whereas an
annotation could really make a difference in readability. But that is
a different story.
A simple 1 page guide showing the annotations and their uses is easy
enough to put on the web, in the distribution etc.
Hibernate/EJB3's annotations are just as hard to discover. But somehow
folks do like them.
Martijn
On Jan 10, 2008 6:22 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> > - @Stateless - instead of overriding isStateless
> > - @Headers - define headers specific for the page
>
> Playing the advocate of the devil: the thing with those is that it
> doesn't actually solve anything. I mean, you hardly decrease the lines
> of code you have to write to achieve something, annotations are
> arguably harder to discover than overridable methods, and we end up
> with having multiple ways to do the same thing...
>
> 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
Re: 1.4/2.0 annotations support
Posted by Johan Compagner <jc...@gmail.com>.
Its not about is it technically easy or hard to do.
It must make sense, we really have to gain something
On 1/11/08, Martijn Dashorst <ma...@gmail.com> 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.
>
> Seriously all the "I don't like annotations" arguments are getting stale.
>
> Martijn
>
> On Jan 11, 2008 6:42 PM, Jon Steelman <jo...@gmail.com> wrote:
> > If we are talking about using annotations for anything that hints of
> > declarative programming, I'm not at all in favor. Nobody here...but some
> > folks are rabid about declarative programming and always find a new way to
> > attempt to finally make it work. It reminds me of the
> > Computer-Aided-Software-Engineering (CASE) debacle from the 80's which has
> > its latest incarnation as Model-Driven-Architecture (MDA). There are
> > fundamental reasons why CASE/MDA isn't really going to fly yet generation
> > after generation of folks get seduced into taking a crack at it.
> Declarative
> > programming (including systems that use annotations for declarative
> > programming) is to me another relative dead-end. Please don't saddle
> Wicket
> > with it. :-)
> >
>
>
>
> --
> 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
>
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
On Jan 11, 2008 1:25 PM, Martijn Dashorst <ma...@gmail.com> 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.
No, the point is here that you would have different ways to do the
same thing. Also, annotations are different from methods in classes.
> > 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.
Then we disagree. Annotations have a very different purpose (meta
data) compared to regular methods and members.
> 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() {
> }
> }
Yeah, I like @Stateless better too. But I don't like to have two
separate ways of doing the same thing.
> 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.
Well, then come with concrete use cases and argue for them. Let's
start putting those alternatives in a separate project, and later
argue whether they are useful enough to be put in the core project.
Eelco
Re: 1.4/2.0 annotations support
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
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 <jc...@gmail.com> 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 <ma...@gmail.com> 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 <ee...@gmail.com>
>>>
>> wrote:
>>
>>>> On Jan 11, 2008 11:53 AM, Martijn Dashorst <ma...@gmail.com>
>>>>
>>> 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
Re: 1.4/2.0 annotations support
Posted by Johan Compagner <jc...@gmail.com>.
By the way, the mount anotation is in my eyes a nice one
On 1/12/08, Johan Compagner <jc...@gmail.com> 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 <ma...@gmail.com> 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 <ee...@gmail.com>
> wrote:
> > > On Jan 11, 2008 11:53 AM, Martijn Dashorst <ma...@gmail.com>
> > 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
> >
>
Re: 1.4/2.0 annotations support
Posted by Johan Compagner <jc...@gmail.com>.
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 <ma...@gmail.com> 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 <ee...@gmail.com> wrote:
> > On Jan 11, 2008 11:53 AM, Martijn Dashorst <ma...@gmail.com>
> 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
>
RE: 1.4/2.0 annotations support
Posted by Maeder Thomas <th...@ecofin.ch>.
> 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".
I guess the argument was more "we don't like new stuff when the old will
do". It works the other way around, too: all I'm hearing is that some
guys like annotations (more elegant, readeable), but I remain
unconvinced that it's the better way.
<snip...>
>
> 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() {
> }
> }
>
Now when I look at the Component class, I see no indication that there
is such a thing as statelessness. I find the isStateless() method much
more discoverable. I'm all for separation of concerns, but this is
(imho) exactly not an orthogonal configuration, but an intrinsic
property of the component implementation.
On a more general level, when I speak of configuration (as opposed to
code), I mean something that can change with different uses of the same
code. For example, there could be one use of a page where it is
stateless, and another where it is not. Annotations exactly cannot do
that.
Thomas
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <ee...@gmail.com> wrote:
> On Jan 11, 2008 11:53 AM, Martijn Dashorst <ma...@gmail.com> 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
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
On Jan 11, 2008 11:53 AM, Martijn Dashorst <ma...@gmail.com> 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
Re: 1.4/2.0 annotations support
Posted by Jon Steelman <jo...@gmail.com>.
The burden is on you to demonstrate that a significant change like
this is warranted. Show use cases of what's done presently and use
cases of how you would handle it with annotations. Your annotation use
cases must be compelling over the original ones.
Jon
On Jan 11, 2008 2:53 PM, Martijn Dashorst <ma...@gmail.com> 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.
>
> Seriously all the "I don't like annotations" arguments are getting stale.
>
> Martijn
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
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.
Seriously all the "I don't like annotations" arguments are getting stale.
Martijn
On Jan 11, 2008 6:42 PM, Jon Steelman <jo...@gmail.com> wrote:
> If we are talking about using annotations for anything that hints of
> declarative programming, I'm not at all in favor. Nobody here...but some
> folks are rabid about declarative programming and always find a new way to
> attempt to finally make it work. It reminds me of the
> Computer-Aided-Software-Engineering (CASE) debacle from the 80's which has
> its latest incarnation as Model-Driven-Architecture (MDA). There are
> fundamental reasons why CASE/MDA isn't really going to fly yet generation
> after generation of folks get seduced into taking a crack at it. Declarative
> programming (including systems that use annotations for declarative
> programming) is to me another relative dead-end. Please don't saddle Wicket
> with it. :-)
>
--
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
Re: 1.4/2.0 annotations support
Posted by Jon Steelman <jo...@gmail.com>.
If we are talking about using annotations for anything that hints of
declarative programming, I'm not at all in favor. Nobody here...but some
folks are rabid about declarative programming and always find a new way to
attempt to finally make it work. It reminds me of the
Computer-Aided-Software-Engineering (CASE) debacle from the 80's which has
its latest incarnation as Model-Driven-Architecture (MDA). There are
fundamental reasons why CASE/MDA isn't really going to fly yet generation
after generation of folks get seduced into taking a crack at it. Declarative
programming (including systems that use annotations for declarative
programming) is to me another relative dead-end. Please don't saddle Wicket
with it. :-)
Re: 1.4/2.0 annotations support
Posted by Ryan Sonnek <ry...@gmail.com>.
> But those projects ended up adding the annotation option because they had
> something ugly like XML configuration hell that they were trying to improve
> upon. Wicket does not.
True! Good point! =)
Re: 1.4/2.0 annotations support
Posted by Jon Steelman <jo...@gmail.com>.
On Jan 11, 2008 10:05 AM, Ryan Sonnek <ry...@gmail.com> wrote:
> +1 for separate project regardless of the outcome. Tapestry,
> hibernate, and spring are all examples of projects that provide the
> *option* to use annotations if you want.
But those projects ended up adding the annotation option because they had
something ugly like XML configuration hell that they were trying to improve
upon. Wicket does not.
On Jan 11, 2008 4:02 AM, Maeder Thomas <th...@ecofin.ch> wrote:
> I'd like to chime in on the conservative side here. I believe you should
> only introduce a completely new way of doing things if there is a CLEAR
> benefit to be had.
Exactly.
Jon
Re: 1.4/2.0 annotations support
Posted by Ryan Sonnek <ry...@gmail.com>.
+1 for separate project regardless of the outcome. Tapestry,
hibernate, and spring are all examples of projects that provide the
*option* to use annotations if you want.
On Jan 11, 2008 9:00 AM, Eelco Hillenius <ee...@gmail.com> wrote:
> On Jan 11, 2008 1:02 AM, Maeder Thomas <th...@ecofin.ch> wrote:
> > I'd like to chime in on the conservative side here. I believe you should
> > only introduce a completely new way of doing things if there is a CLEAR
> > benefit to be had.
>
> Exactly. See http://chillenious.wordpress.com/2006/08/01/does-wicket-need-ajax-annotations/
> for a related rant.
>
> To Martijn's defense, it is never bad to explore new ideas. But the
> benefit should be huge or we shouldn't do it imho (or in a separate
> project, that'll always be fine with me).
>
> Eelco
>
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
On Jan 11, 2008 1:02 AM, Maeder Thomas <th...@ecofin.ch> wrote:
> I'd like to chime in on the conservative side here. I believe you should
> only introduce a completely new way of doing things if there is a CLEAR
> benefit to be had.
Exactly. See http://chillenious.wordpress.com/2006/08/01/does-wicket-need-ajax-annotations/
for a related rant.
To Martijn's defense, it is never bad to explore new ideas. But the
benefit should be huge or we shouldn't do it imho (or in a separate
project, that'll always be fine with me).
Eelco
RE: 1.4/2.0 annotations support
Posted by Maeder Thomas <th...@ecofin.ch>.
I'd like to chime in on the conservative side here. I believe you should
only introduce a completely new way of doing things if there is a CLEAR
benefit to be had. Color me unconvinced on that account.
Furthermore, annotations on classes are basically equivalent to tagging
interfaces. I thought those were bad?
Thomas
> -----Original Message-----
> From: Eelco Hillenius [mailto:eelco.hillenius@gmail.com]
> Sent: Donnerstag, 10. Januar 2008 18:23
> To: dev@wicket.apache.org
> Subject: Re: 1.4/2.0 annotations support
>
> > - @Stateless - instead of overriding isStateless
> > - @Headers - define headers specific for the page
>
> Playing the advocate of the devil: the thing with those is
> that it doesn't actually solve anything. I mean, you hardly
> decrease the lines of code you have to write to achieve
> something, annotations are arguably harder to discover than
> overridable methods, and we end up with having multiple ways
> to do the same thing...
>
> Eelco
>
Re: 1.4/2.0 annotations support
Posted by Ryan Sonnek <ry...@gmail.com>.
> Playing the advocate of the devil: the thing with those is that it
> doesn't actually solve anything. I mean, you hardly decrease the lines
> of code you have to write to achieve something, annotations are
> arguably harder to discover than overridable methods, and we end up
> with having multiple ways to do the same thing...
I agree 100% *except* the real point of annotations is to provide
*meta-data* about your objects. So the question is whether or not
these "settings" are meta-data about a page? Overriding methods does
accomplish the same goal, but it's a very different approach.
I'm all for whatever makes the most sense. I personally think the
@Stateless annotation would kick ass. =)
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
> - @Stateless - instead of overriding isStateless
> - @Headers - define headers specific for the page
Playing the advocate of the devil: the thing with those is that it
doesn't actually solve anything. I mean, you hardly decrease the lines
of code you have to write to achieve something, annotations are
arguably harder to discover than overridable methods, and we end up
with having multiple ways to do the same thing...
Eelco
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
Possibilities:
- @Stateless - instead of overriding isStateless
- @Caching - how to cache the component's/page's markup
- @Headers - define headers specific for the page
Martijn
On Jan 10, 2008 5:43 PM, Ryan Sonnek <ry...@gmail.com> wrote:
> > Well, if you're going to do that, why not just mount the page in the
> > application class and skip the annotation + registration altogether?
>
> *IF* annotation support only includes mounting the url, i agree with
> you. but if you start specifying url encoding strategies or other
> useful page annotations come about, then I still think it makes sense.
>
--
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
Re: 1.4/2.0 annotations support
Posted by Ryan Sonnek <ry...@gmail.com>.
> Well, if you're going to do that, why not just mount the page in the
> application class and skip the annotation + registration altogether?
*IF* annotation support only includes mounting the url, i agree with
you. but if you start specifying url encoding strategies or other
useful page annotations come about, then I still think it makes sense.
Re: 1.4/2.0 annotations support
Posted by Nick Heudecker <nh...@gmail.com>.
> One comment I have about classpath scanning is that *if* it turns out
> to be a nightmare, you could go the route of Hibernate where you have
> to register what annotated pages you want to support. ex:
Well, if you're going to do that, why not just mount the page in the
application class and skip the annotation + registration altogether?
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
> One comment I have about classpath scanning is that *if* it turns out
> to be a nightmare, you could go the route of Hibernate where you have
> to register what annotated pages you want to support. ex:
>
> public class MyWebApplication extends Application {
> public void init() {
> registerAnnotatedWebPage(MyWebPage.class);
> registerAnnotatedWebPage(SecondPage.class);
> ..etc..
> }
> }
Yeah, that's a good alternative.
Eelco
Re: 1.4/2.0 annotations support
Posted by Ryan Sonnek <ry...@gmail.com>.
+1 for some R&D time. I think this could turn out to be *really* cool.
One comment I have about classpath scanning is that *if* it turns out
to be a nightmare, you could go the route of Hibernate where you have
to register what annotated pages you want to support. ex:
public class MyWebApplication extends Application {
public void init() {
registerAnnotatedWebPage(MyWebPage.class);
registerAnnotatedWebPage(SecondPage.class);
..etc..
}
}
Just a thought. I don't want to see the whole idea thrown out *just
because* of classpath scanning. That's a whole separate issue IMO.
On Jan 10, 2008 9:08 AM, Nino Saturnino Martinez Vazquez Wael
<ni...@jayway.dk> wrote:
> +10 for exploring, you just never know what handy feature turns up:) I
> meant to say that to in my previous mail.
>
>
> Martijn Dashorst wrote:
> > Having the ability to specify the mount with the page instead of a
> > central location may be interesting. How is this different from
> > specifying to what table an entity is retrieved from? I think having
> > all the things that relate to a specific page in one place is an
> > advantage.
> >
> > I'm not sure what deserved this outburst, but I think *EXPLORING* the
> > possibility and the consequences of having a mount-annotation are
> > worth it. Just saying you don't like it without arguments or throwing
> > some unrelated arguments around just doesn't cut it. If you don't like
> > it, you don't have to use it.
> >
> > So instead of the "I don't like ..." arguments, please answer the
> > question: What issues would we run into if we were going to implement
> > it? There are probably tons of issues associated with it, for instance
> > (which didn't take me long to come up with):
> >
> > Pro's:
> > - a long list of mounts becomes unmanagable
> > - easy to add a mount: work on a page, slap on the annotation and you
> > have your mount done
> > - locality of the configuration
> >
> > Con's
> > - distributed configuration, so hard to see the 'big picture' (though
> > a mounts page listing all mounts would help)
> > - scanning of classpath at startup (though spring, struts, etc are
> > doing that already)
> > - multiple mounts at same position harder to detect, though that is
> > already possible.
> >
> > Open questions:
> > - annotated page impossible?
> > - specifying the URL encoding strategy
> > - multiple mounts for the same page
> > - package mounting?
> > - can we override the annotated mount?
> > - how do we work with pages contributed using jars, could we disable
> > the annotated mounts and provide our own?
> >
> > Martijn
> >
> > On Jan 10, 2008 2:28 PM, Eduardo Ito <zi...@summa-tech.com> wrote:
> >
> >> I agree...
> >>
> >> What is the *advantage* of putting the mount definition in an annotation?
> >> Following the same pattern, we would create a bunch of annotations
> >> like @PageSettings, @HomePage, etc... argh!
> >>
> >>
> >>
> >> On 1/10/08, Eelco Hillenius <ee...@gmail.com> wrote:
> >>
> >>>> I suggest we take a look at annotations for:
> >>>> * the mount with a page
> >>>>
> >>> A disadvantage to doing that imho is that you'll have those
> >>> definitions scattered throughout. Right now we steer people to do it
> >>> in one place.
> >>>
> >>> Eelco
> >>>
> >>>
> >> --
> >> Eduardo Issao Ito
> >> Summa Technologies
> >>
> >> "Discipline is never an end in itself, only a means to an end"
> >>
> >>
> >
> >
> >
> >
>
> --
>
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
Re: 1.4/2.0 annotations support
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
+10 for exploring, you just never know what handy feature turns up:) I
meant to say that to in my previous mail.
Martijn Dashorst wrote:
> Having the ability to specify the mount with the page instead of a
> central location may be interesting. How is this different from
> specifying to what table an entity is retrieved from? I think having
> all the things that relate to a specific page in one place is an
> advantage.
>
> I'm not sure what deserved this outburst, but I think *EXPLORING* the
> possibility and the consequences of having a mount-annotation are
> worth it. Just saying you don't like it without arguments or throwing
> some unrelated arguments around just doesn't cut it. If you don't like
> it, you don't have to use it.
>
> So instead of the "I don't like ..." arguments, please answer the
> question: What issues would we run into if we were going to implement
> it? There are probably tons of issues associated with it, for instance
> (which didn't take me long to come up with):
>
> Pro's:
> - a long list of mounts becomes unmanagable
> - easy to add a mount: work on a page, slap on the annotation and you
> have your mount done
> - locality of the configuration
>
> Con's
> - distributed configuration, so hard to see the 'big picture' (though
> a mounts page listing all mounts would help)
> - scanning of classpath at startup (though spring, struts, etc are
> doing that already)
> - multiple mounts at same position harder to detect, though that is
> already possible.
>
> Open questions:
> - annotated page impossible?
> - specifying the URL encoding strategy
> - multiple mounts for the same page
> - package mounting?
> - can we override the annotated mount?
> - how do we work with pages contributed using jars, could we disable
> the annotated mounts and provide our own?
>
> Martijn
>
> On Jan 10, 2008 2:28 PM, Eduardo Ito <zi...@summa-tech.com> wrote:
>
>> I agree...
>>
>> What is the *advantage* of putting the mount definition in an annotation?
>> Following the same pattern, we would create a bunch of annotations
>> like @PageSettings, @HomePage, etc... argh!
>>
>>
>>
>> On 1/10/08, Eelco Hillenius <ee...@gmail.com> wrote:
>>
>>>> I suggest we take a look at annotations for:
>>>> * the mount with a page
>>>>
>>> A disadvantage to doing that imho is that you'll have those
>>> definitions scattered throughout. Right now we steer people to do it
>>> in one place.
>>>
>>> Eelco
>>>
>>>
>> --
>> Eduardo Issao Ito
>> Summa Technologies
>>
>> "Discipline is never an end in itself, only a means to an end"
>>
>>
>
>
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
Re: 1.4/2.0 annotations support
Posted by Martijn Dashorst <ma...@gmail.com>.
Having the ability to specify the mount with the page instead of a
central location may be interesting. How is this different from
specifying to what table an entity is retrieved from? I think having
all the things that relate to a specific page in one place is an
advantage.
I'm not sure what deserved this outburst, but I think *EXPLORING* the
possibility and the consequences of having a mount-annotation are
worth it. Just saying you don't like it without arguments or throwing
some unrelated arguments around just doesn't cut it. If you don't like
it, you don't have to use it.
So instead of the "I don't like ..." arguments, please answer the
question: What issues would we run into if we were going to implement
it? There are probably tons of issues associated with it, for instance
(which didn't take me long to come up with):
Pro's:
- a long list of mounts becomes unmanagable
- easy to add a mount: work on a page, slap on the annotation and you
have your mount done
- locality of the configuration
Con's
- distributed configuration, so hard to see the 'big picture' (though
a mounts page listing all mounts would help)
- scanning of classpath at startup (though spring, struts, etc are
doing that already)
- multiple mounts at same position harder to detect, though that is
already possible.
Open questions:
- annotated page impossible?
- specifying the URL encoding strategy
- multiple mounts for the same page
- package mounting?
- can we override the annotated mount?
- how do we work with pages contributed using jars, could we disable
the annotated mounts and provide our own?
Martijn
On Jan 10, 2008 2:28 PM, Eduardo Ito <zi...@summa-tech.com> wrote:
> I agree...
>
> What is the *advantage* of putting the mount definition in an annotation?
> Following the same pattern, we would create a bunch of annotations
> like @PageSettings, @HomePage, etc... argh!
>
>
>
> On 1/10/08, Eelco Hillenius <ee...@gmail.com> wrote:
> > > I suggest we take a look at annotations for:
> > > * the mount with a page
> >
> > A disadvantage to doing that imho is that you'll have those
> > definitions scattered throughout. Right now we steer people to do it
> > in one place.
> >
> > Eelco
> >
>
>
> --
> Eduardo Issao Ito
> Summa Technologies
>
> "Discipline is never an end in itself, only a means to an end"
>
--
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
AW: 1.4/2.0 annotations support
Posted by Stefan Lindner <li...@visionet.de>.
@HomePage wuold not be very handy. Assume you have more than one page annotated with @HomePage. Which should be the REAL homepage? Or should this result in an error message during deployment?
Stefan
-----Ursprüngliche Nachricht-----
Von: Eduardo Ito [mailto:ziba@summa-tech.com]
Gesendet: Donnerstag, 10. Januar 2008 14:29
An: dev@wicket.apache.org
Betreff: Re: 1.4/2.0 annotations support
I agree...
What is the *advantage* of putting the mount definition in an annotation?
Following the same pattern, we would create a bunch of annotations like @PageSettings, @HomePage, etc... argh!
On 1/10/08, Eelco Hillenius <ee...@gmail.com> wrote:
> > I suggest we take a look at annotations for:
> > * the mount with a page
>
> A disadvantage to doing that imho is that you'll have those
> definitions scattered throughout. Right now we steer people to do it
> in one place.
>
> Eelco
>
--
Eduardo Issao Ito
Summa Technologies
"Discipline is never an end in itself, only a means to an end"
Re: 1.4/2.0 annotations support
Posted by Eduardo Ito <zi...@summa-tech.com>.
I agree...
What is the *advantage* of putting the mount definition in an annotation?
Following the same pattern, we would create a bunch of annotations
like @PageSettings, @HomePage, etc... argh!
On 1/10/08, Eelco Hillenius <ee...@gmail.com> wrote:
> > I suggest we take a look at annotations for:
> > * the mount with a page
>
> A disadvantage to doing that imho is that you'll have those
> definitions scattered throughout. Right now we steer people to do it
> in one place.
>
> Eelco
>
--
Eduardo Issao Ito
Summa Technologies
"Discipline is never an end in itself, only a means to an end"
Re: 1.4/2.0 annotations support
Posted by Dmitry Kandalov <no...@gmail.com>.
On Thursday 10 January 2008 08:55:38 Eelco Hillenius wrote:
> > I suggest we take a look at annotations for:
> > * the mount with a page
I like it.
> A disadvantage to doing that imho is that you'll have those
> definitions scattered throughout. Right now we steer people to do it
> in one place.
I think it should be easy to find all usages of annotation in project with IDE
help. And in some sense page mount information is not related to application
class.
Dima
Re: 1.4/2.0 annotations support
Posted by Eelco Hillenius <ee...@gmail.com>.
> I suggest we take a look at annotations for:
> * the mount with a page
A disadvantage to doing that imho is that you'll have those
definitions scattered throughout. Right now we steer people to do it
in one place.
Eelco