> > 3) Use Annotations to handle mounting. Instead of putting all mount logic > in the Application class, you could annotate your pages with something > like > @Mount( strategy=foo.class, params=x,y,z ). Then upon initialization, > Wicket could scan the class path and auto-mount these annotated pages. > Scanning the classpath is pretty easy using some spring-core > functionality. > I don't know if the Spring license is compatible with Apache, so this > might > need to be a contrib feature. >
personally i dont see any added value. It is stil a line of "code", no gain here. then scattered throughout your code base also you have to make sure that you can have then multiply of those mounts for 1 class i use the same pages under different mounts.. also what happens if you package your pages and somebody else uses it or you start to also use them in an other project... But that doesnt want those mount points... what then? you cant remove them because then the first app breaks... I still think mounting and stuff is something the Application is responsible for not the web app itself. I could see an annotation like: @Unmountable ... Because it is sort of a security hole in wicket now. If a page has a default constructor and i know the name i could just show it... (of no other security prevents that) Ofcourse this is very hypothetical and not very likely that it will be abused because you have to know classnames (but these can spoil out when not carefull with shared resouces..) johan
