> > 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
On 1/9/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>
> On Jan 10, 2008 12:06 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > you mean @Mount("/foo") class MyPage extends WebPage {...}
> >
> > then we have to scan the classpath for all classes that have that
> > annotation.
>
> Yep,
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.
On Jan 15, 2008 11:22 AM, Bruno Borges <[EMAIL PROTECTED]> 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.
>
> Th
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
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 packag
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 const
> 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
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
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.
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 <[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
On Jan 11, 2008 1:25 PM, 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* Jav
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
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
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 Dasho
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 <[EMAIL PROTECTED]> 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-Engi
> 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! =)
On Jan 11, 2008 10:05 AM, Ryan Sonnek <[EMAIL PROTECTED]> 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 opti
+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 <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 1:02 AM, Maeder Thomas <[EMAIL PROTECTED]
On Jan 11, 2008 1:02 AM, Maeder Thomas <[EMAIL PROTECTED]> 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
ought those were bad?
Thomas
> -Original Message-
> From: Eelco Hillenius [mailto:[EMAIL PROTECTED]
> Sent: Donnerstag, 10. Januar 2008 18:23
> To: dev@wicket.apache.org
> Subject: Re: 1.4/2.0 annotations support
>
> > - @Stateless - instead of overriding isState
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 <[EMAIL PROTECTED]> wrote:
I think especially overriding setHeaders is not intuitive whereas an
annotation could really make
On Jan 10, 2008 9:32 AM, Martijn Dashorst <[EMAIL PROTECTED]> 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 i
On Jan 10, 2008 9:32 AM, Martijn Dashorst <[EMAIL PROTECTED]> 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
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 an
> 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 multipl
> - @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, annotat
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 <[EMAIL PROTECTED]> wrote:
> > Well, if you're going to do that, why not just
On Jan 10, 2008 5:32 PM, Eelco Hillenius <[EMAIL PROTECTED]> 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 i
> 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 annotati
> 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 s
> 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() {
> registe
> 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 m
+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 MyWebApplicat
+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
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 dese
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. Migh
: 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
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 <[EMAIL PROTECTED]> wrote:
> > I suggest we take a look at annotations f
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 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
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
On Jan 10, 2008 12:15 AM, Igor Vaynberg <[EMAIL PROTECTED]> 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/wick
im not a big fan of scanning classpaths
-igor
On Jan 9, 2008 3:10 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 12:06 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > you mean @Mount("/foo") class MyPage extends WebPage {...}
> >
> > then we have to scan the classpath for all
On Jan 10, 2008 12:06 AM, Igor Vaynberg <[EMAIL PROTECTED]> 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
-
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 <[EMAIL PROTECTED]> wrote:
> We've tried annotations for lifecycle methods and that didn't work
>
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
48 matches
Mail list logo
